# Official "cloud native" docker image from discourse

**URL:** <https://meta.discourse.org/t/official-cloud-native-docker-image-from-discourse/228568>\
**Category:** Feature\
**Created:** [May 31, 2022, 9:29am UTC](https://meta.discourse.org/t/official-cloud-native-docker-image-from-discourse/228568 "2022-05-31T09:29:08Z")\
**Posts on this page:** 1\
**Showing post:** 1

<div class="post-metadata">

**Author:** ![wzrdtales](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/wzrdtales/32/262073_2.png) [@wzrdtales](https://meta.discourse.org/u/wzrdtales)\
**Post date:** [May 31, 2022, 9:29am UTC](https://meta.discourse.org/t/official-cloud-native-docker-image-from-discourse/228568/1 "2022-05-31T09:29:08Z")

</div>

Hey there,

the team recently dropped support for disabling long polling over the interface. This broke functionality required for the bitnami docker image, which uses passenger and does not work see [https://github.com/bitnami/bitnami-docker-discourse/issues/177](https://github.com/bitnami/bitnami-docker-discourse/issues/177). The bitnami image doesn’t pass through environment parameters directly, so this is broken until someone extends the bitnami image, see [DEV: Drop `enable_long_polling` and `long_polling_interval` settings by tgxworld · Pull Request #16323 · discourse/discourse · GitHub](https://github.com/discourse/discourse/pull/16323).

Of course the question for me came up, since discourse is already only distributed with a docker container: Is there any chance the team will maintain a “cloud native” docker image?

The big difference between the bitnami image and yours is the mode of operation. Modern infrastructure expects that you can automate the installation. Usually in k8s done with helm, but also ansible deployments in rather traditional environments with VMs would result in the same outcome. So what would actually make discourse on par with the rather neglected bitnami image is adding an auto installer routine and maybe even adapting the helm template.

As I am here already, let me leave some feedback about discourse itself and its “cloud readiness”:

In general when we tried tying discourse into a reproducible setup for a current customer project it showed quite fast that discourse was never made under the aspects of modern infrastructure. One example is the need of a shared NFS storage. That is neither reliable, nor scalable. Luckily most of this can be redirected to a S3 already, but there are parts left which are the plugins.

There are three ways to solve the plugin issue:

- Evaluated code stored in the database (not recommended)
- Prepackaged sidecar containers (in kubernetes terms that would be used as initContainers writing to an emptyDir) writing to a volatile storage (i.e. tmpfs) pre startup of the discourse container (recommended, even though not super comfortable)
- An installer routine, getting current plugin information and their install commands from the db on startup and a watcher/listener routine to install plugins at runtime as well (not recommended, b/c super slow and error prone)

---

_[View the full topic](https://meta.discourse.org/t/official-cloud-native-docker-image-from-discourse/228568)._