MKJ's Opinionated Discourse Deployment Configuration

I have been running a Discourse forum with a substantial amount of content and plenty of images over the past few years. Maker Forums has over 100GB of images and over 400,000 posts, of which a substantial amount was imported, primarily from Google+, and the rest was created on the site. This post describes elements of how I eventually configured Maker Forums and, later, a few other Discourse instances. This is what I wish I knew when I got started, and which I’ve used to help others avoid some of the same pitfalls for their own Discourse instances.

Time for a wider audience.

:warning: Warning: If you are not comfortable working as a Linux systems administrator, this guide is probably not for you. I may not even be aware of all the ways that it presumes knowledge about Linux. If this feels enlightening to read, you may be the target audience. If it feels confusing to read, you are probably not the target audience. If this feels like work, please consider paying CDCK or @pfaffman to run Discourse for you; they know what they are doing. :warning:

:warning: As if that weren’t enough: I have more Linux expertise than Discourse expertise. My opinions come with no warranty. If trying to follow my advice causes anything of yours to break (your Discourse forum, your host system, or your heart) you get to keep both pieces, with all the sharp edges. I have no plans to provide any form of support for the content in this post. :warning:

I plan (but do not promise) to keep this document up to date with my practices covering the Discourse instances that I participate in maintaining. This is written in the form of advice, but I intend it primarily as advice to myself and to any administrators who inherit Discourse deployments that I have been responsible for. Otherwise, you should consider it as one jumping-off point for your own research to determine how you would like to deploy Discourse.

System Setup

Use a CentOS-derived or Ubuntu LTS OS. Anything that supports Docker can probably be made to work, but I’ve used those two.


I’m a Fedora user. I was the first Fedora Project Lead at Red Hat, and I’d much rather run Discourse on top of Podman because I opine that its security model is preferable to Docker’s. However, Discourse deployments are supported only on Docker, and you will be quite a pioneer if you try to run on top of anything else. (It may, someday, work with Podman using podman-compose if docker-compose is ever supported.)

Now that Docker supports cgroups v2, you can install the official Docker builds on a CentOS-derived system:

dnf config-manager --add-repo
dnf install --allowerasing docker-ce docker-ce-cli

(Include --alloweraseing because of a conflict with podman, runc, and buildah that may already be installed; they need to be erased to install docker.)

systemctl enable --now docker

I have tested this with AlmaLinux 9.


This section really has nothing to do with Discourse per se, but it’s part of my normal security practice. Don’t allow password-only shell access to any system on the network, including a VM running Discourse. Set up SSH-based access using a passphrase-encrypted SSH key, and configure the ssh server on your VM not to allow password access.

laptop$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/.../.ssh/id_rsa):
Enter passphrase (empty for no passphrase): SOME LONG PHRASE
Enter same passphrase again: SOME LONG PHRASE
Your identification has been saved in .ssh/id_rsa
Your public key has been saved in .ssh/

Linux distributions are normally set up to remember the passphrase in memory, so you only have to type it once per boot. Windows is not as convenient; you might consider using Pageant with PuTTY to do the same.

First, validate that incoming SSH works without a password. Only after doing that, on the server, modify the file /etc/ssh/sshd_config and find the PasswordAuthentication line. Set it to no to disable incoming password access.

PasswordAuthentication no


You will need to leave ports 80 and 443 generally open for letsencrypt to generate and renew your SSL certificates, even before your Discourse is open to the public.

If you are using firewalld, these commands will accomplish this:

firewall-cmd --add-service http --add-service https --zone public
firewall-cmd --runtime-to-permanent

Separate device and file system

Make /var/discourse/shared a separate device with its own file system, with 20GB of space plus at least twice as much room as you need for images; add more space if you will be using prometheus. If the device will be easy to expand later (such as LVM or any cloud block storage like AWS elastic block storage) you can monitor and grow it as you need to; otherwise be generous at the start. If you are using a network storage block device, do not put a partition table on it. Using it without a partition table will make it easier to expand; you will not have to modify a partition table. In many cases you will be able to expand without any system downtime.

