# Maintenance page workaround - can this be done?
**URL:** https://meta.discourse.org/t/maintenance-page-workaround-can-this-be-done/408967
**Category:** Self-hosting
**Tags:** cloudflare
**Created:** [July 31, 2026, 8:22am UTC](https://meta.discourse.org/t/maintenance-page-workaround-can-this-be-done/408967 "2026-07-31T08:22:23Z")
**Posts on this page:** 20
**Page:** 2
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [August 1, 2026, 7:46pm UTC](https://meta.discourse.org/t/maintenance-page-workaround-can-this-be-done/408967/22 "2026-08-01T19:46:07Z")
Yeah, I would do it in stages:
1. get a slightly more powerful server
2. get the two container installation working
if at this point you are satisfied, stop here, or:
1. implement the maintenance page using @Lilly’s excellent guide above. 👍
---
### Author:  [@Lilly](https://meta.discourse.org/u/Lilly)
#### Post date: [August 2, 2026, 1:19am UTC](https://meta.discourse.org/t/maintenance-page-workaround-can-this-be-done/408967/23 "2026-08-02T01:19:03Z")
> [@alltiagocom](#):
>
> Why do you add and delete workers route page, if leaving them is not an issue? So, if I do add the maintenance page, can I really just set it up once, and from that moment on, I always just SSH my server via Terminal and do everything there like I do with a single container, without ever having to go to Cloudflare?
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](https://developers.cloudflare.com/workers/platform/pricing/#workers).
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](https://meta.discourse.org/t/maintenance-page-workaround-can-this-be-done/408967/6#p-2017547-step-2-add-the-route-2) (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.
1. go to the Cloudflare workers route page for your domain and click the button on the right side of the route.
1. at the bottom of the edit screen, click the `remove` button to detach the worker page from the route.
1. 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](https://meta.discourse.org/t/maintenance-page-workaround-can-this-be-done/408967/6#p-2017547-step-2-add-the-route-2).
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:
1. add the workers route on Cloudflare
2. ssh into hetzner
3. do any system updates (eg: `sudo apt update && sudo apt upgrade -y`), then reboot the server if necessary (i use `shutdown -r now` to do a full shut down and restart)
4. ssh in again if i needed to restart my server
5. run `./update-web.sh`
6. once the shell script is complete and my forum loads again, i remove the workers route on Cloudflare
---
### Author:  [@Jagster](https://meta.discourse.org/u/Jagster)
#### Post date: [August 2, 2026, 7:32am UTC](https://meta.discourse.org/t/maintenance-page-workaround-can-this-be-done/408967/24 "2026-08-02T07:32:41Z")
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.
---
### Author:  [@alltiagocom](https://meta.discourse.org/u/alltiagocom)
#### Post date: [August 23, 2026, 2:24pm UTC](https://meta.discourse.org/t/maintenance-page-workaround-can-this-be-done/408967/25 "2026-08-23T14:24:26Z")
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
---
### Author:  [@Jagster](https://meta.discourse.org/u/Jagster)
#### Post date: [August 23, 2026, 4:12pm UTC](https://meta.discourse.org/t/maintenance-page-workaround-can-this-be-done/408967/26 "2026-08-23T16:12:28Z")
> [@alltiagocom](#):
>
> how much maintenance two containers seem to require
It requires as much as single container 😳
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [August 23, 2026, 5:48pm UTC](https://meta.discourse.org/t/maintenance-page-workaround-can-this-be-done/408967/27 "2026-08-23T17:48:59Z")
And less heart ache 🙂
---
### Author:  [@alltiagocom](https://meta.discourse.org/u/alltiagocom)
#### Post date: [August 23, 2026, 5:53pm UTC](https://meta.discourse.org/t/maintenance-page-workaround-can-this-be-done/408967/28 "2026-08-23T17:53:26Z")
Can you clarify how that goes?
---
### Author:  [@alltiagocom](https://meta.discourse.org/u/alltiagocom)
#### Post date: [August 23, 2026, 5:54pm UTC](https://meta.discourse.org/t/maintenance-page-workaround-can-this-be-done/408967/29 "2026-08-23T17:54:04Z")
Not sure if you were replying to me or to @Jagster? What do you mean?
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [August 23, 2026, 5:55pm UTC](https://meta.discourse.org/t/maintenance-page-workaround-can-this-be-done/408967/30 "2026-08-23T17:55:08Z")
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.
---
### Author:  [@alltiagocom](https://meta.discourse.org/u/alltiagocom)
#### Post date: [August 23, 2026, 6:11pm UTC](https://meta.discourse.org/t/maintenance-page-workaround-can-this-be-done/408967/31 "2026-08-23T18:11:37Z")
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
> [@Move from standalone container to separate web and data containers](https://meta.discourse.org/t/move-from-standalone-container-to-separate-web-and-data-containers/29413):
>
> warning This is an advanced setup. Don’t follow this unless you are experienced with Linux server administration and Docker. You also need to pay close attention to commits to discourse\_docker to make sure you notice if there’s a version bump for postgres or redis. Converting your Current Setup I managed to migrate to two containers. If anyone else needs instructions, this is how it worked for me. The process includes backup, setting up separate web and data containers and restore data. …
and
> **[Managing a Two-Container Installation](https://support.literatecomputing.com/t/managing-a-two-container-installation/310)**
>
> If you have a two-container configuration as is included with the Pro Install managing things is a bit different than a simple single-container installation. How Do I Upgrade? The big advantage of the 2-container installation is that you can...
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.
---
### Author:  [@satonotdead](https://meta.discourse.org/u/satonotdead)
#### Post date: [August 23, 2026, 6:12pm UTC](https://meta.discourse.org/t/maintenance-page-workaround-can-this-be-done/408967/32 "2026-08-23T18:12:07Z")
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?
---
### Author:  [@Jagster](https://meta.discourse.org/u/Jagster)
#### Post date: [August 23, 2026, 6:21pm UTC](https://meta.discourse.org/t/maintenance-page-workaround-can-this-be-done/408967/33 "2026-08-23T18:21:13Z")
First you follow very simple instructions how to start 2-container. After that you mostly need only
```plaintext
./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.
---
### Author:  [@alltiagocom](https://meta.discourse.org/u/alltiagocom)
#### Post date: [August 23, 2026, 6:22pm UTC](https://meta.discourse.org/t/maintenance-page-workaround-can-this-be-done/408967/34 "2026-08-23T18:22:22Z")
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:
> [@Migrate quickly to separate web and data containers](https://meta.discourse.org/t/migrate-quickly-to-separate-web-and-data-containers/153355/28):
>
> @ShawnLi If the two-container system seems complicated, that’s a good sign that the one-container default is a good choice for you. The two-container deployment saves a few minutes of downtime about once per month while updating, but does require more understanding, and requires that you manually follow the details in the announcements every new release. That’s why I led with: grinning
---
### Author:  [@alltiagocom](https://meta.discourse.org/u/alltiagocom)
#### Post date: [August 23, 2026, 6:25pm UTC](https://meta.discourse.org/t/maintenance-page-workaround-can-this-be-done/408967/35 "2026-08-23T18:25:06Z")
Would you say that the instructions in [this topic](https://meta.discourse.org/t/move-from-standalone-container-to-separate-web-and-data-containers/29413) 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…
---
### Author:  [@Jagster](https://meta.discourse.org/u/Jagster)
#### Post date: [August 23, 2026, 6:30pm UTC](https://meta.discourse.org/t/maintenance-page-workaround-can-this-be-done/408967/36 "2026-08-23T18:30:36Z")
> [@Migrate quickly to separate web and data containers](https://meta.discourse.org/t/migrate-quickly-to-separate-web-and-data-containers/153355/28):
>
> The two-container deployment saves a few minutes of downtime about once per month while updating, but does require more understanding, and requires that you manually follow the details in the announcements every new release.
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.
---
### Author:  [@alltiagocom](https://meta.discourse.org/u/alltiagocom)
#### Post date: [August 23, 2026, 6:38pm UTC](https://meta.discourse.org/t/maintenance-page-workaround-can-this-be-done/408967/37 "2026-08-23T18:38:26Z")
I’m confused…
While you say:
> [@Jagster](#):
>
> It requires as much as single container 😳
then your reply above this one makes it sound that there’s more work, when you say:
> [@Jagster](#):
>
> There is no _details in the announcements every new release_ to follow
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?
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [August 23, 2026, 6:42pm UTC](https://meta.discourse.org/t/maintenance-page-workaround-can-this-be-done/408967/38 "2026-08-23T18:42:00Z")
> [@alltiagocom](#):
>
> having 2 containers doesn’t mean two instances of Discourse, I believe?
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”)
---
### Author:  [@Jagster](https://meta.discourse.org/u/Jagster)
#### Post date: [August 23, 2026, 6:48pm UTC](https://meta.discourse.org/t/maintenance-page-workaround-can-this-be-done/408967/39 "2026-08-23T18:48:51Z")
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.
---
### Author:  [@Jagster](https://meta.discourse.org/u/Jagster)
#### Post date: [August 23, 2026, 6:52pm UTC](https://meta.discourse.org/t/maintenance-page-workaround-can-this-be-done/408967/40 "2026-08-23T18:52:11Z")
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` 😉
---
### Author:  [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [August 23, 2026, 7:15pm UTC](https://meta.discourse.org/t/maintenance-page-workaround-can-this-be-done/408967/41 "2026-08-23T19:15:48Z")
> [@Jagster](#):
>
> 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.
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”.
[Previous page](https://meta.discourse.org/t/maintenance-page-workaround-can-this-be-done/408967.md?page=1)
[Next page](https://meta.discourse.org/t/maintenance-page-workaround-can-this-be-done/408967.md?page=3)