Right. That makes sense. And I think would be fine for me using mailgun.
I will understand all of this better if and when I start setting up a multisite!
Jumping in because I’m in a similar situation as @alltiagocom — I’ve got discourse installed on a smallish Hetzner server for my main community but have been thinking, in the background, of moving a few other Facebook groups to Discourse once I have got the hang of things.
I’m familiar with « Wordpress multisite » but I’ve understood that Discourse multisite is more involved. I was wondering what would be less of a headache, running two standalone sites (or more) or a multisite.
Any insight on this?
Multisite would definitely be less maintenance overhead so less headaches but YMMV
For Discourse novices, I recommend just running two sites.
I made a topic for how to run multisite without a reverse proxy, but it’s out of date now.
I think all that needs to change is
can be replaced with the new
DISCOURSE_HOSTNAME_ALIASES: domain.com,other.domain.com
My two cents, after spending the whole day working on this with the help of my old notes, ChatGPT, Claude, Discourse’s AI Bot, and some topics shared here (and after taking notes and more notes about the whole process).
Everything seemed to be working just fine until I got to the point where I needed to add the reverse proxy. My first instance, which was working fine, wasn’t working. I asked a few more questions to Discourse’s AI bot, but since that’s my first day, it stopped working. It’s a limitation for new users of the bot. Claude, who was being super helpful, also stopped, because I’m on the free version. ChatGPT is the least reliable of all, so all replies from it, are always received by me with a LOT of hesitance…
Then I came to the forum again and started reading a few topics about it, some written by @pfaffman. That was the last straw. Too complex, too much technical terms for me to even understand what to ask.
Summary: my first instance was working, so I’m reverting it back to what it was (editing the app.yml file to what it was before the changes. I’m rebuilding as I type.
To be honest, for all the complexity, even though it would allow me add more communities after going through the first big obstacle, I don’t think that saving $4 a month for an extra community will be the end of the world. Since I already know how to set up a server in Hetzner and then install Discourse, I will stick to 2 communities now, pay the $8 for both, and move on. Considering I was paying $12 for one droplet with Digital Ocean a few months ago, I can do the effort of paying the same amount for 3 communities if I want to.
Regardless, I always find these adventures interesting, because I learn something new along the way, and in the end, at least I can say why I don’t want to do it, rather than just saying “I won’t do it, because I don’t know if I can do it”.
I appreciate the time and help all of you shared here, and hopefully this topic will help others who want to achieve what I was trying to.
Over and out!
This is exactly why I said You need to rethink your strategy, while what you were trying to achieve wasn’t impossible, because it has been done before, it requires significant understanding of discourse to be able to get right.
I’d recommend keep experimenting in your free time if you want to learn more about how discourse works, that’s how most of us here learned it.
It took me much longer than I care to admit to (mostly) figure it out!
I’m documenting a supported Discourse multisite install as a command-by-command runbook.
I previously experimented with a “multiple standalone installs on one server” approach, but that configuration is not supported. This post focuses only on the supported multisite architecture, rewritten in a linear format for people who prefer explicit steps.
What this is (supported)
- One Discourse app container (
app) - Multisite enabled via
multisite.yml - Shared Postgres + Redis (managed by Discourse)
- Connectivity via unix sockets (no Docker network required)
- Multiple hostnames routed to separate sites internally
What this is not
- Multiple independent Discourse containers behind HAProxy
- Rolling rebuilds by draining app nodes
- Per-site SMTP credentials (SMTP is shared)
Operational notes (so expectations are correct)
Rebuilds / downtime
In multisite there is only one app container, so ./launcher rebuild app will restart the only node. That means short downtime for all sites is expected.
Certificates / host validation
Add all hostnames to DISCOURSE_HOSTNAME_ALIASES so Let’s Encrypt + host validation work reliably.
Backups / migration later
Each site makes its own backup in /admin/backups. Restoring a site backup onto a standalone install later is the normal migration path.
Full supported multisite runbook (command-by-command)
0) Host prerequisites
| Step | Command |
|---|---|
| Update system | apt-get update && apt-get upgrade -y |
| Install dependencies | apt-get install -y git curl sudo |
1) Install Discourse Docker
| Step | Command |
|---|---|
| Clone repo | git clone https://github.com/discourse/discourse_docker.git /var/discourse |
| Enter dir | cd /var/discourse |
2) Install first site (single site first)
| Step | Command |
|---|---|
| Run setup | ./discourse-setup |
This creates /var/discourse/containers/app.yml and boots the first hostname (e.g. forum1.example.com).
3) Enable multisite
| Step | Command |
|---|---|
| Create config dir | mkdir -p /var/discourse/config |
| Edit multisite file | nano /var/discourse/config/multisite.yml |
Example multisite.yml:
forum1:
host_names:
- forum1.example.com
forum2:
host_names:
- forum2.example.com
4) Edit app.yml to enable multisite + hostname aliases
| Step | Command |
|---|---|
| Edit app.yml | nano /var/discourse/containers/app.yml |
Add:
DISCOURSE_MULTISITE: trueDISCOURSE_HOSTNAME_ALIASES: forum1.example.com,forum2.example.com
5) Rebuild
| Step | Command |
|---|---|
| Rebuild | ./launcher rebuild app |
6) Migrate multisite DBs
| Step | Command |
|---|---|
| Enter container | ./launcher enter app |
| Run multisite migrate | rails multisite:migrate |
| Exit | exit |
| Step | Command |
|---|---|
| Restart | ./launcher restart app |
7) Verify
Visit:
https://forum1.example.comhttps://forum2.example.com
Each site has its own admin, users, uploads, and backups.
8) Backups / migration later
Per-site admin:
/admin/backups
Restore that backup onto a standalone install later if you want to split the site onto its own server.
If anything above conflicts with current best practice, I’m happy to update this runbook - the intent is to provide a linear supported multisite checklist that reduces trial-and-error.
와! 다중 사이트(multisite)라는 혼란스러운 세계에서 명확성을 얻기 위해 제가 필요로 했던 바로 그 명확한 가이드네요! 실제로는 생각했던 것보다 훨씬 실현 가능하고 훨씬 더 단순해 보입니다.
단일 컨테이너에서만 실행할 수 있다는 점은 다소 아쉬우지만, 왜 그렇게 해야 하는지 직관적으로 이해가 됩니다. 그 결과, 여러 개의 작고 조용한 셀프호스팅 포럼에 가장 적합할 것 같습니다.
귀하의 답변은 분명히 자체 (위키) 주제를 가질 자격이 있으며, 잘 안내되어 있어야 합니다.
나에게도 좋은 기회가 될 것 같아 
Discourse가 이미 « monosite »로 실행 중이고 이를 multisite로 전환하려는 경우에도 이 내용이 적용됩니까?
수고 많으셨습니다!
감사합니다! 이것은 여전히 현재 지원되는 멀티사이트 관행과 일치합니다. 여기에는 Discourse 멀티사이트의 현재 작동 방식과 충돌하는 내용이 없습니다.
네, 기존 monosite 설치를 multisite로 전환할 때도 동일한 단계가 적용됩니다. monosite은 기본적으로 단일 기본 사이트를 가진 multisite라고 볼 수 있습니다. DISCOURSE_MULTISITE를 활성화하고, multisite.yml을 추가(기존 사이트 포함)한 후, 한 번 재빌드하고, rails multisite:migrate를 제자리에서 실행하면 됩니다.
여기서 더 이상 모범 사례를 반영하지 못하는 부분이 있다면 런북을 업데이트하는 데 매우 기꺼이 협력하겠습니다. 목표는 시행착오를 피하는 선형적이고 지원되는 체크리스트를 제공하는 것입니다.
단일 컨테이너 discourse_docker 멀티사이트 환경에서 multisite.yml을 올바르게 제공해야 하는 방법에 대해 설명해 주실 분 계신가요?
위의 런북에서는 현재 다음과 같이 작성되어 있습니다:
mkdir -p /var/discourse/config
nano /var/discourse/config/multisite.yml
그러나 멀티사이트 문서에서는 app.yml의 before_bundle_exec 후크를 사용하여 다음 파일을 생성하는 방식을 사용합니다:
$home/config/multisite.yml
문서에는 이 후크가 Discourse 애플리케이션 내부에 해당 파일이 올바르게 배치되도록 보장한다고 명시되어 있습니다.
호스트의 /var/discourse/config/multisite.yml이 애플리케이션 컨테이너 내부의 /var/www/discourse/config/multisite.yml로 자동으로 마운트되거나 복사되는 과정을 확인할 수 없었습니다.
내부 PostgreSQL과 Redis를 사용하는 표준 올인원 app 컨테이너의 경우, 런북에서 호스트에 /var/discourse/config/multisite.yml을 직접 생성하는 것 대신 before_bundle_exec 후크를 사용해야 하는 것인가요?
기존의 라이브 단일 사이트 설치 환경에 적용하기 전에 런북을 올바르게 수정하고 싶습니다.
app.yml에 다음과 같은 내용을 추가해야 합니다.
- volume:
host: /var/discourse/shared/multi/multisite.yml
guest: /var/www/discourse/config/multisite.yml
감사합니다 - 호스트 측 파일에는 명시적인 볼륨 매핑이 필요하다는 것이 확인되었습니다.
런북을 수정하여 /var/discourse/shared/multi/multisite.yml를 /var/www/discourse/config/multisite.yml에 마운트하도록 변경할 수 없습니다.
PostgreSQL과 Redis가 Discourse 컨테이너 내부에서 관리되는 표준 올인원 app 컨테이너의 경우, multisite.yml 항목에 host_names만 포함되어 있으면 충분한가요, 아니면 각 사이트별로 database, username, host, pool, timeout과 같은 명시적인 값도 지정해야 하나요?
예를 들어, 두 번째 사이트를 생성하는 데 다음과 같은 설정이 유효한가요?
forum2:
host_names:
- forum2.example.com
제 설정은 다음과 같습니다. host_names:만 남기고 나머지를 모두 삭제하면 어떻게 될지 모르겠습니다. 제 모든 사이트에 대해 이 설정을 반복 적용하고 있습니다.
forum2:
adapter: postgresql
database: forum2_discourse
host: data
password: SEKRET
pool: 25
timeout: 5000
host_names:
- forum2.example.org
이 내용이 app.yml에 있다면 Discourse는 앱 컨테이너의 var/www/discourse/config/multisite.yml 경로에 파일을 생성하며, 내용은 동일합니다. 가이드를 따라가면서 혼란스러울 수 있다는 점은 알고 있습니다. 하지만 멀티사이트 환경에서 두 번째 사이트나 세 번째 사이트를 app.yml에 선언하는 가장 좋은 방법입니다. 저는 멀티사이트와 함께 이메일 송신을 위한 셀프호스팅 postfix, dovecot 설정을 사용 중입니다. 현재까지는 완벽하게 잘 작동하고 있습니다. 저는 postfix를 가상 메일박스(virtual mailboxes)로 구성했습니다. Postfix는 답장 키(reply key)도 유지합니다. 조금 더 작업이 필요하지만, 제 생각에는 더 나은 해결책입니다.