Two standalone instances on one server?

I’d like to create a second instance of Discourse on my server, which is completely self-contained. It will be another forum entirely.

I assume Docker helps us host setups like this, although I’m concerned to understand any potentially clashes between the two instances, if I were to add a second.

No problem at all. I have such configuration running. You just need an external nginx to help mux 80/443 port.

Someone wrote a blog post about that :slight_smile:



Do I need to change app.yml in the second instance to avoid any name clashes within Docker engine?

Yup - planning on using my external Nginx as a front-end proxy.

Thanks! Got some thing new to play with.

Another alternative is to use haproxy as front end.
There are some old posts in Meta about this.

1 Like

You second instance cannot have “app.yml” as the filename since it is going to be the Docker container name. You can just copy the app.yml file from the first instance and edit it to suit your configuration for 2nd one, and save it under a different filename. Then you need to ./launcher bootstrap <new app.yml file> to bring it up.

Regarding HTTP2 support, all you need is a recent enough nginx which supports HTTP2. Since now you have an external nginx, the SSL setup should be done in it instead of in the container.

You have two options to do SSL setup, if you are using Let’s Encrypt.

  1. Setup LE outside of container. This is the approach I took. This enables you to manage the certificates from a single point. I personally prefer DNS over web server challenge validation. I have a blog post for that if you would like to give it a try.

  2. Let the two containers handle their LE application/renew stuff the same as you have with a single container. Since you can access container files under /var/discourse/shared from the host, you can let external nginx to pick the SSL certificates there and serve HTTPS. This may require some edit in app.yml. Since I personally don’t use it so you have to figure it out by yourself.


EDIT: Some of these steps are unnecessary - see post below by @kraml

I now have my second Discourse instance running.

  1. Checked out the Discourse code into /var/[myforum]
  2. Took the content of standalone.yml from /samples and created /containers/[myforum].yml
  3. In /containers/[myforum].yml
  4. replaced all instances of /var/discourse with /var/[myforum] (e.g. volume configuration)
  5. set unique ports
  6. Ran ./launcher bootstrap [myforum].yml
  7. Ran ./launcher start [myforum].yml
  8. Added nginx config for the new domain

And it’s working perfectly first time. Another win for Discourse!


You actually don’t need another /var/[myforum]… You can just use the same /var/discourse for multiple instances.

/var/discourse/containers/app.yml --> This is the default instance you get by running discourse-setup

/var/discourse/containers/myforum.yml --> This is the 2nd instance you get by running cp app.yml myforum.yml && edit && ./launcher bootstrap myforum

When editing myforum.yml, make sure you put a different host path under the volumes section, so that your 2nd container stores its data under a different directory than the 1st one.


A bit off topic. I got gzip content-encoding back from meta on Firefox 53 beta and Chrom 57. Is there anything wrong?

we only send our static assets with brotli, dynamic assets are a much trickier story.

Oh I see, indeed so.

thanks to you and @kraml for your work and insight on how to set up dual instances of a discourse community. usually takes me a bit to get something like this done. but now have 2 instances working behind nginx proxy. thanks to you both.:grinning:

1 Like

what is the difference between this approach and Multisite configuration with Docker?
I need a development (testing plug-ins) and production instance of discourse on Digital Ocean cloud server, that’s why I’m asking.

Multisite setup uses one database service and a shared pool of application workers for all the sites. This configuration has a completely separate database and unicorn cluster for the sites, which potentially requires a lot more RAM.

1 Like