Not being an experienced developer (I would say I’m on the basic level, actually), trying the nginx solution to present a maintenance page was a bit of a nightmare. Today, I had this idea and decided to ask Claude if this would be possible, now that I use Railway for other websites and applications: “Since Discourse uses Docker, it seems very complicated to show a maintenance message, because it requires nginx, which is a complicated process for me. Can I, via Railway or any other service, create a “switch” that quickly directs traffic from one server to the other? For example, right now Cloudflare redirects example.com to my Hetzner server where Discourse is installed. Would I be able to send Cloudflare to a Railway project/environment/service where that “switch” would be implemented and maybe where changing a variable value from “maintenance” to “live” would direct the traffic to either another Railway service for the maintenance page, or to Hetzner?” And Claude’s reply: Yes, technically it works, but running the switch through Railway is the wrong layer for this. You’d be adding a second network hop (Cloudflare → Railway → Hetzner) for every single request when Discourse is live, which means: - Extra latency on every request, permanently, not just during maintenance - A new single point of failure (if Railway service goes down, Discourse goes down even though it’s healthy) - Egress costs on Railway for all your normal traffic, not just maintenance windows Better approach: do the switch in a Cloudflare Worker. Workers run at the edge (300+ PoPs), so there’s no added round trip when you’re in “live” mode, and toggling is instant. Architecture: Cloudflare Worker (bound to example.com) → checks KV value "maintenance_mode" → if "off": fetch(origin request to Hetzner IP/hostname) and return it → if "on": return static maintenance HTML directly from the Worker Toggle happens via a KV write (through API call or dashboard), not a redeploy. Propagates in seconds, no code push needed. Minimal worker: export default { async fetch(request, env) { const mode = await env.MAINTENANCE_KV.get("mode"); // "on" or "off" if (mode === "on") { return new Response(MAINTENANCE_HTML, { status: 503, headers: { "Content-Type": "text/html", "Retry-After": "3600" }, }); } // pass through to Hetzner untouched return fetch(request); }, }; const MAINTENANCE_HTML = ` Back soon `; Setup: 1. Create a KV namespace, bind it as MAINTENANCE_KV. 2. Set the Worker route to example.com/*. 3. Toggle with wrangler kv:key put --binding=MAINTENANCE_KV mode "on" or via the Cloudflare API from a shell script. This gives you the exact “switch a variable, traffic redirects” behavior you described, without touching Discourse’s nginx/docker setup at all, and without adding a permanent extra hop for your live traffic. One thing worth double-checking before you build this: is your Cloudflare proxy currently doing a DNS-only passthrough or already proxied (orange cloud)? If it’s DNS-only right now, Workers won’t intercept anything, you’d need to switch that record to proxied first. So I would be interested to know if Claude’s reply is valid and can indeed be implemented? Would that be an instant switch and any user would be presented with the maintenance page? Or does it still redirect some users to the Hetzner installation and showing them the broken page, because of some cache being involved? And replying to Claude: Yes, my example.com is proxied in Cloudflare. I then decided to open a new Claude window and ask about this interaction, and I got this (so it seems that a bit more work needs to be done: The architecture is sound. Cloudflare Workers on a proxied (orange-cloud) zone intercept requests at the edge before they hit Hetzner, so the design works. But the “instant, all users see it” claim needs qualification: What’s actually true: Worker route matching is fast, effectively immediate once deployed KV writes propagate globally, but not instantly — Cloudflare’s docs say up to 60 seconds for KV to replicate across all edge locations. Some users could hit stale “off” state for up to a minute after toggling. Since Discourse is proxied through Cloudflare already, the Worker will intercept 100% of requests to example.com — no bypass path exists (assuming no other DNS records like a subdomain pointing straight at Hetzner IP, or a CDN cache serving stale content in front of it). What the reply glossed over / got wrong: Browser cache: if any prior response (from Hetzner) was cached with a long TTL and Cache-Control headers, a returning visitor’s browser could serve a cached page without even hitting Cloudflare. Minor risk, but real — worth setting Cache-Control: no-store on the maintenance response. Cloudflare cache: if you have caching rules/page rules caching HTML for example.com, a cached copy could be served without ever reaching the Worker logic, depending on rule order. Workers execute before cache lookup by default in most configs, but if there’s an existing Cache Rule set to “Cache Everything” it can interact in ways worth testing, not assuming. 503 status code: using 503 is correct practice (search engines won’t deindex during brief maintenance), but he should add Retry-After properly formatted — the example does this correctly. The claim “without touching Discourse’s nginx/docker setup at all” is accurate. No mention of KV read latency inside the Worker itself — trivial, sub-ms, not a real concern. Bottom line: workable, and better than the nginx approach. “Instant” is optimistic — call it “propagates within ~60 seconds worldwide” and tell them to test with cache disabled first. The reply should have flagged KV propagation delay instead of implying it’s instant.

Personally yes. If you want belts and braces for web viewers that appear with fresh navigation during the 30-60 seconds, then a maintenance page is fair. You have to weigh the benefit of that against the time to maintain the infrastructure around it.

Now I understand. Thanks. So now I ask: with 2 containers, those 20 minutes or so, are still a thing, the only difference is that I can let it do it on one of the containers, the one that’s not live, and when it’s ready, do the switch. Is that how it works?

Yes, it still takes a while for the container to build and FYI you need to make sure your server is beefy enough to allow that process to take place in parallel whilst serving your community as normal (essentially the most important thing is ensuring enough memory for starters - so very important to make sure you have enough SWAP). The build will also knock out at least one core so think about having a server with 1 or 2 more cores.

Now it all makes sense. Thank you. I was initially using this, but it seems like it’s not available anymore: [image] So now I need to go to this one: [image] Which is a bit jump in price… :confused: and what seems to be a less effective server…?

I would recommend at least 4GB and 3 cores (“vcpu”) for this kind of setup …

For reference as it was asked on another topic, the (edit: wrong) answer: Any cheaper alternatives to Hetzner? - #2 by Canapin

This is the only one that matches that… what a difference in price… [image] I guess I will have to build it with one container now and when the time (:money_bag:) comes, upgrade. Thanks for the info, Robert!

i disagree and do think it’s worth the maintenance page. in my experience, when people see the Discoure error page the first thing they do is hit refresh and then they will see the brief maintenance page that will then automatically reload the site when the container swap is complete. it isn’t a lot of work to set up and you only have to do it once. during a rebuild with the dual container configuration, the bootstrap part happens in the background and users can still use the site; it is the container switch over that causes the brief downtime (unlike a standard single container configuration) server cost and selection is a completely different discussion and should be in another separate topic than setting up a maintenance page. edit: i see there is a topic here and i replied there.

I guess I’m in the middle right now. I understand what you mean, as well as @merefield. It’s a nice touch to have it and if it’s only set up once, not a big deal, I guess? At the same time, if it does indeed take up to 60 seconds, worst case scenario, not everyone will visit the website exactly at the 0 second mark and have to wait 60 seconds. Some people will see the ugly page for 5 seconds, some 20, some 60. Some people will not even see it (I believe?) for example if they are just reading a reply or writing one, that switch could happen before they hit SEND or before they stop reading the topic and hit REPLY (or visit another page). My issue with the nginx route, was more related to the 20 minute thing on a one container setup. With the option to have 2 and going from 20 minutes to maybe 60 seconds tops, I wonder if it’s really relevant? Especially, if I am able to add an announcement at the top saying where things will go down just for a few seconds, on a low-traffic time, this won’t be a big issue? I have to sit and think about it. The 2 container setup will definitely be something to implement, if I find a good server deal, though.

[画像] Lilly: i tend to add and delete my workers route page whenever i am doing maintenance, but some like to just leave it there all the time (i leave the actual code for the page though, i just add and remove the route). Can you clarify this, in a way that a basic person like me can understand? I’m still not familiar with workers… 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? @merefield mentioned that this (maintenance page, workers, etc) is also something that needs to be maintained, so I wonder if it’s really something that you set and forget, or if there’s anything that needs to be done every once in a while?

メンテナンスページの回避策 - これって可能？

製品サポートインストール

Canapin (Coin-coin le Canapin) 2026 年 8 月 1 日午後 12:46 17

別のトピックで質問されていたため、参考までに（編集：誤った）回答を記載します：Any cheaper alternatives to Hetzner? - #2 by Canapin

トピック		返信	表示
Move from standalone container to separate web and data containers Sysadmins docker , how-to , advanced-setup , two-container	138	31694	2026 年 9 月 21 日
Add an offline page to display when Discourse is rebuilding or starting up Sysadmins configuring , how-to , advanced-setup	140	248894	2026 年 2 月 3 日
MKJ's Opinionated Discourse Deployment Configuration Sysadmins explanation , install	46	8473	2026 年 8 月 7 日
Discourse Fails to update in the Admin UI - No matter what Self-hosting	31	1145	2025 年 8 月 5 日
Use Nginx Proxy Manager to manage multiple sites with Discourse Sysadmins how-to	33	25269	2025 年 2 月 23 日

メンテナンスページの回避策 - これって可能？

関連トピック