O mínimo que um desenvolvedor precisa saber antes de colocar um app em produção

Por que existe um mínimo

Não é perfeccionismo — é o básico que evita desastre

Ninguém precisa dominar todos os conceitos de engenharia de software antes de publicar qualquer projeto. Mas existe um conjunto mínimo de conhecimentos que separa um deploy seguro de uma bomba-relógio esperando para explodir. Esse mínimo não é exigente: não exige anos de experiência, arquitetura perfeita nem infraestrutura complexa. É a diferença entre um app que aguenta os primeiros usuários reais e um app que destrói dados, trava em produção ou vira alvo fácil na primeira semana. Este post é o checklist mental que todo desenvolvedor deveria revisar antes de apertar o botão de deploy.

Segurança básica: as três regras que não têm exceção

Segurança mínima não é opcional — é o piso

Antes de qualquer deploy, três regras de segurança são inegociáveis. Primeira: nunca armazenar senha em texto simples — sempre usar hashing com bcrypt, Argon2 ou similar. Segunda: nunca colocar credenciais (senhas de banco, API keys, tokens secretos) diretamente no código ou no repositório — usar variáveis de ambiente e um arquivo de secrets que fica fora do git. Terceira: validar e sanitizar toda entrada de dados externa — todo campo de formulário, todo parâmetro de URL, todo payload de API pode conter dados maliciosos e precisa ser tratado com desconfiança antes de ser processado.

Autenticação: quem pode entrar e por quanto tempo

Login funcionando é diferente de login seguro

Um sistema de autenticação mínimo precisa de: tokens com expiração (não podem ser válidos para sempre), controle de tentativas de login (bloquear ou adicionar CAPTCHA após falhas repetidas), invalidação correta de sessão ao sair (logout deve destruir o token no servidor, não só no cliente) e HTTPS obrigatório (credenciais não podem trafegar em HTTP). Ferramentas como Auth0, Clerk ou Supabase Auth implementam tudo isso de forma gerenciada. Para quem implementa do zero, JWT com expiração curta mais refresh token rotativo é o padrão mais seguro e amplamente adotado.

Banco de dados: o que não pode dar errado

Dados perdidos não se recuperam — dados corrompidos pioram tudo

Antes de ir a produção, o banco de dados precisa ter: backup automático configurado (diário no mínimo, com retenção de ao menos sete dias), índices nas colunas usadas em filtros e buscas frequentes (sem índice, o banco varre a tabela inteira para cada query), e conexão segura com credenciais exclusivas para a aplicação (não usar root). Para operações que precisam ser completas ou não acontecer (transferência de saldo, criação de pedido com estoque), transações são obrigatórias. Dado sem backup é dado emprestado — mais cedo ou mais tarde algo vai errar e você vai precisar dele.

Monitoramento mínimo: saber quando algo quebra

Você não pode consertar o que não sabe que está quebrado

Monitoramento mínimo não exige Prometheus, Grafana nem stack de observabilidade completa. O mínimo é: logs persistentes com nível de erro (qualquer exceção não tratada deve ser registrada com contexto suficiente para diagnóstico), notificação quando o serviço cai (Uptime Robot, Better Uptime ou similar — gratuitos para monitoramento básico) e rastreamento de erros não tratados (Sentry tem plano gratuito e captura stack trace, contexto e frequência de cada erro). Com esses três elementos, você descobre problemas antes de o usuário reclamar — o que é a diferença entre consertar rápido e perder confiança.

Deploy: como publicar sem destruir o que estava funcionando

O processo de publicação precisa ser seguro e reversível

Um deploy seguro tem duas propriedades: é reproduzível (funciona da mesma forma toda vez, não depende de passos manuais que podem ser esquecidos) e é reversível (se algo der errado, é possível voltar para a versão anterior em minutos). Isso não exige CI/CD completo desde o início: um script de deploy simples que faz build, copia arquivos, reinicia o serviço e valida que a aplicação subiu já é infinitamente melhor que arrastar arquivos manualmente. Antes de deployar: testar localmente, fazer backup do banco, garantir que variáveis de ambiente do ambiente de produção estão corretas.

Rate limiting: proteger o sistema contra sobrecarga e abuso

Sem limite de requisições, qualquer endpoint pode virar um ataque

Rate limiting é o mecanismo que controla quantas requisições um usuário ou IP pode fazer em um determinado período. Sem ele, um endpoint de login pode ser bombardeado com mil tentativas por segundo em ataque de força bruta. Um endpoint de busca pode ser abusado para raspar todo o banco de dados. Uma notificação em tempo real pode ser disparada em loop sem custo para o atacante. A implementação básica — limitar por IP ou por usuário autenticado, com respostas 429 Too Many Requests quando o limite é atingido — pode ser feita com middleware simples e resolve a maioria dos casos de abuso involuntário e automatizado.

Validação de dados: a fronteira entre o sistema e o mundo externo

Nenhum dado externo pode ser confiado sem verificação

Todo dado que entra no sistema por requisição HTTP, webhook, upload de arquivo ou integração com serviço externo precisa ser validado antes de ser processado. Validação mínima inclui: verificar tipo e formato dos campos (um campo de email deve ser um email, um ID deve ser um UUID válido), verificar presença dos campos obrigatórios (não processar requisição com campos faltando), limitar tamanho (um campo de texto não pode aceitar megabytes de dados) e rejeitar com mensagem clara quando a validação falha. Frameworks modernos têm suporte nativo a validação declarativa — usá-la não adiciona complexidade, elimina vulnerabilidades.

Variáveis de ambiente e segredos: nada sensível no código

Um repositório público com credenciais é uma porta aberta

Chaves de API, senhas de banco de dados, tokens de autenticação, URLs internas de serviços — nada disso pode estar no código-fonte. O padrão é usar variáveis de ambiente: o código lê as credenciais do ambiente em que está rodando, não de um arquivo commitado. Localmente, um arquivo .env (excluído do git via .gitignore) armazena os valores. Em produção, as variáveis são configuradas no servidor ou na plataforma de deploy. Se o repositório for público — ou se tornar público por acidente — nenhuma credencial real deve estar exposta. Bots automatizados varrem repositórios GitHub em busca de chaves expostas em segundos.

O checklist antes do deploy

Revisar uma vez evita acordar às três da manhã para apagar incêndio

Antes de qualquer deploy em produção: senhas são hasheadas (nunca texto simples), credenciais estão em variáveis de ambiente e fora do git, autenticação tem expiração de token e controle de tentativas, banco tem backup configurado e índices nas colunas críticas, logs de erro estão ativos e persistentes, monitoramento de uptime está configurado, rate limiting existe nos endpoints públicos, validação de dados está em todas as entradas externas, e o processo de deploy é um script reproduzível com rollback possível. Esse checklist não garante um sistema perfeito — garante que os erros mais comuns e mais destrutivos já foram antecipados. Continue em: Fundamentos obrigatórios antes de produção.