Move your Discourse Instance to a Different Server

:bookmark: 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.

:person_raising_hand: Required user level: System Administrator

:warning: 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 (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.

:exclamation: 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, return to the Backups tab, and locate the newly created backup.
  5. Click Download to save the file locally:

:warning: 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

:bulb: To restore the backup via the command line, refer to the relevant documentation.

  1. Sign in as an administrator to your destination Discourse instance.
  2. Navigate to /admin/site_settings, and search for restore. Enable the allow restore setting.
  3. Go to /admin/backups and upload the backup file you downloaded earlier by clicking the Upload button:
  4. After the upload completes, click the Restore button for the uploaded backup:
  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:
    SiteSetting.force_https = false
    

Last edited by @pfaffman 2025-09-12T22:10:57Z

Check documentPerform check on document:
74 curtidas

Este guia ainda Ă© vĂĄlido 11 anos depois?

Estou executando meu Discourse no Ubuntu e quero atualizar o sistema operacional de 20.04 LTS para 24.04 LTS com o mĂ­nimo de tempo de inatividade. EstĂĄ na AWS.

Isso Ă© um pouco pessimista :wink: :slight_smile:

Ou é  realista? Ou seja, por causa desse tipo de coisas:

Acho vålido se preocupar e perguntar se isso é como a documentação. Recentemente, atualizei meu fórum Discourse e tive alguns problemas que quebraram o sistema, eu estava apenas atualizando de uma versão para a mais recente. Algo sobre novos plugins que agora estão no sistema principal do Discourse.

Acho que mudar para uma instùncia diferente com um sistema operacional mais novo é uma grande mudança. Se eu for tentar essa abordagem, gostaria de ter todo o feedback possível.

Agradeço quaisquer comentĂĄrios Ășteis. Obrigado.

Este guia estå um pouco fora do escopo dessa alteração específica.

obrigado pelos seus comentĂĄrios.

Se vocĂȘ ainda estiver no Ubuntu 20.04, vocĂȘ estĂĄ usando Docker e aufs?

Se sim, vocĂȘ deve ler isto antes de prosseguir:

Acredito que sim, embora eu nĂŁo tenha olhado com muita atenção. NĂŁo. O novo site falharĂĄ em obter chaves do Let’s Encrypt se o DNS nĂŁo apontar para ele. Portanto, vocĂȘ precisaria fazer backup, transferir o backup, mudar o DNS para o novo servidor e, em seguida, reconstruir.

Se vocĂȘ quiser minimizar o tempo de inatividade, o que recomendo Ă© Mover um site Discourse para outro VPS com rsync. Isso copia suas chaves SSL para que o novo servidor esteja pronto quando vocĂȘ reconstruir.

A menos que vocĂȘ jĂĄ tenha atualizado para o Postgres 15 (e talvez mesmo assim), o que eu recomendaria (o que eu faço) Ă© --exclude postgres*, reconstruir e, em seguida, fazer backup do site principal e restaurar esse backup no novo servidor. Quando isso for restaurado, mude o DNS. As instruçÔes do rsync pedem para vocĂȘ desligar o banco de dados para que possa copiar os arquivos brutos do banco de dados. Existem alguns casos em que isso nĂŁo funcionarĂĄ muito bem, entĂŁo, na maioria das vezes, faço um backup apenas do banco de dados e o restaure.

EDIT: Adicionei isso ao OP.

1 curtida

Obrigado, Jay! Eu me perguntei por que fiquei um pouco preso com a questão de URL / DNS / LetsEncrypt no passado (recente) ao tentar seguir as instruçÔes no OP.

No final, consegui usando um subdomínio para o novo site, garantindo que meu site restaurado no novo servidor estivesse funcionando e, em seguida, fazendo uma troca rápida de DNS / URLs. Mas tudo isso foi um pouco precário / doloroso (especialmente o jogo de “remap whack-a-mole” depois!).

Agora faz sentido por que precisei fazer tudo isso. E Ă© bom saber que o rsync pode contornar alguns dos pontos problemĂĄticos.

Acho que algumas instruçÔes claras aqui realmente ajudariam os outros, pois é um pouco confuso no momento - e não tenho certeza da melhor maneira de fazer isso no futuro. Seu aviso poderia ser incorporado ao OP como uma reescrita (talvez por @SaraDev?).

É por isso que sugeri nĂŁo seguir estas instruçÔes. :rofl:

Acho que ignorar ou excluir estas instruçÔes e seguir o tópico rsync que eu linkei é o que ajudaria as pessoas.

Estou perdendo alguma coisa?