Checklist antes de ir para produção

Use este checklist antes de apontar tráfego real para uma aplicação na Zenifra. Ele ajuda a revisar os pontos que mais causam falhas em produção: porta, variáveis, banco, logs, domínio, permissões e cobrança.

Aplicação

• a aplicação sobe localmente com o mesmo comando configurado no console
• a porta configurada na Zenifra corresponde à porta usada pela aplicação
• o servidor escuta em 0.0.0.0, não apenas em localhost
• existe uma rota simples de saúde, como /health
• dependências estão declaradas em package.json, package-lock.json ou requirements.txt
• segredos não estão versionados no repositório

Deploy

• origem escolhida é adequada: repositório GitHub ou Forgejo para build a partir do código, OCI para imagem pronta
• branch de produção está correta
• o modo Automático por branch foi selecionado somente se a branch monitorada for estável
• tags de imagem OCI identificam versões reais
• a porta do projeto corresponde à porta exposta pela imagem OCI, como 80 no NGINX oficial
• logs de build foram revisados após a última publicação
• rollback operacional foi planejado antes de mudanças críticas
• a equipe sabe que os logs de build ficam em Logs de build e que isso é diferente dos logs da aplicação

Variáveis e segredos

• DATABASE_URL foi configurada manualmente, se houver banco
• chaves de API, tokens e senhas estão em variáveis de ambiente
• nomes de variáveis seguem o padrão usado pela aplicação
• valores de produção não reutilizam credenciais locais ou de teste
• equipe sabe quem pode editar variáveis no console

Banco de dados

• engine e versão foram escolhidas conforme a aplicação
• storage foi dimensionado para produção
• regra de aumento de storage foi entendida
• pool de conexões está configurado na aplicação
• migrações foram testadas antes do deploy
• dados de conexão foram guardados em local seguro
• existe uma rotina própria de dumps ou exports, com restauração testada, porque a Zenifra não oferece backup automático com restauração pelo console

Observabilidade

• logs aparecem no console (logs da aplicação em todos os planos, lidos ao vivo e sem histórico retido)
• métricas de CPU, RAM, storage e requisições HTTP foram verificadas
• equipe sabe onde consultar logs de build e logs da aplicação
• alertas por e-mail foram ativados e alertas externos ou rotina de acompanhamento foram definidos quando necessários
• a equipe acompanha incidentes da plataforma em status.zenifra.com
• rota de diagnóstico mostra versão ou commit quando isso for útil para suporte

Segurança e acesso

• permissões da organização foram revisadas
• membros têm apenas os acessos necessários
• API keys foram guardadas com segurança
• whitelist ou blacklist foi configurada quando o projeto é interno (a partir do plano Premium Plus)
• domínio próprio aponta para o destino correto
• plano de resposta a incidente foi combinado internamente

Cobrança

• crédito ou forma de pagamento está disponível
• modalidade de cobrança foi entendida
• custo de storage persistente foi considerado
• consumo de IA foi limitado por budget quando aplicável
• pessoa responsável por billing tem acesso no console

Próximos passos

• Deploy em produção na Zenifra
• Observabilidade
• Segurança, privacidade e confiabilidade
• Modelos de Pagamento

FAQ

Preciso concluir todos os itens?

Para produção real, sim. Em ambientes de teste, alguns itens podem ser simplificados, mas porta, variáveis, logs e cobrança devem ser revisados sempre.

O checklist substitui testes da aplicação?

Não. Ele revisa operação na Zenifra. Testes unitários, integração, carga e migração continuam sendo responsabilidade do projeto.

Quando revisar novamente?

Revise antes de mudanças grandes, troca de plano, aumento de instâncias, alteração de banco, troca de domínio ou mudança em variáveis críticas.