Como migrar uma aplicação do deploy manual para o Coolify sem perder dados nem domínio

Fala aí, beleza? Se tua aplicação ainda sobe na base do SSH, cópia de arquivo na mão e banco rodando no próprio servidor, esse post é pra você 😀

A ideia aqui é tirar esse deploy manual e colocar a aplicação rodando no Coolify em uma VPS, cuidando de três coisas que costumam dar dor de cabeça: domínio, dados persistentes e plano de retorno

Se liga num detalhe antes de tudo: o Coolify tem um guia oficial de migração entre instâncias, pensado pra quem já roda Coolify e está trocando de servidor: mas a lógica dele serve de referência pra qualquer migração de app pro Coolify, incluindo a tua, que vem do deploy manual

E essa lógica deixa claro que não existe export/import único: o caminho é recriar, validar e só então trocar o tráfego, com uma janela de manutenção curta no meio

Nada de prometer indisponibilidade zero, beleza? A janela existe e é bom avisar teus usuários

O que você precisa antes de migrar para o Coolify

Pra rodar o Coolify self-hosted, a página de requisitos oficial pede no mínimo:

• 2 núcleos de CPU
• 2 GB de RAM
• 10 GB de disco livre, mais espaço para imagens Docker, volumes e backups
• Arquitetura amd64 ou arm64
• Sistema Linux (só Linux mesmo)
• Servidor com acesso SSH

Além do servidor, tu precisa de acesso ao DNS do teu domínio, porque vai criar registros A apontando pro IP da VPS

E o servidor? Aqui a recomendação principal da Hora de Codar para esse cenário é a VPS da Hostinger (este artigo contém links de afiliado da Hostinger)

O motivo é técnico, não é achismo: a página de VPS para Coolify da Hostinger lista acesso root completo, processadores AMD EPYC, armazenamento NVMe e backups semanais automáticos gratuitos

Os backups semanais automáticos valem para todos os planos VPS, e ainda tem o modelo "Ubuntu 24.04 com Coolify", que já vem com o Coolify pré-instalado

Agora, Tome cuidado na escolha do plano!

O KVM 2 tem 2 vCPU, 8 GB de RAM e 100 GB NVMe, então atende o mínimo de CPU do Coolify com folga de memória pra aplicação

Já o KVM 1 tem 1 vCPU, abaixo do mínimo oficial de 2 núcleos pedido pela documentação do Coolify

Passo a passo da migração do deploy manual para o Coolify

A lógica é a mesma de qualquer mudança de casa: primeiro monta a casa nova, testa se tudo funciona, e só depois leva os móveis e troca o endereço 🙂

1. Preparar o servidor com o Coolify

Na VPS da Hostinger, o caminho mais curto é escolher o modelo "Ubuntu 24.04 com Coolify"

No primeiro acesso ao painel, tu cria a conta de administrador e, se essa for a única máquina, escolhe localhost pra implantar as aplicações no mesmo VPS, conforme o guia do template da Hostinger

Se tu estiver usando outro servidor Linux com acesso SSH, a instalação é pelo comando oficial:

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash

Resultado esperado: painel do Coolify acessível e conta de administrador criada

Erro comum deste passo: subir num servidor abaixo do mínimo (1 núcleo, por exemplo) e depois achar que o problema é a aplicação

2. Mapear o que tem estado na aplicação atual

Antes de mexer em qualquer coisa, lista tudo que a aplicação grava e que não pode sumir: banco de dados, uploads de usuário, arquivos gerados, e por aí vai

Pra cada item, anota também o caminho onde a aplicação espera encontrar esses dados, porque é nesse caminho que o armazenamento persistente vai ser montado

Resultado esperado: uma lista simples tipo "banco X", "pasta de uploads em tal caminho"

Erro comum deste passo: esquecer que, no Coolify, a aplicação roda em contêiner, e dados gravados só no sistema de arquivos do contêiner somem quando ele é removido, então não pula esse mapeamento

3. Recriar a aplicação com domínio temporário

Cria a aplicação no Coolify apontando pra um domínio temporário (um subdomínio de teste, por exemplo) e com credenciais não produtivas

Sim, banco de teste, chaves de teste, nada que mexa em produção ainda

Resultado esperado: a aplicação sobe no Coolify sem tocar no tráfego real

Erro comum deste passo: atribuir o domínio de produção ou mudar o DNS antes da validação, o que joga teus usuários num ambiente que ainda não está pronto

4. Configurar o armazenamento persistente

Aqui entra o mapa do passo 2: cada dado com estado vira um armazenamento persistente montado no caminho que a aplicação espera

O Coolify oferece volume mounts (o padrão recomendado), directory mounts, file mounts e host file mounts

Na dúvida, vai de volume mount

Depois de alterar storage, variáveis de ambiente ou portas, faz deploy ou restart da aplicação, porque essas mudanças só valem num novo deploy

Resultado esperado: os dados continuam lá mesmo depois de um novo deploy

Erro comum deste passo: mudar a configuração e não refazer o deploy, e ficar horas achando que o Coolify ignorou tua alteração haha

5. Validar no domínio temporário

Navega pela aplicação no domínio temporário, faz login, sobe um arquivo de teste, cria um registro

Depois faz um redeploy e confere se o arquivo e o registro continuam lá

Resultado esperado: aplicação funcionando e dados sobrevivendo ao redeploy

Erro comum deste passo: validar só a página inicial e pular as partes que gravam dados, que são justamente as que quebram

6. Abrir a janela de manutenção e mover os dados

Agora sim é hora de levar os móveis

Como os dados continuam mudando enquanto a origem roda, para as escritas ou a aplicação de origem antes de tudo