On Maker Forums, this is a network storage block device attached to the VM on which Maker Forums is running. On another Discourse forum, it is a Digital Ocean Block Storage Volume. In Amazon, this would be AWS Elastic Block Storage. On my test system running a KVM VM under libvirt on Fedora, it is an LVM volume on the Fedora host exported to the AlmaLinux VM as a virtual disk. In each case, I could create a new VM, copy key files across to it, stop the old VM, attach the /var/discourse/shared volume to the new VM, and be back up and running in minutes. This makes operating system upgrades on the VM relatively low risk.

Make sure that you start out with at least 25GB on the root filesystem for your VM, not including any space for /var/discourse/shared. This will be used for all the docker containers, and the discourse launcher will fail if less than 5GB is free at any time. You want plenty of space available for system updates, too. If you don’t have enough disk space, this is hard to recover from.

In site configuration, do set force_https but heed the warnings. Set it up in test, before taking a Discourse site public. Note that even with force_https you need port 80 open, both to redirect to SSL on port 443 and to renew your letsencrypt SSL certificate. (However, if you are using cloudflare, use its feature instead; it is reported to be not compatible with force_https in Discourse.)

Kernel configuration

Redis (one of the key components on which Discourse is built) strongly recommends disabling transparent huge pages when using on-disk persistence (which Discourse does), and I also allow memory overcommit.

echo '' > /etc/sysctl.d/10-huge-pages.conf
echo 'vm.overcommit_memory=1' > /etc/sysctl.d/90-vm_overcommit_memory.conf
sysctl --system

Discourse Installation

While the default installation is a single container, this makes every upgrade, recommended monthly, typically a 10-15 minute downtime if done from the command line, which is necessary for some updates, including those updating the tools on top of which Discourse is built, for security or new features, or when the live update from the UI fails for any reason. You can reduce that downtime in practice with the two-container installation.

Two-container installation

Start the configuration with two containers.

./discourse-setup --two-container

This makes required system downtime every few months quite short, rarely noticeable; many users won’t notice at all if they don’t click or scroll past content during the outage. This makes it easier to apply most security updates; it’s just a blip rather than approximately 15 minutes of rebuilding everything. The following process works for most updates and typically gives approximately 30-90 seconds of downtime, depending primarily on the performance of the host system and the set of plugins installed.

cd /var/discourse
git pull
./launcher bootstrap app
./launcher destroy app && ./launcher start app
./launcher cleanup

Do not delay between the bootstrap and the destroy/start invocations. Infrequently (maybe once or twice a year in practice), the database migrations done near the end of the bootstrap phase will cause more or less serious errors to present to users of the app, due to the older code accessing the updated database.

This does mean that when you update Discourse, you have to also check whether to update the data container as well, but this is rarely required (typically expect once or twice per year). Depending on the contents of your data and app containers and the speed of the system, this will typically result in a downtime between 5 and 20 minutes.

cd /var/discourse
git pull
./launcher stop app
./launcher rebuild data
./launcher rebuild app

For more on knowing when to update the data container, see:

(In my own deployments, I personally chose to call the web_only container app both because it’s easier to type and because it makes most instructions easier to follow. This is non-standard but I keep appreciating the ease of use. However, it was extra work, and it works for me because I know what is going on. If that sounds bad to you, stick with the default web_only instead for a multi-container deployment.)

Note that at some point in the future, Docker may force you to do a migration to a new configuration for connecting your containers:

If you have 4GB or more of memory, or multiple CPUs, read advice at:

Update Schedule

