# Migration to a Self-Hosted solution from Kubernetes

**URL:** https://meta.discourse.org/t/migration-to-a-self-hosted-solution-from-kubernetes/377198
**Category:** Self-hosting
**Tags:** install, migrations-tooling
**Created:** [August 4, 2025, 12:40pm UTC](https://meta.discourse.org/t/migration-to-a-self-hosted-solution-from-kubernetes/377198 "2025-08-04T12:40:20Z")
**Posts on this page:** 1
**Showing post:** 3

<div class="post-metadata">

### Author: ![manning-ncsa](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/manning-ncsa/32/282163_2.png) [@manning-ncsa](https://meta.discourse.org/u/manning-ncsa)
#### Post date: [October 16, 2025, 2:45pm UTC](https://meta.discourse.org/t/migration-to-a-self-hosted-solution-from-kubernetes/377198/3 "2025-10-16T14:45:10Z")

</div>

> [@pfaffman](#):
>
> > [@stevejr](#):
> >
> > Is it better to create a brand new database with a fresh install and then do a backup/restore?
> 
> If by “better” you mean “will this mean that I won’t break our existing site and leave it in a state where it will never work again?”, the answer is yes. 😉

My experience concurs. I have seen so many strange little failures over the years that I always maintain full backups such that I can start from scratch and restore the site. Relying on fixing problems _in situ_ will eventually fail you.

> [@stevejr](#):
>
> - The standard installation guide uses Docker - how do you monitor the containers in a production environment as it looks like the [standard install](https://meta.discourse.org/t/142537?silent=true) is a single VM with Docker.

Like you, I was left in the lurch when Bitnami stopped offering free images and charts. I had to adapt and migrate so many deployments. One of them was my Discourse deployment. If it is useful to you, [here is a link to the replacement Helm chart](https://git.ncsa.illinois.edu/nsf-muses/muses-terraform/-/tree/695dba4ba1077e55ab6539fd27d495261cded024/charts/discourse) I created in a very short amount of time (meaning that it works but is far from an ideal design). It is an attempt to use the “official installation method” given that I have seen no “community standard” Helm chart emerge after all these years. (I suppose Bitnami’s chart was effectively that standard, because few of us predicted this abrupt change.) In any case, this new chart that I am running for one of my research communities is basically just a pod with two containers: the official Docker-in-Docker container and a custom container based on `python:3`, installing Docker and then using the official Discourse installation. Because all the components (Discourse server, Redis, PostgreSQL) run in the black box of the locally image built by the launcher script, there is no scalability or support for high-availability. I did manage to reduce the downtime due to the pod respawning on another node (e.g. when draining node for OS updates or a node crash) by using `docker save` to [store the built image on the persistent volume](https://git.ncsa.illinois.edu/nsf-muses/muses-terraform/-/blob/695dba4ba1077e55ab6539fd27d495261cded024/charts/discourse/files/run.sh), and then loading that if `local_discourse/app:latest` is not found.

But to answer your question, I do not know how to monitor anything in this new deployment. I am running “in production” but my community is small enough and the usage moderate enough that if the forum goes offline for a while, it is not a big deal. Even so, I am very close to abandoning self-hosting and migrating to a service like [Communiteq](https://www.communiteq.com/discoursehosting/pricing/) or [Discourse.org](https://discourse.org/pricing).

---

_[View the full topic](https://meta.discourse.org/t/migration-to-a-self-hosted-solution-from-kubernetes/377198)._