Yeah, I would do it in stages:
- get a slightly more powerful server
- get the two container installation working
if at this point you are satisfied, stop here, or:
- implement the maintenance page using @Lilly’s excellent guide above.
haha i am glad you asked because i did not take the time to explain this part (i should have - there is a lot to explain and Cloudflare is complex!)
when the workers route page is set, every single image load and page view on the forum is routing through that worker.
the Cloudflare free CDN plan includes free 100,000 requests/day limit on a worker route.
thus, if you have a relatively busy forum, in order to prevent hitting your free tier cap in a day it is a good idea not to have it on all the time.
so this is just the worker route, not the maintenance page - you can leave the maintenance page up the whole time - it does not get hit unless you have the worker route on it. this is just that Step 2 part where you assigned the route (which is easy to setup and delete). unless you are using a cloudflare paid plan, it is thus good practice to only have it on when you are doing your own maintenance.
- go to the Cloudflare workers route page for your domain and click the button on the right side of the route.
- at the bottom of the edit screen, click the
removebutton to detach the worker page from the route.
- don’t worry, the worker code itself won’t be deleted, just the routing rule. then next time you do your rebuilt / update, you can just add it again like in Step 2 above.
if you are on a paid Cloudflare plan then you have nothing to worry about. However, then you can use the Cloudflare error pages instead of a workers page… (did i mention that Cloudflare is pretty complex? LOL)
my general steps are:
- add the workers route on Cloudflare
- ssh into hetzner
- do any system updates (eg:
sudo apt update && sudo apt upgrade -y), then reboot the server if necessary (i useshutdown -r nowto do a full shut down and restart) - ssh in again if i needed to restart my server
- run
./update-web.sh - once the shell script is complete and my forum loads again, i remove the workers route on Cloudflare
I do not know coding and dev-world at all more than I did one hello world thing with Visual Basic long long time ago. But I can do some things, because I know better how to admin my WordPress and Mastodon/Pixelfed servers, and somehow my Discourse. Plus out there is thingy named AI (that isn’t such easy for a novice than is advertized).
I don’t know if this is even remotely possible with Discourse because of Docker, but in ordinary Nginx-Varnish-WordPress world I build a system where a plesk server gets information of 50x error and shows an error page. Actually I have three setups, where frontend nginx shows generated snapshot content if Varnish is down, Varnish starts use snapshot for uncached content when WordPress-related backend is down and third one is error page if frontend nginx doesn’t answer.
Varnish things aren’t possible for Discourse, but I can’t see any reasons why one couldn’t build such spiderweb into Docker-world too where any 50x error would show an errorpage.
That could be very error prone system though. And I have no idea what so ever what would happend if there is more than handful users.
There is the most obvious answer too, of course: has i.e. Nginx before Discourse. I used that before I moved on to 2-container.
I finally took the time to install Discourse again. After evaluating where I am right now, and how much maintenance two containers seem to require, I believe I will stick to one for now, and if I need two containers in the future, I will revise everything being said here. Other than installing plugins, which doesn’t seem to be something I will need to do as often as managing components, the community being down for 20 minutes on a period of the day where fewer people are online, along with a banner letting people know that the community will be down a certain day and time, seems pretty reasonable for now.
Let’s see how it goes
It requires as much as single container 
And less heart ache 
Can you clarify how that goes?
Not sure if you were replying to me or to @Jagster? What do you mean?
Because the process of bootstrapping the new container whilst your site remains online is much less stressful - if the build breaks you don’t have to panic and have all the time it takes to fix it without remaining offline.
Ok so you are encouraging having both, hence the “less heart ache”.
So, as non experienced person when it comes to this, having 2 containers doesn’t mean two instances of Discourse, I believe?
I’m reading the topic
and
to see if I can understand how much work it requires, and attention I need to have, so I don’t end up with something I can’t manage, making the process more problematic than all the other things that can go wrong with just one.
Just want to praise sharing about the two containers setup. I was using one and it usually takes 3-5 minutes (on a dedicated server with 64GB of RAM).
May I know, in clear and simple examples, when one should update both containers in a dual installation? I mean, which Discourse upgrades should restart both of them and which only the newly created web_container?
First you follow very simple instructions how to start 2-container. After that you mostly need only
./launcher bootstrap web_only && ./launcher destroy web_only && ./launcher start web_only ) 2>&1 | tee ~/$(date +%Y-%m-%d_%H-%M-%S)-upgrade.log'
tee part is only for logging, because browsing it is easier (for me) than tmux feed I’m using.
But basically it is totally same than using app.yml and rebuild, except it bothers users much less. Sure, there is data-container, but it needs love and caring very rarely — and if you will do some more sophisticated tricks with container, you propably know what to do and when with containers too.
If upgraiding fails with 2-container you have still a forum up and alive, when single one will crash.
So, only starting is a bit more demanding, but instructions are quote clear. I would say using mail-reveiver is more harder task, if using Amazon SES.
For example, this is the kind of comment that I can’t simply ignore, because it seems that updating/upgrading stops being as simple as clicking a button, but something that needs more focus and attention, which to an experienced person may seem easy and obvious, but maybe not for someone who’s not:
Would you say that the instructions in this topic are still accurate in 2026, since that one was from 2015?
I don’t mind trying it, since I just installed Discourse today again. Anything going wrong, I can just go back to one container. I just want to make sure that halfway through, I don’t do something that is no longer accurate in 2026…
Few minutes saving for me is more than 20 minutes. Once per month is true if upgrading once per month, but I am doing upgrading at least twice a week. And if some plugin has failed and must do several tries (because of course we are working with live instances 
) then that long downtime is just pain.
There is no details in the announcements every new release to follow. Mcdanlj may have, but he isn’t an ordinary sysadmin but works on much higher level.
I’m confused…
While you say:
then your reply above this one makes it sound that there’s more work, when you say:
That alone, makes it sound like two containers is indeed more complex to maintain, not the same as one? Sure, the down time and all, I get it, but the maintenance of the containers themselves, seems more complex and more prone to errors, than a simple upgrade with one container. Or am I missing something?
that’s correct:
Container 1 = website & nginx
Container 2 = database and redis
(I think I have this right)
Container 1 stuff changes a lot
Container 2 stuff very seldom.
And you can update container 1 without updating container 2.
And even better, you can prepare a replacement for container 1 and then swap it over in a few seconds (the preparation is called “bootstrapping”)
You are missing that with single container ./launcher rebuild app kind of web and data is stopped, both are upgraded, but dataside needs it very rarely, and after the job everything is started if there isn’t any issues.
With 2-container you rebuild only ”web”, no data container, then if everything went smootly it will destroy old container and start new one. If something bad happens, then your old and functional ”web” is still in use.
So, only actual difference is how to deal with softwear and couple other things of database.
Sure, 1-container setup is an option too, of course. But the main point is when 2-container is created the only real difference in the name of difficulty is used command when upgrading — and for that there is alias
That was written in the old days of hand-written announcements that would say something about it being time to update the database now. The new automated site is flashier, but there’s no human note about what’s actually most important like there used to be.
Today I guess you have to notice a post that the database is getting an update? I seem to have missed those for months.
However, this happens once every few years, and it gets rebuilt when you explicitly rebuild the DB, and CDCK seems to have preserved compatibility with older versions of pgsql for a while. So it’s never really bit me. So far.
I really like the two-container (or more!) setup for myself, but I still caveat it because it’s not easiest for everyone. It’s hard for me to judge for whom two container deployment will feel like “of course, that’s simple” and for whom it will be “ugh, I just want to press a button”.