Watch the release-notes tag (Click on release-notes and click on the bell at the upper right; I use “Watching First Post”) and/or add to your RSS feed to know when there are releases. Read the release notes before updating. If there is a database change, the release notes will mention it. They will also call out releases that contain security updates. Read all release notes even if you skip actually updating to some version; if you don’t read the release notes for a release that updates the database, you might miss database update instructions in the release notes you didn’t read.


Mail is still one of the key ways to keep connecting people. Set up outgoing and incoming mail to make mail work for you. If you have trouble see:

Keep reaching out

Maker Forums has seen occasional visitors who are gone for long stretches before returning. By default, Discourse stops sending digest emails after a year. Consider setting the suppress_digest_email_after_days to something longer than the default 365 days if you want to encourage occasional visitors to come back when they see something new and interesting. I made it substantially longer for Maker Forums to support occasional visitors keeping up to date. Reading digest emails is a valid way to “lurk” on a forum, and you never know when something is going to spark someone’s interest in contributing.

Similarly, by default, unprivileged users who haven’t interacted much (trust level 0 with no posts) are eventually deleted after 730 days of not logging in. Set “clean up inactive users after days” to 0 to disable deleting users, if you want them to be able to lurk reading digest emails indefinitely.

Consider adding the yearly review plugin which once per year, will generate a post like 2020: The Year in Review and ultimately email it to your inactive users which may encourage them to renew participation.

Mail receiver container

Set up a third container as a mail receiver. It ensures bounce processing, makes your bounce processing independent of outgoing mail provider, and gives you the option of reply-by-email.

Make sure you have SPF set up for trusting your email sender; minimally, a policy like v=spf1 +mx -all if you send and receive through the same MX, but more specific may be better trusted as spam protection. Consider DKIM as well.

If you use the same host name to receive email, you should really terminate SSL outside your container as for an “offline page” (see below) and will need to map your certbot certificates into the container and restart the container after running certbot.

Terminate user SSL connections outside the container

There are two choices for terminating SSL outside the container, either of which brings substantial advantages over terminating inside the container. Set up one of them after you have successfully completed discourse-setup and bootstrapped your forum.

External nginx

Use nginx running on the host system, rather than only in a container, both to host a maintenance page, and to support IPv6 address logging if your host has IPv6 support. (Otherwise, all IPv6 connections will be logged as coming from an internal RFC1918 address associated with your local docker virtual network interface.) This configuration will present a temporary maintenance page during most maintenance operations that will eventually redirect back to the page a user was looking at.

Note that the instructions on that page (currently) suggest installing a package called letsencrypt but it is now normally called certbot instead. If you follow the instructions on that page to use --certonly, you will not need the nginx plugin for certbot, but installing the nginx plugin is another mechanism. On CentOS derivatives that’s:

dnf config-manager --set-enabled crb
dnf install epel-release
dnf install certbot python3-certbot-nginx
systemctl enable --now certbot-renew.timer

Make sure that certbot restarts nginx and the mail receiver container so that you do not end up with browsers or email blocking traffic with your site due to continuing to use an old, expired certificate.

# systemctl edit certbot

For a system without a mail receiver, I added the two lines:

ExecStartPost=/bin/systemctl reload nginx

On a system where I’m using a separate mail-receiver container that also shares the cert from the system:

ExecStartPost=/bin/systemctl reload nginx
ExecStartPost=/bin/sh -c 'cd /var/discourse && ./launcher restart mail-receiver'

If you are using SELinux, the Ubuntu containers aren’t set up to label the nginx.http.sock file with httpd_sys_content_t for external nginx to be able to access it. You have two choices.

The first is to run nginx in permissive mode, removing SELinux protection for it: semanage permissive -a httpd_t

However, that removes SELinux protection from what is probably the most relevant service! To keep SELinux enabled, you will need to allow nginx to access the error pages and switch from proxying over a unix domain socket to a port (which is a few µs slower, but should not be noticeable to your users).

First, run these commands to allow nginx to access error pages:

semanage fcontext -a -t httpd_sys_content_t /var/www
restorecon -R -v /var/www

