In a discussion titled “Discourse Self Hosting with Docker compose” under the Installation category, max.hammer asked if it’s possible to self-host Discourse using a standalone docker-compose file for local testing, avoiding complex scripts. merefield pointed to the official documentation on self-hosting and the standard install guide. merefield also encouraged reading the launcher scripts since Discourse is open source. hellekin noted that while unsupported, community efforts exist, such as medevel.com and IndieHosters’ libre.sh, both using the official discourse/base image but not replicating the full pups automation. max.hammer reported the discourse/base container exited without logs, which tvavrda explained happens because the base image requires compilation via the ./launcher script — a core part of Discourse’s flexible, commit-driven upgrade system. tvavrda advised that creating a docker-compose setup would require replicating the launcher’s logic. max.hammer clarified he wanted to test Discourse locally without DNS or open ports. Canapin suggested the dev install guide, while tvavrda noted the dev setup is ideal for bug fixing, but Docker is better for production-like local testing. Ultimately, max.hammer confirmed success using the standard Docker installation.
I hope you’re all doing well! I have a question about Discourse: Is it possible to self-host Discourse? I’m really interested in the platform and would love to know if anyone here has experience with it. Are there any specific requirements or tips I should keep in mind?
This is unsupported, but there are efforts trying to keep up with mainline Discourse. You can search for docker compose here, or visit these two variants:
Because the base image does nothing by itself. You need to compile Discourse in it and then run it. And that is done by executing a ./launcher script outside of the image first. So you should first try to install it the official way and then think about the options.
The Discourse installation procedure is not very common but over the years I really like the approach for one reason, which you will only appreciate after being an admin for some time. And that is the possibility to upgrade it after each commit to the source code. It’s incredible. You report a Contribute > Bug, after 1 hour it may very well be addressed by the team or the community, the automatical tests are executed and the commit is merged and available. And you can upgrade straight away. Because you recompile your Discourse on the latest source code.
So there is no image where any specific version would be compiled. You get an “empty” image and compile your version from the point you want and with the combination of plugins you need. And it still works!
You don’t get this kind of flexibility anywhere else.
So I am not sure, but if you want to make a docker compose file, you will need to replicate the ./launcher script procedure inside the compose file, so you compile it to another image, which you can then just plug in. But you cannot use the built-in procedure when you need an upgrade. You will have to go and compose a new version by yourself.
Thanks for your help guys. You make it easy for beginners like me to use Discourse!
Yes, but before I make Discourse available to my club, I wanted to run Discourse on the localhost and do some tests so that I can get along better with the admin interface and the command line of Discourse. If errors occur, I want to be able to fix them. For the ‘supported’ version I need a DNS entry, port 443 and 80 which is unnecessary in my case - at least I think so.
Does anyone know a hack on how to run this on the localhost?
Or that. Although I understood that Max is interested in getting to know how it behaves in production but to test it locally before purchasing a hosting environment. For that the docker setup would be more appropriate. In order to actually fix bugs, the dev setup is the right choice.