# Move your Discourse Instance to a Different Server
**URL:** https://meta.discourse.org/t/move-your-discourse-instance-to-a-different-server/15721
**Category:** Self-Hosting
**Tags:** migrations, how-to
**Created:** [May 16, 2014, 8:56pm UTC](https://meta.discourse.org/t/move-your-discourse-instance-to-a-different-server/15721 "2014-05-16T20:56:27Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@Discourse](https://meta.discourse.org/u/Discourse)
#### Post date: [May 16, 2014, 8:56pm UTC](https://meta.discourse.org/t/move-your-discourse-instance-to-a-different-server/15721/1 "2014-05-16T20:56:27Z")
> đ This is a guide for moving your Discourse instance from one server to another, including all settings and data. This guide applies to self-hosted Discourse instances using Docker.
>
> đ Required user level: System Administrator
>
> â This procedure involves domain and DNS changes. Ensure you have access to both the source and destination servers.
This guide walks you through the process of migrating your Discourse instance from one server to another, ensuring your data, settings, and configuration are preserved.
### Disclaimer added by @pfaffman 2025-09-12T05:00:00Z.
These instructions donât work well now because youâre now using https and letâs encrypt, which require the new server to have DNS pointed to it so that it can request keys. What I recommend is follow the [Move a Discourse site to another VPS with rsync](https://meta.discourse.org/t/move-a-discourse-site-to-another-vps-with-rsync/43812) (perhaps using `--exclude postgres*` and then backing up and restoring the database from the command line.) This is slick since if you know how, you can tweak your local DNS to point to the new server so you can test that it works while the rest of the internet still sees the old site.
## Summary
You will perform the following key steps in this guide:
1. Back up your current Discourse instance (source server).
2. Transfer the backup file to your target Discourse instance (destination server).
3. Restore the backup on the destination server.
4. Update DNS settings (if applicable).
## Adjusting DNS settings (when required)
If youâre using the _same domain_ for the new server, reduce the TTL (time to live) on your DNS entry in advance. This ensures minimal downtime during propagation of the updated DNS records. If youâll use a _new domain_, this step can be skipped.
## Logging in and preparing the source server
1. Log in to your source Discourse instance with an account that has administrator permissions.
2. Ensure both the source and destination servers are using:
- The **same Discourse version**.
- The **same set of plugins**.
3. Upgrade the Discourse version on both servers by visiting `/admin/upgrade`.
> â Avoid restoring a newer backup onto an older Discourse version, or incompatible PostgreSQL versions, as this may result in errors.
## Creating and downloading the backup
1. Navigate to `/admin/backups` on your source Discourse instance.
2. Click the **Backup** button to create a backup:
3. When prompted, confirm by clicking **Yes**.
4. Once the backup is complete, go to the **Backup files** tab, and locate the newly created backup.
5. Click **Download** to receive an email with a download link. Click the link in the email to save the backup file locally.
> â Before proceeding, review your `app.yml` file to ensure any optional settings, such as CDN configurations, installed plugins, or HTTPS support, are consistent between the source and destination servers.
## Restoring the backup on the destination server
> đĄ To restore the backup via the command line, refer to the [relevant documentation](https://meta.discourse.org/t/restore-a-backup-from-command-line/108034/).
1. Sign in as an administrator to your destination Discourse instance.
2. Navigate to `/admin/backups/settings`, and enable the `allow restore` setting.
3. Go to `/admin/backups` and click the **Backup files** tab. Upload the backup file you downloaded earlier by clicking the **Upload** button:
4. After the upload completes, click the ⎠(more options) menu next to the uploaded backup, then click **Restore** :
5. Confirm by clicking **Yes** when prompted.
The restoration process will begin. This may take some time depending on your database size. After the process completes, youâll be logged out automatically.
## Finishing up and logging in
1. Log into your destination Discourse instance with your admin credentials.
2. If the site was backed up using HTTPS, ensure HTTPS is enabled on the new server. If not properly configured, use the Rails console to disable the âforce httpsâ setting temporarily.
3. Re-enable any optional configurations by editing the `app.yml` file and rebuilding your instance. This may include:
- Enabling CDN support.
- Installing additional plugins.
- Setting HTTPS configurations.
## Common issues and solutions
### Backup file is not restoring
- Check that the Discourse and PostgreSQL versions match between the source and destination servers.
### Unable to log in after restoration (with HTTPS enabled)
- Use the Rails console to disable `force https` temporarily by running:
```rails
SiteSetting.force_https = false
```
> Last edited by @pfaffman 2025-09-12T22:10:57Z
>
> > **Check document**
> >
> > Perform check on document:
---
### Author:  [@bayardo.rivas](https://meta.discourse.org/u/bayardo.rivas)
#### Post date: [September 11, 2025, 9:13pm UTC](https://meta.discourse.org/t/move-your-discourse-instance-to-a-different-server/15721/94 "2025-09-11T21:13:49Z")
Is this guide still valid 11 years later?
I am running my Discourse on Ubuntu and I want to upgrade the OS from 20.04 LTS â 24.04 LTS with the less downtime. Itâs in AWS.
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [September 11, 2025, 10:45pm UTC](https://meta.discourse.org/t/move-your-discourse-instance-to-a-different-server/15721/95 "2025-09-11T22:45:10Z")
> [@bayardo.rivas](#):
>
> still valid 11 years later?
Thatâs a little pessimistic đ đ
> [@Discourse](#):
>
> Last edited by @SaraDev 2024-11-21T00:47:52Z
---
### Author:  [@Jagster](https://meta.discourse.org/u/Jagster)
#### Post date: [September 12, 2025, 6:06am UTC](https://meta.discourse.org/t/move-your-discourse-instance-to-a-different-server/15721/96 "2025-09-12T06:06:07Z")
Or is it⌠realistic? I.e. Because of this kind of things:
> [@Discourse](#):
>
> Check that the Discourse and PostgreSQL versions match between the source and destination servers.
---
### Author:  [@bayardo.rivas](https://meta.discourse.org/u/bayardo.rivas)
#### Post date: [September 12, 2025, 3:17pm UTC](https://meta.discourse.org/t/move-your-discourse-instance-to-a-different-server/15721/97 "2025-09-12T15:17:57Z")
I think is valid to be concern and ask if this is like the documentation. I recently upgraded my Discourse forum and I got some issues that broke the system, I was just upgrading from one version to the lattest. Something about new plugins that now are in the core system of Discourse.
I think that moving to a different instance with a newer OS is a major change. If Iâm going to try this approach, I would like to have all the feedback as possible.
I appreciate any usefull comments. Thanks.
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [September 12, 2025, 4:13pm UTC](https://meta.discourse.org/t/move-your-discourse-instance-to-a-different-server/15721/98 "2025-09-12T16:13:42Z")
This guide is kind of outside the scope of that specific change.
Core upgrades are in general steps you need to take with an open mind as there are often deprecations and changes.
But thatâs different to migration and this guide is not 11 years old đ
---
### Author:  [@bayardo.rivas](https://meta.discourse.org/u/bayardo.rivas)
#### Post date: [September 12, 2025, 4:56pm UTC](https://meta.discourse.org/t/move-your-discourse-instance-to-a-different-server/15721/99 "2025-09-12T16:56:02Z")
thanks for your comments.
---
### Author:  [@Gunnar](https://meta.discourse.org/u/Gunnar)
#### Post date: [September 12, 2025, 9:41pm UTC](https://meta.discourse.org/t/move-your-discourse-instance-to-a-different-server/15721/100 "2025-09-12T21:41:15Z")
If youâre on Ubuntu 20.04 still, are you using Docker and aufs?
if you are, you should read this before proceeding:
> [@Docker Upgrade Removed AUFS Storage Driver, Killed Discourse](https://meta.discourse.org/t/docker-upgrade-removed-aufs-storage-driver-killed-discourse/308181):
>
> I run a Discourse forum installation on Ubuntu 20.04.6 LTS. The Docker image uses AUFS for storage. Today, I installed upgrades via sudo apt upgrade. Now the Discourse forum is no longer accessible, and it appears to be because a Docker upgrade removed the AUFS storage driver. I see plenty of guides to configuring Docker to use Overlay2 instead, but I donât see any guidance on how to migrate my existing Discourse installation to use Overlay2, especially now that I canât start Docker to mount mâŚ
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [September 12, 2025, 10:07pm UTC](https://meta.discourse.org/t/move-your-discourse-instance-to-a-different-server/15721/101 "2025-09-12T22:07:24Z")
~~I believe so, though I didnât look extra closely.~~ No. The new site will fail to get keys from letâs encrypt if DNS doesnât point to it. So youâd need to backup, transfer the backup, switch DNS to the new server and then rebuild.
If you want to minimize downtime, what I recommend is [Move a Discourse site to another VPS with rsync](https://meta.discourse.org/t/move-a-discourse-site-to-another-vps-with-rsync/43812). This copies over your ssl keys so the new server is ready to go when you do the rebuild.
Unless youâve upgraded to Postgres 15 already (and maybe even then), what Iâd recommend (what I do) is `--exclude postgres*`, rebuild, and then backup the main site and restore that backup on the new server. When thatâs restored, switch the DNS. The rsync directions have you shutdown the datbase so you can copy the raw database files. There are some cases where this wonât work very well, so mostly I make a database-only backup and restore it.
EDIT: I added this to the OP.
> [@Discourse](#):
>
> ### Disclaimer added by @pfaffman 2025-09-12T05:00:00Z.
>
> These instructions donât work well now because youâre now using https and letâs encrypt, which require the new server to have DNS pointed to it so that it can request keys. What I recommend is follow the [Move a Discourse site to another VPS with rsync](https://meta.discourse.org/t/move-a-discourse-site-to-another-vps-with-rsync/43812) (perhaps using `--exclude postgres*` and then backing up and restoring the database from the command line.) This is slick since if you know how, you can tweak your local DNS to point to the new server so you can test that it works while the rest of the internet still sees the old site.
---
### Author:  [@nathank](https://meta.discourse.org/u/nathank)
#### Post date: [October 16, 2025, 2:45am UTC](https://meta.discourse.org/t/move-your-discourse-instance-to-a-different-server/15721/102 "2025-10-16T02:45:06Z")
Thanks Jay! I have wondered why I got a bit stuck on the whole URL / DNS / LetsEncrypt thing in the (recent) past when attempting to follow the instructions in the OP.
I got there in the end by using a subdomain for the new site, ensuring my restored site in the new server was working, and then doing a quick DNS / URLs switch. But that was all a bit sketchy / painful (especially the remap whack-a-mole afterwards!).
Why I needed to do all that makes sense now. And good to know that [rsync](https://meta.discourse.org/t/move-a-discourse-site-to-another-vps-with-rsync/43812) can sidestep some of the pain points.
I think that some clear instructions here would really help others, as it is a bit confusing at the moment - and Iâm not sure the best way to do it in future. Could your disclaimer perhaps be rolled into the whole OP as a re-write (perhaps by @SaraDev?).
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [October 16, 2025, 4:28pm UTC](https://meta.discourse.org/t/move-your-discourse-instance-to-a-different-server/15721/103 "2025-10-16T16:28:50Z")
> [@nathank](#):
>
> I have wondered why I got a bit stuck on the whole URL / DNS / LetsEncrypt thing in the (recent) past when attempting to follow the instructions in the OP.
Thatâs why I suggested not following these instructions. đ¤Ł
> [@nathank](#):
>
> I think that some clear instructions here would really help others, as it is a bit confusing at the moment
I think that ignoring or deleting these instructions and following the rsync topic that I linked is what would help people.
Am I missing something?
---
### Author:  [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [August 11, 2026, 8:28am UTC](https://meta.discourse.org/t/move-your-discourse-instance-to-a-different-server/15721/104 "2026-08-11T08:28:07Z")
Just adding a migration edge case I ran into here, in case it helps someone else.
I hit a Letâs Encrypt/SSL edge case while moving a standalone Discourse instance to a new VPS, so I wrote up the exact diagnosis and recovery steps in case theyâre useful to anyone else following this guide.
In my case, nginx inside `app` would not start because both `.cer` files in `/var/discourse/shared/standalone/ssl/` had become zero-byte files:
```plaintext
PEM_read_bio_X509_AUX() failed
```
Rebuilding attempted certificate issuance again, and after repeated attempts I hit Letâs Encryptâs certificate rate limit. Copying the still-valid certificate files from the old server alone was not sufficient, because starting `app` replaced them with zero-byte files again.
What ultimately fixed it was stopping `app` and copying **both** the working `/var/discourse/shared/standalone/ssl/` directory **and** the corresponding `/var/discourse/shared/standalone/letsencrypt/` state from the old server, then starting the container again.
Iâve documented the full sequence here:
>
These are diagnostic/recovery notes from this particular migration rather than a replacement for the official migration or HTTPS documentation.
There is also an older Meta topic covering the related zero-byte `.cer` failure mode:
> [@Let's Encrypt- empty \*.cer files](https://meta.discourse.org/t/lets-encrypt-empty-cer-files/135241):
>
> I canât connect to a new [standard 30-minute install](https://github.com/discourse/discourse/blob/master/docs/INSTALL-cloud.md). AWS Lightsail, 2GB memory, Ubuntu 18.04 LTS x64 with :443 open. The problem is that the Letâs Encrypt \*.cer files are empty. Why? nginx logs root:/var/log/nginx# ls -ltrh -rw-râr-- 1 www-data www-data 0 Dec 6 05:45 error.letsencrypt.log -rw-râr-- 1 www-data www-data 0 Dec 6 05:45 access.letsencrypt.log -rw-râr-- 1 www-data www-data 1.8M Dec 6 08:19 error.log tail error.log PEM\_read\_bio\_X509\_AUX() failed (SSL: error:0909006C:PEâŚ