ecki is seeking a way to configure a Discourse server to accept multiple hostnames during a staging/cutover phase, without relying on redirects or complex reverse proxy setups. While Discourse officially doesn’t support multiple hostnames (outside of multi-site), ecki notes that the main blocker is the Content Security Policy (CSP) headers, which enforce absolute URLs tied to a single hostname — suggesting they could be extended to accept a list of allowed hosts. ecki also reports that rebuilding the app container with a different DISCOURSE_HOSTNAME fails, likely due to hardcoded values in the database, making a multi-host solution more critical. pfaffman references existing guides for changing domain names and setting up Let’s Encrypt for multiple domains, noting that for HTTP, Discourse can handle multiple names with redirects, but for HTTPS, certs must cover all domains. They also suggest tweaking nginx to avoid redirects, though details are unclear. ecki counters that the domain-change method is unreliable (e.g., broken image URLs after remap/rebake) and that nginx isn’t the issue — the app layer (especially CSP headers) is the real obstacle. The goal is to allow both the new staging hostname and the official production hostname to serve the same site during cutover, without breaking assets or redirects.
However is that still the case? Redirect wont help in my case (and i really dont want to do fancy reverse proxy rewrites for a simple, temporary use case): In my case I want to install a new discourse server in parallel to the existing and have a staging view of this server with a new name. However the server should also accept the official name (for when the switch over in DNS happens or when admins use a /etc/hosts alias). This would greatly improve the staging phase.
I think currently the main problem are the absolute CSP URLs which stops this from working (hwoever since those already cdheck for protocol, they should be able to extend to check for hostnames from a list of allwoed hosts). So is this available .. meanwhile?
BTW in my case I test with http, but I think the letsencrypt setup to request multiple certs is already covered here, so I will be able to do that later. (does not work until its available under the right official alias anyway)
BTW I just noticed that rebuilding the app container with a different DISCOURSE_HOSTNAME does not work - I suspect its also somewhere in the DB (but it cant be changed on the Admin settings).
Which makes it somewhat more important to have a list of accepted hosts for such a scenario.
If you want multiple names to resolve and for Discourse to redirect to the right one, you’re all set for http. For https you’ll need to get a cert for all domains. I think Set up Let’s Encrypt with multiple domains should help.
If you want to have the site not redirect to itself, you can tweak the nginx to not do that redirect. I’m not sure how to tell you how to do it though.
The changing hostname topic does not work reliable for me (for example despite the remap+rebake the twitter-emoticons of the Welcome post point to wrong server) - havent researched why that is (will let you know). At least its not painless.
The redirect for my usescases does not work since it would redirect to the old server
nginx config does not need a change its not aware of the hostname. But the problem is more with the app, for example the CSP headers contain the full URL (no idea why).