I really would like to have an official helm chart for discourse with an official docker image. I just opened this issue. I’d like to have the consent of the discourse maintainers to make this happening. Hope you can help make this happen. All you need to do is to give a yes :slight_smile: Thanks!

I predict you’ll have a lot of these sorts of things. If you diverge from how our image does things, you have to know why, otherwise you’re setting everything up for a horror show.

[תמונה] mpalmer: you’re setting everything up for a horror show Don’t exaggerate, I’ve been running this for 5 (little) forums for 2 years now, I’m still sane. Do you want to keep discussing every little detail, or should we get the repo to start actually working toward this official docker image? I think all of this has already been discussed, and I really don’t want to go back to this discussion. I want to have the ball rolling to have a community docker image. If you don’t want, please just let me know, I still have some ideas to convince you, but yeah, let’s try to keep focus.

The concern is that we have a way that works. Introducing another way has the potential to cause a bunch of people trouble. And then they’ll go away with a bad taste for discourse because it didn’t work. I make a part of my living doing installs (most is from imports). I’ll be willing to do some testing and see how your setup works. Can I test it out?

[תמונה] pierreozoux: Do you want to keep discussing every little detail, or should we get the repo to start actually working toward this official docker image? Yes, actually, I do want to discuss every little detail, because the details matter. We care very much about the experience of people who decide to self-host Discourse, and invest a lot of time and effort in making that as efficient and straightforward as we possibly can. A lot of hard work has gone into making the current setup work well, and throwing all that out and going back several years just because it doesn’t use this month’s “container orchestration” hawtness does not seem like a good tradeoff. Sure as heck we’re not going to put any sort of “official” stamp, or even tacit endorsement, on a deployment method which is worse in any way than what we have now.

[תמונה] pierreozoux: Don’t exaggerate, I’ve been running this for 5 (little) forums for 2 years now, I’m still sane. Awesome! I’ve bookmarked this post, and if anybody asks how to run Discourse in Kubernetes or Swarm, I’ll be sure to point them at your images :+1:. Advantage of being not-an-employee: my word doesn’t have to carry the weight of being Official™. They, on the other hand, benefit immensely from having One Official™️ Way of deploying Discourse. CDCK is not going to take on the load of maintaining a deployment system that they themselves don’t use and is massive overkill for most self-hosters. And if they don’t maintain it, they ain’t endorsing it. Brand protection demands it.

Thanks for creating this thread @pierreozoux! I recently reached critical appreciation for discourse and got interested in hosting a deployment. I’m currently hosting JupyterHub, GitLab and Mattermost - everything through Helm charts and would very much like to do the same with Discourse. Some background about Helm / Kubernetes: A Helm chart is a set of configurable Kubernetes resources, and Kubernetes resources are for example a Deployment Kubernetes resource that makes a given docker image run at all time. Installing something can end up becoming a single line command + some configuration. I would be happy to at least review code and make some PRs to fix various things in a Helm chart for discourse if it would be developed. I’m currently a maintainer of JupyterHub’s Helm chart and have various contributions to other charts.

I think it’s actually possible / feasible to break up Discourse into a set of kube pods, but have fun sizing the resource requirements for the web and sidekiq runners :slight_smile: If insane levels of infrastructure failure tolerance is not a business requirement for you, just use the singleton fat container, it’s going to be order of magnitude cheaper & easier for the same level of steady state service.