Com a origem parada, faz o dump final do banco (com a ferramenta nativa dele, tipo pg_dump) e a cópia final dos arquivos, e restaura tudo no destino

E a origem? Fica intacta, não apaga nada ainda

Resultado esperado: destino com os dados mais recentes da produção

Erro comum deste passo: fazer o dump com a origem ainda recebendo escritas, o que deixa pra trás tudo que entrou depois do dump: ou, pior, copiar o volume Docker do banco em execução no lugar de um backup lógico, em vez de usar a ferramenta de dump nativa

7. Apontar o domínio de produção

Cria um registro A pra cada domínio ou subdomínio apontando pro IP da VPS, conforme a documentação de DNS do Coolify

O mesmo IP pode servir vários domínios, então se tu tem app e API em subdomínios diferentes, cada um ganha seu registro A apontando pro mesmo lugar

Com o DNS feito, vai em Domains na aplicação, clica em Add domain, escolhe https no campo Protocol (um seletor separado do campo onde tu digita o domínio) pra ter TLS automático, e no campo Domain digita só o hostname, sem o https:// na frente

Depois salva e faz o redeploy

O proxy do servidor fica responsável por rotear o hostname até a porta do contêiner, então tu não precisa expor porta na mão

Resultado esperado: aplicação respondendo no domínio de produção

Erro comum deste passo: tentar digitar a URL completa com https:// dentro do campo Domain: hoje o protocolo é escolhido no seletor Protocol, separado do campo que recebe só o hostname

Checagem final da migração:

Abre o domínio de produção e confere duas coisas: HTTPS ativo e os dados mais recentes presentes (o último cadastro, o último upload antes da janela)

Se os dois batem, a migração está de pé 😀

Como configurar backups no Coolify depois da migração

Agora que a aplicação está rodando, o próximo trabalho é proteger o estado dela

E aqui vai um ponto que muita gente confunde: armazenamento persistente NÃO é backup

Ele não protege contra exclusão acidental, falha de disco, perda do servidor ou dados corrompidos

Pra banco de dados, o Coolify tem backups agendados para PostgreSQL, MySQL, MariaDB, MongoDB, ClickHouse e SQLite, usando o dump nativo de cada um (pg_dump/pg_dumpall, mysqldump, mariadb-dump, mongodump): Redis, Dragonfly e KeyDB não entram nesse fluxo

O agendamento é por expressão cron, e o destino pode ser opcionalmente um storage compatível com S3

Pra arquivos, o Coolify também agenda backups dos volume mounts e directory mounts da aplicação, de forma local e, opcionalmente, com cópia pra um storage compatível com S3

A documentação recomenda manter pelo menos um backup fora do servidor, então vale MUITO configurar esse destino S3

Os backups semanais automáticos da VPS Hostinger entram como camada adicional, mas não substituem o backup da aplicação: eles cobrem o servidor, e o teu banco e teus uploads merecem uma rotina própria

Erro comum desta etapa: configurar tudo bonitinho e nunca testar a restauração

Backup que nunca foi restaurado é só uma esperança, né? A recomendação é restaurar uma cópia num banco descartável e confirmar que a aplicação consegue ler esses dados antes de tratar o backup como algo confiável

Plano de retorno: o que fazer se a migração para o Coolify der errado

Deu ruim depois da troca? A decisão de voltar fica bem mais simples se tu entender o que o rollback do Coolify faz (e o que ele não faz)

Sintoma:

A aplicação no Coolify começa a falhar depois da migração, e a primeira reação é clicar em rollback esperando voltar tudo como era

Causa do equívoco:

O rollback do Coolify reimplanta uma imagem antiga retida no servidor

Ele não desfaz migrations de banco, não restaura storage persistente e não altera serviços externos

Ou seja, o código volta, mas o estado continua como está

Solução:

O estado se restaura pelos backups, não pelo rollback

Se for preciso voltar de vez, presta atenção numa pegadinha: reapontar o registro A muda o roteamento, mas NÃO mescla dados

Antes de voltar o tráfego pra origem, para as escritas no destino, confere se algum dado de produção mudou lá depois do cutover (um cadastro novo, um upload novo) e sincroniza essas mudanças de volta pra origem

Só então reaponta o registro A pro IP do servidor antigo, liga a origem de novo e confere se o fluxo crítico da aplicação continua de pé

Por isso a regra do passo 6 é tão importante: manter a origem intacta até o destino estar estável é o que te dá essa margem pra sincronizar antes de voltar

Como prevenir:

• Guarda o dump e a cópia final de arquivos antes da troca de DNS
• Mantém pelo menos um backup fora do servidor
• Define antes da migração um critério claro pra declarar o destino estável (por exemplo, um período sem erros e com dados conferidos), e só depois desliga a origem

Vídeo: do zero ao deploy de uma aplicação

Se tu ainda está construindo a aplicação que vai migrar, esse vídeo do canal mostra a criação de um app completo com DeepSeek no Claude Code até chegar no deploy

Próximo passo depois de migrar para o Coolify

Antes de desligar o servidor antigo, agenda o primeiro teste de restauração: pega um backup do banco e um dos volumes e restaura num ambiente separado

Se a restauração funcionar, aí sim tu pode aposentar a origem com tranquilidade

E se tu ainda nem escolheu onde o Coolify vai morar, vale conferir a VPS para este projeto começando pelo KVM 2, que já atende os requisitos mínimos do Coolify

Bora migrar? Até o próximo post! 🙂

Quer aprender mais sobre inteligência artificial e programação na prática? Conheça o canal Hora de Codar no YouTube e acompanhe os próximos vídeos.