# Automatic deployment to production environment
**URL:** https://meta.discourse.org/t/automatic-deployment-to-production-environment/306471
**Category:** Self-hosting
**Created:** [May 2, 2024, 1:38pm UTC](https://meta.discourse.org/t/automatic-deployment-to-production-environment/306471 "2024-05-02T13:38:14Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@Celso\_Teixeira](https://meta.discourse.org/u/Celso_Teixeira)
#### Post date: [May 2, 2024, 1:38pm UTC](https://meta.discourse.org/t/automatic-deployment-to-production-environment/306471/1 "2024-05-02T13:38:14Z")
Hi,
I have Discourse installed on two separate Azure VMs (staging and production). Is there a way to automatically deploy changes from staging Discourse to production Discourse?
UI changes (theme) will be managed in a Git repository, so shipping them to production won’t be a problem. The main concern lies in automating the deployment of Discourse settings and configurations to the production environment. How can we achieve this?
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [May 2, 2024, 1:59pm UTC](https://meta.discourse.org/t/automatic-deployment-to-production-environment/306471/2 "2024-05-02T13:59:17Z")
You can push the staging container to a repo and then launch it on production. The `./launcher start-cmd app` will give you the required stuff to crank up the container in Docker.
You’ll also need to migrate the database (perhaps with `SKIP_POST_DEPLOYMENT_MIGRATIONS` and then again when the new container has started if you want true zero downtime) and precompile assets.
Some settings live the the database. Others can be set with ENV variables like `DISCOURSE_SETTING_NAME` (e.g., `DISCOURSE_TITLE='my great communiyt'`)
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [May 2, 2024, 2:13pm UTC](https://meta.discourse.org/t/automatic-deployment-to-production-environment/306471/3 "2024-05-02T14:13:56Z")
A lighter weight strategy is to use this:
Note the “only show overriden” in top right
That will give you a list of things which aren’t default which you might transfer manually.
Depending on your need this might be simpler. (That said, I’ve got 100 + settings that are not default on my several year old instance.)
app.yml can be partially copied.
Of course that won’t carry across Categories etc.
---
### Author:  [@Celso\_Teixeira](https://meta.discourse.org/u/Celso_Teixeira)
#### Post date: [May 3, 2024, 9:50am UTC](https://meta.discourse.org/t/automatic-deployment-to-production-environment/306471/4 "2024-05-03T09:50:50Z")
> [@pfaffman](#):
>
> You can push the staging container to a repo and then launch it on production. The `./launcher start-cmd app` will give you the required stuff to crank up the container in Docker.
Can this be achieved with a standalone approach, or do I need to have two containers (one for the database and one for the web)?
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [May 3, 2024, 11:27am UTC](https://meta.discourse.org/t/automatic-deployment-to-production-environment/306471/5 "2024-05-03T11:27:13Z")
If you’re not a hobbyist, I recommend two containers, as you have to shut down the database when you start a new container so you can’t have zero downtime. But it would work with a single container.