# Installing on Kubernetes

**URL:** https://meta.discourse.org/t/installing-on-kubernetes/49329
**Category:** Self-hosting
**Tags:** unsupported-install
**Created:** [August 27, 2016, 10:59pm UTC](https://meta.discourse.org/t/installing-on-kubernetes/49329 "2016-08-27T22:59:09Z")
**Posts on this page:** 1
**Showing post:** 39

<div class="post-metadata">

### Author: ![lucasbasquerotto](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/lucasbasquerotto/32/133376_2.png) [@lucasbasquerotto](https://meta.discourse.org/u/lucasbasquerotto)
#### Post date: [February 10, 2020, 12:35pm UTC](https://meta.discourse.org/t/installing-on-kubernetes/49329/39 "2020-02-10T12:35:08Z")

</div>

> [@Geoffrey\_Challen](#):
>
> I’m talking about the database server, even if the database files live outside the container.

That makes more sense. That’s what I did when separating in 2 steps the bootstrap stage. The 1st can run in an isolated environment (like a CI pipeline) generating a base image with the discourse repository, gems and plugins installed, and the 2nd step needs to run in the target machine (or at least have access to the production database) to do the db migration and generating the assets (this is done in the bootstrap process tough, not when starting the container).

> [@Geoffrey\_Challen](#):
>
> This fat container Discourse deployment pattern would be much easier to support if the `launcher` script would more cleanly separate (a) bootstrap steps that could be performed offline and only affect the files in the container and (b) bootstrap steps that modify or need access to the database or other state outside the container.

Yes that would be awesome. [I requested that already](https://meta.discourse.org/t/bootstrap-app-container-in-2-steps/116865), but I don’t know if and when that will be done.

> [@Geoffrey\_Challen](#):
>
> The approach described above is a bit frustrating because you do see all kinds of JS uglification, asset minification, and other things that could be done with the previous deployment running

That would be difficult to implement completely on a separate environment because the assets precompile task needs access to the database (for things like custom css), but would be great if only what depends on the database could be made in a separate step (and all other assets, that don’t depend on the database, could be precompiled separately, but I don’t know how viable would be to implement it, technically).

---

_[View the full topic](https://meta.discourse.org/t/installing-on-kubernetes/49329)._