Hey Mike. Basically, what you do is use ./launcher bootstrap to build the image, push it to a repo, and then use ./launcher start-cmd to see what ENV needs to get passed to Docker to crank things up.
The reason that such a guide doesn’t exist is that people who don’t have the most basic understanding of any of the underlying pieces work will find it and not be able to make sense of it and then expect a tutorial on how ingress works on whatever system that the think is the only answer.
Call me crazy, but maybe you are living proof that we did things the way we did for a reason? 
Thanks Jay - I figured that much out. I finally made it work.
I guess part of the issue is that it goes counter the grain of all the other docker images out there. It isn’t as plug and play. It is more fiddle, plug and then play.
As I said, the launcher is a beautiful and reliable thing for what it does.
On a really positive note, the web only build works a treat, its super fast on my swarm, updateable because I have the build server.
When I have time I will explore a build server on my swarm that allows a web based build of a docker image.
Things I tried that left much to be desired…
Ok - thanks.
Mike.
we got that First Mover Disadvantage 
The launcher script was created before docker-compose, docker-swarm, kubernetes, and all that existed, and… it still works. There’s not really any compelling reason for us to switch to something else. The “advantages” of these systems aren’t advantages for the #1 consumer of Discourse self-hosting, which is budget installations on cloud VPSes.
Oh! I always wondered. And last I looked, it was an extra step to install docker-compose on Ubuntu. It’s like they don’t want people to use it, unless those people use windows (or Mac?)
A bit sad to hear this as official response from the development team. You basically saying that if you’re not good enough to figure out this undocumented process of running Discourse in production then maybe you shouldn’t be running Discourse in production.
Well, not every one of us has extensive devops experience, sadly.
@Mike_Sutton I am on the same page with you. Have been reading the forums for the last few weeks trying to crack this nut. Did you manage to make a video on how you solved the problem?
Would that work? What about DB migrations?
In this scenario, you’d have bootstrap do the migrations as it builds the new container image.
Yes, you can push Discourse docker images to a repo and archive the rest of /var/discourse like in the discussion below but it is not an efficient way to do things and is not officially supported. I recently fully tested this:
But in this case the bootstrap step must be done in the production machine, this kinda defeats the purpose of pushing a base image to a container registry, if I’m not mistaken (because this would be done with the intention of not having to bootstrap an image in production, except maybe to run a db migration step or something like that).
This is what I do in non discourse sites I host, I normally use flyway to run migrations in the db, along with some other stuff like emptying the redis cache, but without running other intensive processes, especially ones that depends on external services, like updating https certificates (I would do in a cronjob, except the 1st time, which is fine), or changing the codebase (this would be static in the image, like packages, libraries, and other stuff). It seems discourse uses rake which is fine, but it does other stuff like installing gems, generating assets, updating maxmind db and maybe other services (which would break the rebuild step if, for example, the service is down, or if they change the API, which is rare but could happen).
I’m not saying that discourse should do that way, of course, but generating an image in a CI environment and just running a db migration step in staging/production servers, along with defining the environment variables, is what I would expect, and is easily achievable with other softwares like Wordpress, Mediawiki, Rocketchat, etc… Discourse is the best software for forums IMO, and they might have good reasons to do it the way they do, but for now I would only use the standard install (or multicontainer install) to avoid headaches and just hope that nothing goes wrong with rebuilds.
It seems like the bootstrap should still be done in a production environment, and not in a CI environment to generate a base image to use in both a staging and production environment. Furthermore, not being a standard install is a huge red flag, that can became a headache in the future as the software receives updates.