Is Docker image discourse/discourse considered safe and production-ready?

Hi Discourse team,

We’re currently evaluating the Docker image available here: discourse/discourse - Docker Image

This image was published very recently (less than 24h ago at the time of writing), and I couldn’t find references to it in the official documentation.

My question is:

• Is this Docker image officially maintained and supported by the Discourse team for production use?
• Or is it an experimental image that might be removed or changed unexpectedly?

We want to confirm whether it’s safe to rely on this image in our production environments.

Thanks

I believe the Docker image is discourse/base - Docker Image. (5M+ downloads vs 800+) See:

The Docker repository will always contain the latest built version at: discourse/base - Docker Image, you should not need to build the base image.

Thanks for your reply, I know that. But I couldn’t get that discourse/base image to run easily with Docker Compose. This new discourse/discourse image makes setup much simpler and just works fine, but I want to understand its purpose and whether I can use it in production.

Take a read of:

discourse/discourse is new, but still experimental, so I wouldn’t recommend using it in production. We’ll certainly publish more info if/when that changes, and it’s ready for use.

As of right now, the only method we can support is the standard install.

As described, the Supported way to self-host is to follow the standard install. If you don’t want to do that then you’re sort-of on your own. If you want to launch with docker-compose, what I recommend is to use launcher to build your image, push it to a repo of your own and then use `./launcher start-cmd web_only’ to get the necessary ENV variables and such to launch it. And you’ll still need to do something to see that the database is migrated, assets precompiled, and so on.

You can also contrive to get github to build images for you and have them migrate and so on when launched (as will one day be provided by CDCK, it seems). I’ve done this for clients in the past. (Happy to help if you have a budget.)

If you like to live on the edge, you’re probably pretty safe using the “experimental” version with the caveat that you’ll need to have a staging site where you test each new deployment before pushing it to production and being prepared to either need to wait a while and/or do something that requires deep knowledge of discourse to move forward. A worst case (probably) is that you’d need to be prepared to make a backup and restore to a standard install until the experimental thing is ready for prime time.

Do you have an estimated release date or timeline for when discourse/discourse might be considered stable/production-ready?

Additionally, I would like to confirm: Is the discourse/discourse Docker image open source, and if so, could you provide the GitHub repository link?

I don’t have any timeline/guarantees right now. But hopefully we’ll have more info to share in the next few weeks.

Yes it’s all open source. It’s built & published regularly by this github actions workflow: discourse_docker/.github/workflows/push-web-only.yml at main · discourse/discourse_docker · GitHub

Thanks for the info and for sharing the GitHub link, much appreciated!

Yeah, it’s becoming an open secret of what’s in the oven

You can get a technical preview of what’s upcoming, but like David said we can’t support it officially yet. There are tons of docs to plan, edge cases to test, etc… so we can’t recommend it for production until we smooth those things out.

@david / @featheredtoast, you guys and the rest of the team have done a great job here.

I just switched to discourse/discourse from bitnami/discourse for automated testing and it’s working great. Obviously my use case is perfect - spin up a new forum, run tests, delete.

So, just wanted to give a big thanks. I’m sure a lot of others will benefit from this too especially once it becomes stable / official / supported.

Similar situation, was looking for a quick way to spin up Discourse in a Docker Compose setup to make it easier for developers to build an SSO integration. This appears to work a treat (setup below for those who are interested):

volumes:
  redis_data: {}
  discourse_data: {}
  discourse_postgres: {}
  discourse_postgres_data: {}

services:
  mailpit:
    image: docker.io/axllent/mailpit:latest
    container_name: mailpit
    ports:
      - '8025:8025'

  redis:
    image: redis:7-alpine
    container_name: redis
    volumes:
      - redis_data:/data
    ports:
      - '6379:6379'
    command: redis-server --appendonly yes

  discourse_db:
    image: discourse/postgres
    container_name: discourse_db
    volumes:
      - discourse_postgres:/var/lib/postgresql
      - discourse_postgres_data:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB: discourse
      - POSTGRES_USER: admin
      - POSTGRES_PASSWORD: admin_password
      - DB_USER: discourse_user
      - DB_PASSWORD: discourse_user_password

  discourse:
    image: discourse/discourse:3.5.1
    container_name: discourse
    depends_on:
      - discourse_db
      - redis
      - mailpit
    ports:
      - '80:80'
    volumes:
      - discourse_data:/shared
    environment:
      - DISCOURSE_HOSTNAME: localhost
      - DISCOURSE_DEVELOPER_EMAILS: admin@example.com
      - DISCOURSE_DB_HOST: discourse_db
      - DISCOURSE_DB_PORT: 5432
      - DISCOURSE_DB_NAME: discourse
      - DISCOURSE_DB_USERNAME: discourse_user
      - DISCOURSE_DB_PASSWORD: discourse_user_password
      - DISCOURSE_REDIS_HOST: redis
      - DISCOURSE_REDIS_PORT: 6379
      - DISCOURSE_SMTP_ADDRESS: mailpit
      - DISCOURSE_SMTP_PORT: 1025
      - DISCOURSE_SMTP_ENABLE_START_TLS: false
      - DISCOURSE_SMTP_AUTHENTICATION: none
      - LANG: en_US.UTF-8

Looking forward to hearing about future plans or timelines, would love to be able to run this in something like Digital Ocean App Platform (something that clients could manage with less technical know-how).

Ah thanks for sharing, @JackNZ . I didn’t even notice the discourse/postgres image I’ll have to fix that. Nevertheless, I’ll share where I’m at too. Maybe more interesting is the start.sh script here that, while in need of some cleanup, will create an admin user, API key, and disable rate limiters.

really thanks for the `bitnami/discourse` information, I use the official way to install on a restricted network, it is quite painful. I will try the bitnami/discourse one. thank you!

A hint in case you need help

Bitnami is no longer supporting those. Upcoming changes to the Bitnami catalog (effective August 28th, 2025) · Issue #35164 · bitnami/charts · GitHub

I would try the not-yet-supported stand alone discourse images. I’ve seen reports of them working well.

will try the discourse/discourse, thanks for your kind reminder.

Is this close to being production ready now? If not, is there a roadmap/indicative dates of when it will be?

Great work BTW - will make managing new releases a lot easier with a simple image tag update

There’s some internal updates going on in our hosting that turned out to be unforseen dependencies. Those need to be resolved before I’ll be able to push to have it marked for official support, but I suspect the last blockers here are planned to be resolved this quarter. It’s been a long road.

In the meantime, all of my sites I’m hosting are done through the discourse/discourse docker image and it’s been working out here.

thanks for the work here @featheredtoast! Is it possible to install additional plugins into the discourse/discourse image? How does the process look like for that?

Hello !
I registered just to say thanks a lot to all for your help, particularly @featheredtoast
I almost got it to work, but the mail sending wasn’t working.
I suppose it was because I have caddy as a reverse proxy.

So now I’m back to using discourse separately from all the other services on my docker compose setup.

Do you know how I could make it work with Caddy ? I suppose I have to make it use a socketed example, but I don’t know how to modify the app.yml inside the docker-compose discourse config.

All the best to you - Y

Unless you’re somehow having Caddy proxy your outgoing email, I don’t think it’s related.

You don’t have to make it socketed, you can just refer to the docker name and/or IP. Discourse working with jwilder /nginx proxy & acme-companion - #7 by Steve_Emerson talks about using the socketed template and a bunch of other stuff.

So, short answer, no, not through docker-compose on its own – it’s something I’d like to see, but the plan here is to allow anyone to create a customized base image that can be shared publicly to push the ball forward. Building a plugin involves cloning the plugin, bundle install, npm, and recompiling ember… This should not be done on boot.

So part of the idea here is to allow images to build just as discourse/discourse is – with the same app.yml as the supported Discourse versions are running.

As a sample, I’m building my personal image with resenha by updating the core app.yml to include the plugin here and then pushing it up to an external (public!) docker registry.

If you’re using an external mail service, I don’t think your caddy reverse proxy probably isn’t the problem. Unlike the current launcher builds, discourse/discourse will not nag you about setting up your email env vars (but it’s still necessary to do) – I’d check those first.

I have managed to change the upload size limit:

cat fix-upload-size.sh (which needs to be chmod +x):

#!/bin/sh
sed -i 's/client_max_body_size .*;/client_max_body_size 500m;/' /etc/nginx/conf.d/discourse.conf

in docker-compose.yml:

    volumes:
     - ./fix-upload-size.sh:/etc/runit/1.d/fix-upload-size

I’ve been able to build an image but “only” using the ESR version. When I use something newer than that, the build process does require a database and a redis instance. Is that intentional?

Is there any way to upgrade Discourse to the latest version when using this image?

I’m using it for my faculty’s research group forum and would like to update to the latest Discourse release, but the image hasn’t been updated since March. What would be the recommended way to upgrade?

That was an unintentional side effect of adding a call to clearing stuck web upgrades; I’m looking to resolve this soon via FIX: run clear_stuck_web_upgrades during precompile stage · Pull Request #1055 · discourse/discourse_docker

Awesome, thank you!

But I have another question, I’m using Azure for students and I am using Container Apps. If I somehow upgrade inside the app, I’m afraid that if the instance Discourse is running fails for some reason, it may render our forum in disarray, because when it restart it will probably be in a previous version.

Once again Thank You!

That is a risk - there’s unfortunately no good way around that other than making sure the image is up to date if you’re upgrading both in the app and updating by pulling images from the docker repo. I really wouldn’t recommend doing so.

Meantime, I’m still getting the docker repo sorted (there’s another issue to tackle here).