There is this open issue (which I just closed) on Discourse Docker repo asking Discourse should behave like a standard docker image a docker user excepts to be able to run discourse without a special launcher. to define multiple containers (redis, postgres, discourse,..), links and volumes, docker-compose should be used instead. Docker Compose | Docker Docs The question is somewhat misguided, but I would like to address a broader one of Can Discourse ship frequent Docker images that do not need to be bootstrapped? This question if far more complicated, so let me start here Compose and launcher operate at different levels Compose is a tool used for multi image orchestration. It allows you to “define” environments, bring them up and tear them down. It allows simple generation of base images from Dockerfiles (provided they are not local) Launcher is a tool used for a wide variety of processes many of which have no parity with Docker Compose We have a series of pre-req tests that ensure a system is up to the task of running Discourse (enough memory / disk space and so on) We provide lightweight wrappers on top of docker exec , docker start , docker stop and docker rm, these wrappers ensure containers are launched with the correct configuration, automatically restart and so on We allow rich semantics with generation of base images, this allows you to mixin support similar to the closed INCLUDE proposal for Docker. Unlike Docker compose, Launcher only deal with configuration of a single container We provide utilities like “cleanup” that allow you to clean up old orphan docker images Our installation process was always meant to be “philosophy” agnostic. You can run Discourse as a single “fat” container including pg/redis and the web, you can also run Discourse in multiple containers using launcher keeping db and redis in other containers. Launcher reflects this. At the end of the day … launcher and Docker Compose are compatible, you can generate the base images you want using launcher and bring up your environment using compose. The tools do very different things. If you look at the images on your box you will notice an image called: local_discourse/app (derived from your yml file name), this image can be pushed to your own registry, composed using Docker compose and so on. So let me try to address some of the bigger question here instead. Why do we need to bootstrap? Discourse ships 2 Docker images that you can use to generate your environment: SamSaffron/discourse_base , config: Our base image that include all our dependencies excluding Discourse code. This image includes the “right” version of Ruby, Node, runit, postgres, redis and the list goes on and on. It also includes the plumbing for running stuff that uses this image, taking care of providing infrastructure for reliable cron, log rotation, a reliable boot up and boot down process and so on. All our images are derived off this image SamSaffron/discourse , config : a simple image generated from our base image that creates the Discourse user and performs a “bundle install”. The process of “bootstrapping” takes a base image (SamSaffron/discourse by default) and performs a series of transformations on it that prepare the image for execution. We did not use a Dockerfile, for this process cause the Dockerfile did not support the rich transformations we needed and generated lots and lots of layers. In the context of a full container for Discourse the bootstrapping process will Ensure postgres configuration is in place, configuration is dynamic and can be overridden by parent configuration. For example, this process will default [db_shared_buffers][7] in postgres config to “256MB”, however users may amend the app.yml file to increase this amount, which in turn will amend the physical configuration file in the bootstrapped image. The Postgres template also takes care of pesky things like postgres upgrade, which are 100% absent from the official postgres images. Dealing with issues such as this is totally omitted from the default images: docker run -it --rm -v /tmp/pgdata:/var/lib/postgresql/data -e POSTGRES_PASSWORD=mysecretpassword postgres:9.3 docker run -it --rm -v /tmp/pgdata:/var/lib/postgresql/data -e POSTGRES_PASSWORD=mysecretpassword postgres:9.4 LOG: skipping missing configuration file "/var/lib/postgresql/data/postgresql.auto.conf" FATAL: database files are incompatible with server DETAIL: The data directory was initialized by PostgreSQL version 9.3, which is not compatible with this version 9.4.4. Ensure redis is configured correctly, including ensuring that redis is always launched before the web comes up in “fat container” setup. Ensure rake assets:precompile and bundle install is executed. Perform a series of transformations on our existing config (including setting up log rotation, setting up directories, permission, configuring NGINX and so on) Apply specific user transformations. Want rate limiting? no problem. Want to use CloudFlare? Sure. Want to apply your own transformation? You have a rich set of hooks during the bootstrap process that allow you to apply your changes at the exact right spot. In a nutshell there are 3 strong reasons why bootstrapping exists in the Discourse context Allow end user to override various settings that are written into files (such as transformations of NGINX config and PG config) rake assets:precompile needs access to a “specific” customer database and config To ensure plugins are able to amend application.js file and insert plugin code (which is minified) To ensure custom colors which live in the DB are taken into account when generating the application CSS file To run DB migrations What if we shipped an updated bootstrapped image? Internally when we deploy we use a “pre-bootstrapped” image as our base image and then simply run “assets:precompile” and “rake db:migrate” as our only bit of custom bootstrapping code. This allows us to mostly eliminate the need for an expensive bootstrap on every deploy. Images for our customers are shipped to a central private repo, we deploy the same image on multiple machines to load balance customers. There is a great appeal to having a simple “dockery” distribution for Discourse eg: docker run -d --link discourse_db --link discourse_redis --name discourse discourse:latest This kind of distribution would allow us to easily apply updates without needing do a new bootstrap EG: docker pull discourse:latest docker rm -f discourse docker run -d --link discourse_db --link discourse_redis --name discourse discourse:latest Bang, you have an update with very minimal downtime and you did not need to bootstrap. But … Who / what is going to migrate the database? Who / what is going to ensure assets are precompiled if you have custom plugins? How are you going to install plugins? How is this going to work in a multi machine setup? If I precompile assets on machine A so they include a plugins changes to application.js how can machine B get that exact change? How are we going to apply non ENV var settings How are you going to apply transformations like the cloudflare config or rate limiting? Only way to get this going very reliably would be Introduce an intelligent boot process that through distributed locking can cleanly generate compiled assets and migrate. Convert all params we have now into ENV, on boot generate the conf files we need based on ENV. Trade around with your own custom discourse images just as we have today Heavily amend core to allow for a more intelligently composed application.js and a smarter way for doing application.css This is not a zero sum game We can slowly chip at some problems: We can automatically build and publish Discourse base images for tests-passed, beta and stable, if done carefully this can help a lot, cutting down on precompilation and bundle install times drastically. We have to be careful about image count explosion though. We can migrate some (or even all) settings from params into ENV and introduce a boot sequence that applies the settings. This will allow people to tweak a lot of stuff without needing a full bootstrap We can investigate a system that allows us to install a plugin without a “full” precompile, and maybe even ship plugin docker images. That said, this is a huge system and I would like to focus on our real and urgent problems first. Which in my mind are: Writing upgrade logic for pg from 9.3 to 9.5 (which is just around the corner) I want us to move to 9.5 this year Moving us to a multi image install by default, its super nice not to need to stop a site during bootstrap, only way of achieving this is with a multi image install. However, I do not want users having to muck around with multiple config files, so we need to think of a format that would enable this simply. Supporting another config format that is not yaml (probably toml). Our #1 support issue we see is “I mucked up my yaml file”, guess what … compose also has this problem.