Then in your app.yaml, comment out or remove the - "templates/web.socketed.template.yml", expose port 80 as a different port on the local machine and rebuild the container.

  - "8008:80"   # http

Don’t use https here — you have terminated SSL in the external nginx, and the X-Forwarded-Proto header tells Discourse that the request came in via https. Make sure that port 8008 (or whatever other port you have chosen) is not exposed publicly by your firewall settings.

Then run this command to allow nginx to connect over the network to the containre:

setsebool -P httpd_can_network_connect 1

Then modify your external nginx configuration from proxying via nginx.http.sock to (or your chosen port) and clear the default Connection: close header, so that the external nginx doesn’t have to establish a new IP connection for every request.

  location / {
    proxy_set_header Host $http_host;
    proxy_http_version 1.1;
    # Disable default "Connection: close"
    proxy_set_header "Connection" "";

Removing web.socketed.template.yml also removed the real_ip invocation, so add that back. Make sure that the IP address range you use makes sense; Docker’s default is to use the 172.* RFC1918 address space. Add to your app.yml file something like this:

  - replace:
     filename: "/etc/nginx/conf.d/discourse.conf"
     from: /listen 80;/
     to: |
       listen unix:/shared/nginx.http.sock;
  - replace:
     filename: "/etc/nginx/conf.d/discourse.conf"
     from: /listen 443 ssl http2;/
     to: |
       listen unix:/shared/nginx.https.sock ssl http2;

This is required for rate limiting to work correctly.

External service

I have not configured Fastly or Cloudflare in front of Discourse, but others have, and unlike external nginx running on the host, they can allow you to serve a maintenance page while the host system is entirely down, such as when rebooting during a system update on your host. If this is worthwhile to you, here’s how to do it:

Don’t rush to S3 uploads

Be very sure you always want to use S3 (or equivalent) for uploaded images before you enable enable_s3_uploads during setup, or migrate to it later. Be aware that using S3 (s3_endpoint) with its associated CDN (s3_cdn_url) for images will also result in serving javascript via that CDN. Migrating from S3 back to local storage is not supported and there are no concrete plans to implement it at this time. It’s a “one way door” that can’t even be undone by a full backup and restore. If you do use S3 or similar, don’t use Digital Ocean Spaces instead of S3. There are references here on meta to it not being reliable.

I moved my site to serving images through Digital Ocean Spaces and its associated CDN early on, and I had to write hundreds of lines of custom code to migrate back to local storage, doing minor damage to my Discourse instance in the process, due to the “one way door” not being well understood.

For more information:

You do not need to enable S3 uploads to use a CDN for your Discourse. Consider using an independent CDN (e.g. Cloudflare, CloudFront, Fastly, GCS CDN) in front of a Discourse that manages its own images. It is my second-hand understanding that the warning about Cloudflare not being recommended is due to “Rocket Loader” modifying JavaScript; and that at this time, as long as you don’t use “Rocket Loader” it functions correctly.

Discourse settings for moderation

On any site where moderation is active, strongly consider the enable_whispers configuration that allows moderators and administrators to talk about a topic in line. Also, category moderators have been given more abilities in recent versions of Discourse. It is worth being aware of enable_category_group_moderation if you have experts in different topics with their own categories, or if you have functionally separate categories such as for support.

Geolocation can be helpful when trying to understand whether an account is legitimate.

The Discourse Templates plugin is really helpful for moderators. It lets you collaborate on common responses. We have a few dozen at Maker Forums. It has more features than the prior “Canned Responses” plugin that it replaces.

The User Notes plugin will help moderators share notes about users. You can put these to use for things like:

  • “Keep an eye on this user, they may be malicious because …”
  • “While this behavior seems suspect, I have validated that this is a legitimate user by …”
  • “I’m already having a conversation with this user to address concerns, other moderators don’t need to pile on.”

Information Accessibility

The Discourse Solved plugin not only marks solved problems so that site visitors can identify them more easily, but I understand might also prioritize google search results.

Public information is more accessible than private information. On Maker Forums, our FAQ strongly discourages personal messages and reminds everyone that personal messages are not truly private. However, by default, users may see the message:

You’ve replied to user 3 times, did you know you could send them a personal message instead?

If you really want to encourage users to go to personal messages, I suggest that you go to Admin → Customize → Text and change the get_a_room template to fix the comma splice.

If, like Maker Forums, you want to keep conversation in public to benefit everyone, Admin → Settings → Other → get_a_room_threshold can be set higher, like 1000000.

Similarly, if you have a forum providing help, the max_replies_in_first_day default 10 might push new users in a conversation asking for help into personal messages when they use up their budget of replies. Consider increasing this setting to avoid pushing conversations into personal messages.

Connect users, build a community

A few plugins can help connect users to each other.

If your forum doesn’t have too many simultaneous users, consider the Who’s Online plugin to give people more of a sense of connection. You might want to limit display to logged-in users, possibly only those who have reached at least trust level 1. You can use it only to add presence flair (whos_online_avatar_indicator) to avatars by setting whose_online_minimum_display very high and whos_online_hide_below_minimum_display true. This can be useful for support forums to support and encourage quick question and answer while helping users resolve problems.

However, a sense of presence can cut both ways. A user who is online at a different time from the majority of forum users might feel lonely, or the forum might feel like a “ghost town” to them.

If you have users in many countries and want them to have hints about when each other are more likely to be available, consider the National Flags plugin, and encourage users to set a national flag in their profile.

A tricky one is translation. It would be convenient to help people communicate when they don’t speak the same language, but currently (as of this writing) there are no translation services with free tiers of service. If you choose to pay for translation services, you can enable translation with the Discourse Translator plugin.


For system files, consider backing up at least:

  • /var/discourse/containers (for discourse configuration details)
  • /var/www (for error pages)
  • /etc/ssl (for letsencrypt config, to avoid having to bootstrap certbot as part of restoring a backup; otherwise you have to comment out the SSL portion of your nginx configuration while you are bootstrapping; this works only if you keep the backups recent because the certificates have short validity)
  • /etc/systemd/system/backup-uploads.service (for doing images backups to S3)
  • /usr/local/bin/mc (minio-client as image backup tool, if you choose to use it)
  • /root/.mc (configuration for image backup with minio-client)
  • /root/.ssh (incoming SSH session authentication)

Some of these files you may back up by checking them into Git and pushing them somewhere off site. If the files you check into Git include secrets (like database passwords), definitely don’t push them to a public repository. Alternatively, you could script copying them off the system and checking them into Git on a supervisory system that you control. Script this sufficiently frequently to keep your backups of /etc/ssl fresh.

The goal is to have backups both in case of disaster and to have record of changes in case of mistake.

A better alternative for most of these files is to keep the canonical copies elsewhere, and use a tool like Ansible to maintain the configuration on the system, which makes it just as easy to update after a backup. But if you are going to do that, you probably figured it out without me telling you!

Discourse Configuration for backup

  • Back up thumbnails with include_thumbnails_in_backups. A restore without thumbnails takes a long time to regenerate them. If your site doesn’t have many graphics, the thumbnails take insignificant space. If your site is graphics-rich, regenerating thumbnails could take days. While thumbnails are being regenerated, email notifications will be disabled. Either way, it makes no sense to omit thumbnails from backups.

  • Do not include images in backups if you have lots of images. This will make backups slow and unwieldy. Back them up separately. If you back up images after your database backup, your backups will be consistent.

  • Arrange for backups to go off site somehow.

This page shows how to set up database backups to S3 or something like S3:

While database backups can be stored to S3, there is no S3 image backup separate from serving images from S3. An alternative is to use minio-client to copy images to any S3-like storage. This can be many S3-like targets, including S3 and minio, but not DigitalOcean Spaces because it is built on top of the Ceph filesystem which does not implement the ListObjectsV2 API the same way that S3 does.

In S3, create a bucket that blocks public access (PermissionsBlock public access is the easy way to get this right in AWS).

Install minio-client (mc) somehow. Here’s one way.

curl > /usr/local/bin/mc && chmod +x /usr/local/bin/mc

Configure minio-client with an alias called backup using a command something like this:

# mc alias set backup ACCESSKEY SECRETKEY --api S3v4
# mc mirror /var/discourse/shared/standalone/uploads backup/UPLOADS-BACKUP-BUCKET

Then create a service /etc/systemd/system/backup-uploads.service like this

Description=Neartime remote backup sync of discourse uploads

ExecStart=/usr/local/bin/mc mirror --overwrite -a --watch /var/discourse/shared/app/uploads backup/UPLOADS-BACKUP-BUCKET


Note that UPLOADS-BACKUP-BUCKET here should be a different bucket from the s3_backup_bucket into which you configure discourse to upload database backups. Also, note that the path will be /var/discourse/shared/web_only/uploads if you use the standard multi-container deployment.

# systemctl enable backup-uploads
# systemctl start backup-uploads
# journalctl -fu backup-uploads

Upload a test image and make sure you see lines for successfully backing up the original and optimized images. Control-C will exit follow mode in journalctl.


I have never had to test this plan as of this writing. This summary might miss something.

  • Restore all backed up files generally
  • Start nginx (now your maintenance page will show)
  • Do a normal deployment of Discourse using the restored files in /var/discourse/containers
  • Install minio-client in /usr/local/bin/mc if you didn’t restore it from backups
  • If you did not back up /root/mc, set up the backup alias # mc alias set backup ACCESSKEY SECRETKEY --api S3v4
  • # mc cp backup/UPLOADS-BACKUP-BUCKET /var/discourse/shared/app/uploads
  • Restore the most recent database backup; I recommend that you Restore a backup from the command line
  • Only after you have confirmed the site is operational, re-configure backing up uploads to S3 as documented above.

Streaming postgresql backups

In the future, I may create, test, and provide a configuration to enable using continuous WAL archiving to stream near-instantaneous Postgres backups with minio-client using the archive-command in postgresql, similar to streaming uploads backups.

Performance monitoring

There are at least two approaches to performance monitoring.

Prometheus container

Set up prometheus, putting prometheus logs in /var/discourse/shared/prometheus if you are running it on the same system. Prometheus files can grow large, and you do not want them to fill up the root file system; you also probably want to bring them along if you move to a newer host system (either upgrading to a larger VM or a VM with a newer operating system installation).

If you deploy prometheus on the discourse system (or anywhere else on the public internet), configure security in front of it. Installed that way, one option would be nginx configuration like this:

  location /prometheus/ {
    auth_basic "Prometheus";
    auth_basic_user_file /etc/nginx/prometheus-htpasswd;
    proxy_pass http://localhost:9090/;


If Prometheus is too much, consider using sysstat instead.

  • apt install sysstat
  • In /etc/cron.d/sysstat change 5-55/10 to */2
  • In /etc/default/sysstat change false to true

After this, the sar command can tell you if you are running out of resources from time to time.

Other Resources

Here’s a complementary (and more compact) discussion of using Discourse internally as a primary form of internal communications.


Hi, thank you for this howto

What are your current CPU (cores) and RAM?
What are your current settings:

  db_shared_buffers: "xGB"
  db_work_mem: "xMB"

2 vCPUs (L5640 Xeon), 4GB RAM — but thanks to the massive import we have larger content per simultaneous user than typical Discourse that has been built entirely organically. We rarely have more than 5 simultaneous users.

I have not currently set db_work_mem in data.yml but it looks like it’s set to 10MB in /etc/postgresql/13/main/postgresql.conf. In my data.yml I have set db_shared_buffers: "768MB" but now I see that /etc/postgresql/13/main/postgresql.conf in my data container says shared_buffers = 512MB which surprises me. Apparently I didn’t rebuild my data container after my last change. :roll_eyes: I made the configuration change before adding prometheus (using more memory) so before I change that I will probably move prometheus off that server instance.

In the app, I have set UNICORN_WORKERS: 4

1 Like

thanks @mcdanlj for all these goodies. Any advice on periodic/scheduled maintenance? like weekly/monthly restarts? or up/down monitoring with automatic restart? Any other periodic manual or automated maintenance?

1 Like

@jaffadog Watch the release-notes tag (it’s the bell at the upper right; I use “Watching First Post”) and/or add to your RSS feed to know when there are releases. This is typically monthly for the app, which covers monthly restart. I don’t restart more frequently on a schedule. Also:

If you use letsencrypt and mail_receiver, you probably should set it up to restart mail_receiver after getting a new cert.

That’s all that comes to mind at the moment. Thanks for asking, and I incorporated how to watch release-notes and more specifics on restarting into the main text. I think that it’s all now fully covered in the original post.

I augmented the update instructions to pull updates in /var/discourse in order to change the base image version, because in looking at Update base image for polkit vulnerability I realized not being explicit about this step might be misleading. I was previously thinking of it as one of those things that’s part of the baseline documentation. The launcher script contains a specific reference to the base image version, and until you git pull you will be building on top of an older base image, and not be running what has been tested. (Look for image= near the top of the file.)

1 Like

It’s worse than that: it’s configured by default to delete inactive level 0 accounts after some period. In my case, that was really not what I wanted! Check “clean up inactive users after days” and set it to zero, or a really large number.


I looked at that, but as far I understood it means that they never responded to the “confirm your email address” flow and so wouldn’t be getting emails anyway. I don’t think “inactive” here means “not logging into the site” but would like to know whether I’m wrong.

No, “inactive” does not mean active=false here.

It means users where all of the below apply to:

  • trust level 0
  • no posts
  • not an admin, not a moderator
  • last seen longer than X days ago.

And yes, that wording is indeed confusing, although the setting does explain it somewhat (“trust level 0 without any posts”).


Actually I was confusing different settings and had " clean up unused staged users after days" in mind. I had already set “clean up inactive users after days” to zero in Maker Forums long ago, and had failed to mention it here; I must have missed it in my audit of changed site settings when I was looking for things that might be of general interest. Thanks to both of you, @Ed_S and @RGJ! I have updated the post with another paragraph on enabling lurking. :relaxed:


Hi @mcdanlj thanks for your excellent insight that you share here. Regarding a 2-container installation, I’m confused about how that gives an advantage in reducing downtime when upgrades are performed. On my test installation, an upgrade via the GUI /admin/upgrade#/upgrade/all interface does take several minutes as you describe, but the site remains operable for users during the whole process.

When you have to rebuild from the command line the two container installation let’s you bootstrap the new image while the old one continues to run.


As usual, @pfaffman is quicker than I am, and knows his stuff. :smiley:

I never do upgrades from the GUI. That way every time I update, I will include any system security updates in the underlying containers on top of which Discourse is running. That’s saying it’s bad to use the GUI, nor is it a recommendation for everyone else. The GUI update have slightly lower downtime (restarting the web container does bip service momentarily, which one of several reasons to consider this together with external nginx) so it’s a trade-off, and I have taken the road less traveled.

A single-container installation has longer outages more often, if you regularly update for security updates as well as the occasional database version updates as Discourse takes advantage of new Postgresql features. Without reviewing actual data, my gut feeling is that there’s a reason to rebuild that 3-4 times per year. If that amount of downtime is OK from your perspective, there’s not a lot of reason to take on the complexity of the 2-container deployment.


That’s very kind, but this is about your opinions. :wink:

Me neither. Except with my dashboard, that has a bunch of extra stuff in the container (like Ansible, and I can’t remember exactly what all), and if someone is running an upgrade using and then I destroy that container, their rebuild gets terminated, which is potentially problematic. So I’ve been doing a few more docker_manager upgrades lately, and they are pretty darn slick.

Not really. It’s at least mostly the case that if there’s a new base image docker_manager will force you to get it (at least, it’ll try).

That’s about right. FWIW, and I don’t recommend it, but I’ve interacted with a bunch of people who did zero upgrades for years without any problems.

Yeah, there’s no question that the in-container updates are well implemented!

Yes, that’s what I meant. :tada:

1 Like

Hi again, thanks to both of you for your insight. So I’m still trying to decide what I’m going to do for my production setup. I understand in theory why a 2-container installation would lead to less downtime. But I’m still seeing hardly any downtime with the GUI update mechanism. I just now timed it, I had a docker-manager update and Discourse was 22 commits behind. The whole process took under 5 minutes and during the whole process the forum was fully operable. Granted there were no PostgreSQL updates this time, but if it were necessary to update that too then I would be looking at the maximum amount of downtime even with the 2-container method, correct? So if I’m understanding correctly, the 2-container method only reduces downtime when an SSH login and app container rebuild is necessary due to a configuration change (add/remove plugins, etc.)? I don’t foresee frequent changes to my production configuration, so I don’t see any potential reduction in downtime in my case. Or do I also need to SSH in and rebuild the containers to apply certain kinds of feature/security updates?

That’s fine.

Yes, you have the full downtime every time you update postgresql (every year or two I suppose, plus and security updates to PostgreSQL itself, not that they have been that frequent).

Before I changed, I had a couple of failures doing the GUI updates, but no longer remember the details; ancient history.

The GUI updates do not update the base image, so all security updates in the provided software, like image processing, won’t be applied there.

I like rebuilding the app container fast as my normal mode to consume security updates to the app container when available so that I would never put that off for a 10-minute downtime to rebuild everything. That’s why git pull in the launcher is part of the first part of me applying every update; so that if the base image with things like image processing programs has been updated, they get applied without me even having to think to ask whether there are security updates to apply. :smiling_face:

But ultimately, I personally find the two-containers approach simpler for me, and I absolutely am not trying to talk other people into it. If it doesn’t seem simpler to you based on your knowledge and experience, do not do it just because my personal opinionated guide identifies it as useful in a certain context. :grin:

1 Like

Gotcha! :wink: I tend to have strong opinions on tech implementation details too, but I appreciate your additional perspective.

Hmm, so is this still the case?

At any rate in my experience with traditional forums installed without containerization on a LAMP/LEMP stack, the typical vulnerability / attack vector that leads to real-world compromised websites is almost always in the web app’s code or in one of its web development frameworks. So I tend to have more of a sense of urgency toward updates to the Discourse codebase, which appear to be handled by the GUI, so I guess I’m leaning that way.

By the way, on the subject of downtime, a quick plug for Clear Linux: I started testing it due to its low-level optimizations at pure number crunching to try to shave a few hours off my huge forum import process. There may indeed be some speed improvements for that case, but in general, holy mackerel, it’s crazy fast at rebooting, especially as a KVM guest. On the cheapest tier VPS I can reboot and log back into SSH in barely 5 seconds. So I’m looking forward to using that when there are important host OS updates.

Yes. But a few times a year you must to a command line rebuild because some component in the container has been updated. And then you’ll have the 5-15 minutes of downtime. I pretty much only do upgrades from the command line (except on my dashboard where I might update just the dashboard plugin several times in a day), and I have a bunch of customers for whom I do those command line updates when they are required (presumably they are doing updates via the web interface, but often they don’t).


Does the Discourse dashboard notify specifically about that sort of required update? Or should I keep an eye on Debian’s PSAs?