Hello guys! I’m from a quite large Italian community that uses Discourse as the tool for their forum. While we love Discourse, we’ve also observed some difficulties deploying it on Kubernetes, through some kind of “standard” procedures. I feel the pain of the maintainers :slight_smile: I’ve been working at Open Networking Foundation for years, and one of the biggest challenges has been moving CORD -one of our biggest platforms- away from scripts-based installations to Dockerfiles/docker-compose and Docker images hosted on DockerHub + helm-charts. While there’s a reasonable fear in doing so, and if a solution that fits all the cases never really exists, I can tell we absolutely saw the benefits of it since the very first deployments. Usually, the biggest step to take is to enter in the mindset to leave existing tools do whatever they can do best :slight_smile: Docker has installation procedures, that are standard, easy and already well-documented. Scripts are something custom, that often needs customizations and maintenance. Also, there’s really no reason why you shouldn’t be able to use the original Docker images / helm-charts as Discourse dependencies (i.e. unicorn, postgres, redis, …). I’d suggest to tackle the basics first (i.e. having a Dockerfile, docker-compose, and a dockerhub automated build for each component). Once this is done (with the proper software and docs modifications), the helm-charts development is the easiest thing. I’d be very happy to help, even having a call together to discuss pros and cons of the solutions proposed above. Along my brief research, I’ve also noticed that Bitnami (super famous in the Docker space) has come up with some images (https://github.com/bitnami/bitnami-docker-discourse#how-to-use-this-image). I was wondering if this was some separate work they’ve been doing alone, or something coordinated with you. It may be a very good starting point. If there was no partnership with them, I’d suggest it as a possible way to go. Not sure if they would do it for free, but I may be a possibility. FYI I’ve opened an issue on their repo to know more about the work that has been done (https://github.com/bitnami/bitnami-docker-discourse/issues/132). Please, let me know your thoughts and if I can help anyhow.

Hi @Luca_Prete, did you check @pierreozoux’s work above and the team’s response? Most of the Docker packaging work would be to match what pups is doing in the background for launcher, including some custom configuration setup for Postgres, Sidekiq, etc. @unteem scratched an itch and went through following what pups did for earlier versions of Discourse. Keeping the docker image up-to-date with the official release is challenging. It would be interesting to unfold the whole process and walk that path in a standard docker approach. If there’s a workable path towards using a standard setup I guess many people here would be super happy.

@hellekin thanks. I have not. I’m sure there’s a lot there, but I usually tend to stay away -at least for work- from single-user (as opposed to community-supported) jobs, for the simple fact that it may become hard to maintain them later on. The specific path really depends on some details of the platform. What I see as a possible solution in your case would be start understanding how standard images (Postgres, Redis, …) would work with Discourse without specific customizations. The reason why I’m considering this important is that it gives you the ability to rely -anywhere you install Discourse- on external, standard services (that could be installed on physical hardware, on a VM, on some containers, on k8s in form of chart deps, …). Each of these services typically allows the use of some startup scripts, to create a db and so on…shouldn’t be so difficult. Then I would create a proper Dockerfile (which automatically also becomes your quick start guide for users that wish to install Discourse without Docker). Then comes the docker-compose.yaml (this is pretty much the same of what bitnami exposes on their github) At this point you should be able to bring up Discourse on your laptop in form of "micro"services, using standard dep images, in few seconds, in one command, without any custom script. Last but not least comes Kubernetes fun (few yaml files, possibly packaged in form of a helm-charts), to be published on the official, stable repo, or alternatively -at least at the beginning of the process- on your self-hosted repo.

Community supported official docker image

מפתח

pfaffman (Jay Pfaffman) 26 בספטמבר,‏ 2020,‏ 3:41am 33

There will not. The solution that I use is to bootstrap the new image, push it to a repo, then launch it, then do post upgrade migrations after the new pods crank up.

נושא		תגובות	צפיות
Is Docker image discourse/discourse considered safe and production-ready? Self-hosting hosting	30	3723	26 במאי,‏ 2026
Can Discourse ship frequent Docker images that do not need to be bootstrapped? Development	211	41868	13 ביולי,‏ 2025
Using a launcher built docker image in docker-compose Development	30	8537	27 בספטמבר,‏ 2024
Installing on Kubernetes Self-hosting unsupported-install	56	26575	9 ביוני,‏ 2026
Container restart - discourse tries to reinstall Self-hosting unsupported-install	22	3353	30 ביולי,‏ 2020

Community supported official docker image

נושאים קשורים