You are right, the settings can be changed indeed. If I get it running without a big effort, I will try sending some PR to improve the existing tooling or documentation, such as running it without root. That should be compatible with the opinions of the development team, while bringing some relief to some more demanding sysadmins.

9 years later, it seems like idiomatic docker is covered by bitnami’s discourse? But elsewhere in this forum there are claims that it’s a ram hog and is unsupported. I was surprised to see how much friction there still is in the canonical setup when trying to get it running in the cloud. A lot of services these days like redis, postgres and s3-compatible storage are easy to setup and move between different hosts like digitalocean, supabase, aws, etc, so the back end is portable. The vm running discourse seems like it should also be easy to scale/swap with deterministic builds. It’s a shame that it’s so close to this ideal but held back. Like another user said, this is surprising: [image] AquaL1te: have never saw a project that is able to make a container installation non-portable like this. The logic alluded to earlier in the thread that making this easier might hinder commercial opportunities is a strange one. Commercial interests will have staff to deal with the complex builds, so this is hitting solo devs more than anyone. My personal use case is that I run a very large (no profit) community. So it doesn’t fall under hobbyist by scale or commercial by revenue.

Eh… I’m pondering setting up a forum/community board and obviously thought about using Discourse (because I enjoy end-user experience) but again I hit the roadblock with completely hostile installation/management… Over the years I grew super attached with having everything run with simple docker-compose file, throwing a couple of additional elements (database, minio for s3 compatible storage and whatnot) but nope… Discourse is still super hostile in this case. I’m sorry but having some silly “launcher” to start things up? And then the upgrade process stating: Create a new base image manually by running: ./launcher rebuild my_image sorry - manually rebuilding the image? Like WTF… it’s like having/using docker but actually not using it…

Does ./launcher rebuild app work? That’s the usual command. Also, did you follow the standard install guide?

I have nothing constructive to comment, so I ask you try upgrade Mastodon server, Pixelfed, Moodle… Discourse is unbeliavable easy. One manual command is a road block :flushed_face:

Docker compose does not feature the required functionality. Discourse’s docker file templating construction allows for flexible docker results. With compose all you have is a possible set of fixed Dockefiles which can result in a bunch of containers. In my Discourse setup I use a single container with Discourse and nginx using a UNIX socket. PostgreSQL and Redis are a service on the host. That is quite a deviation from the the default setup, but it is possible out of the box. It is partially possible with compose, maybe by using the rather ill engineered profile feature. But even then it is rather messy. Or you would need to deliver different compose files for each variation. You are just moving the problem. A clean compose setup for Discourse would be the following services in separate containers: Discourse nginx PostgreSQL Redis Disocurse and nginx need to share a volume, no biggy. PostgreSQL and Redis… those are things you might want to host elsewhere, and not have a Discourse specific container for it. And now docker compose become an issue docker compose up -d will launch your undesired PostgreSQL. Ok, so we make it docker compose --profile postgresql up -d to launch the basic discourse setup, and a postgresql container. docker compose --profile postgresql --profile redis up -d for the “full” self contained Discourse container setup. You better not forger a --profile ... argument, because then you have more issues. So for better UX, you make a launcher to take care of creating the desired docker compose command. Now we are kind of back where we are. Except that modifications to the nginx container are not possible yet. So I need a nginx-http container and nginx-unix container which should be mutually exclusive? … Sure the plugin management could be better, but doing this with docker compose, that’ll be hell.

So, to sum it up. There won’t be proper docker image. As for the unbelievable amount of incorrect knowledge about what docker is and how it operates: What is Docker? | Docker Docs You can share containers while you work, and be sure that everyone you share with gets the same container that works in the same way. Also - with the beloved “launcher” - how can I run discourse on k8s cluster given there is no docker image I can consume and deploy it there? [image] NateDhaliwal: Does ./launcher rebuild app work? That’s the usual command. Also, did you follow the standard install guide? Riiight… This script must be run as root. Please sudo or log in as root first. No, thank you. I don’t like running random scripts from internet. I only want to have nice Docker image that I can safely run in isolation :slight_smile:

[image] elmuerte: Docker compose does not feature the required functionality. I’ve successfully deployed Discourse to Production using Docker Compose with the published image as have clients. However, yes, it’s messy and a reasonable amount of bespoke work is involved. It is much easier to stick with the standard install with the CDCK launcher unless you really must use a different method because you have an opionated view, specific architecture or otherwise special requirements.

[image] merefield: use a different method because you have an opionated view, specific architecture or otherwise special requirements. Using non-wizard-take-my-by-the-hand approach is not “opinionated, specific or special” :roll_eyes: At any rate - the clue is having original docker image from discourse. As simple as that. I tried using the official guide and “launcher” just to toy with the setup - with no luck (save for quite silly check if the user is root, which is just asking for problems). I then turned to bitnami image (and their suggested compose file) from bitnami/discourse - Docker Image and one docker compose up later (and a bunch of SQL error [which doesn’t bode well] as well as warning from ruby [same caveat] I got running instance of discourse: [Captura de pantalla 2025-07-06 a las 18.01.03] Pure convoluted and “non-standard magic”… So again - why there is no regular image? Digging through sources and repositories I found that base image is used (discourse/base - Docker Image) though it’s verioning/tagging surprised me (discourse/base - Docker Image)… There are no sane versions I wondered? And indeed, looking at the main repo there didn’t seem to be any releases but hey - at least there are properly tagged versions (Tags · discourse/discourse · GitHub). Now one wonder - why there are not matching images in the main docker hub? So yeah - having a look at how things are organized I concur: [image] merefield: it’s mess :smiley: On the other hand (or rather: “how things should be”), example project (smaller in scope, but the reasoning stands): GitHub - miniflux/v2: Minimalist and opinionated feed reader · GitHub. It has sane releases: Releases · miniflux/v2 · GitHub Which have corresponding images correctly tagged: miniflux/miniflux - Docker Image And then upgrading is just switching version from x to y (or using latest tag so simple stop/pull/start will give updated version (which would run all required migrations automatically) (oh, and the image is like 70x smaller but that’s yet another story)

Can Discourse ship frequent Docker images that do not need to be bootstrapped?

Development

merefield (Robert) July 5, 2025, 4:00pm 187

I believe the launcher was built before docker compose was a thing:

Topic		Replies	Views
Using a launcher built docker image in docker-compose Development	30	8533	September 27, 2024
Container restart - discourse tries to reinstall Self-hosting unsupported-install	22	3349	July 30, 2020
Installing on Kubernetes Self-hosting unsupported-install	56	26562	June 9, 2026
Is Docker image discourse/discourse considered safe and production-ready? Self-hosting hosting	30	3710	May 26, 2026
Community supported official docker image Development	35	9300	July 22, 2022

Can Discourse ship frequent Docker images that do not need to be bootstrapped?

Related topics