Migrar para a Zenifra
Este roteiro ajuda a trazer uma aplicação em produção de outra plataforma para a Zenifra com o mínimo de indisponibilidade. A ideia é simples: subir tudo em paralelo, validar com a URL da Zenifra e só então trocar o DNS.
Roteiro em sete etapas
Faça o inventário
Liste cada serviço da aplicação atual: processos web, workers, tarefas agendadas, bancos, cache, variáveis de ambiente, domínios e integrações externas. Cada processo vira um projeto na Zenifra.
Crie a organização e convide a equipe
Crie ou escolha uma organização e convide quem vai participar com as permissões necessárias.
Crie os bancos e serviços gerenciados
Crie os bancos de dados, o cache e as filas antes da aplicação. Assim as URLs de conexão já existem quando você cadastrar as variáveis.
Publique a aplicação
Use o guia do seu framework e a tabela de equivalências abaixo. Copie as variáveis de ambiente da plataforma atual, trocando as URLs de banco e cache pelas novas.
Copie os dados
Siga a seção Migrar o banco de dados. Faça um ensaio completo antes do dia da troca para medir o tempo.
Valide pela URL da Zenifra
Teste a aplicação em *.clients.zenifra.com: login, fluxos principais, envio de e-mails, webhooks e integrações.
Troque o DNS
Reduza o TTL do registro DNS para 300 segundos um dia antes. No horário combinado, congele as escritas na plataforma antiga, faça a cópia final dos dados, configure o domínio na Zenifra e atualize o DNS. Mantenha a plataforma antiga ligada por alguns dias para rollback.
Equivalências por plataforma
| Heroku | Zenifra |
|---|---|
| App | Projeto |
Dyno web do Procfile | Comando start do projeto |
Dyno worker | Outro projeto com o mesmo repositório e outro start |
release: do Procfile | Prefixo do start, como npm run migrate && npm start |
| Config Vars | Variáveis de ambiente |
| Heroku Postgres | PostgreSQL gerenciado |
| Heroku Redis | Cache gerenciado ou Chave-Valor |
| Buildpacks | Runtime Node.js ou Python, ou Imagem OCI para outras linguagens |
| Review Apps | Ambientes de Preview |
$PORT | Campo Porta do projeto. Defina PORT como variável se o código depende dela |
Migrar o banco de dados
PostgreSQL
Exporte do banco atual em formato customizado e restaure na Zenifra usando a URI do console, que já exige TLS:
pg_dump --format=custom --no-owner --no-acl "$URL_ANTIGA" > dump.pgdump
pg_restore --no-owner --no-acl --jobs=4 \
--dbname="postgresql://usuario:senha@host:porta/banco?sslmode=verify-full&sslrootcert=system" \
dump.pgdumpUse uma versão do pg_dump igual ou mais nova que a do banco de origem. --no-owner evita erros de permissão com usuários que não existem na Zenifra.
MariaDB e MySQL
mysqldump --single-transaction --routines --triggers -h HOST_ANTIGO -u USUARIO -p BANCO > dump.sql
mariadb --ssl -h HOST_ZENIFRA -P PORTA -u USUARIO -p BANCO < dump.sqlValidação
Compare a contagem de linhas das tabelas principais nos dois bancos e rode os testes de fumaça da aplicação apontando para o banco novo.
Arquivos e uploads
Copie arquivos do disco ou do bucket atual para o novo destino antes da troca. Se usar armazenamento persistente, uma forma prática é expor um endpoint de importação temporário, protegido por senha, e removê-lo depois.
Checklist do dia da troca
- TTL do DNS reduzido com antecedência
- Aplicação validada na URL
*.clients.zenifra.com - Variáveis revisadas, sem URLs da plataforma antiga
- Webhooks externos (pagamentos, GitHub, e-mail) atualizados para o novo domínio
- Cópia final dos dados concluída e validada
- Domínio configurado e HTTPS ativo
- Plataforma antiga mantida ligada para rollback
Precisa de ajuda na migração?
Para migrações maiores, escreva para [email protected] com o inventário da etapa 1. Veja também a central de ajuda.
Próximos passos
Última atualização em
Checklist antes de ir para produção
Lista prática para revisar deploy, configuração, segurança, banco, observabilidade e cobrança antes de publicar em produção.
Implantação
Entenda os métodos de implantação da Zenifra, quando usar GitHub, Forgejo ou imagem OCI e como validar uma publicação em produção.