Como rodamos Next.js em produção num VPS
A configuração exata que usamos para hospedar nossos próprios produtos Next.js — gerenciadores de processo, reverse proxy, deploys sem downtime e os erros que cometemos até chegar aqui.
Por Anested Engineering
Todo produto da Anested — incluindo este site — roda na mesma infraestrutura Anested Clouds que vendemos aos clientes. Essa restrição nos mantém honestos. Se um padrão de deploy é frágil demais para os nossos próprios produtos, ele não tem o direito de ser padrão no VPS de mais ninguém.
Nossa stack Next.js de produção é deliberadamente entediante, e dizemos isso como elogio. Um VPS com uma versão Node.js LTS fixada, um gerenciador de processos que reinicia a aplicação em caso de falha e um reverse proxy terminando TLS na frente. Sem cluster de orquestração, sem service mesh, sem contêineres sidecar. Nenhuma das nossas cargas de trabalho mereceu essa complexidade ainda, e fingir o contrário significaria apenas mais coisas quebrando às duas da manhã.
Deploy sem downtime é o único lugar onde investimos esforço real de engenharia. Cada release é construída em um diretório separado enquanto a versão antiga continua servindo tráfego. Rodamos health checks no novo build em uma porta interna, e só quando ele responde corretamente trocamos o upstream do reverse proxy. Se algo parecer errado dez minutos depois, o rollback é uma troca de symlink e um reload — não um redeploy desesperado.
O maior erro que cometemos no início foi tratar logs como algo secundário. Quando algo quebrava, estávamos fazendo SSH nos servidores e vasculhando arquivos espalhados. Hoje toda aplicação envia logs estruturados para um repositório central desde o primeiro dia, e o engenheiro de plantão consegue responder à pergunta 'o que mudou?' em menos de um minuto. Esse único hábito reduziu nosso tempo de resolução de incidentes mais do que qualquer compra de ferramenta.
Cache merece menção porque o Next.js oferece tantas camadas dele — páginas estáticas em build, revalidação incremental, headers de CDN. Nossa regra é cachear agressivamente na borda para tráfego anônimo e nunca para páginas autenticadas. Regras entediantes e explícitas vencem regras espertas que você não consegue explicar durante uma queda.
Se você quer essa mesma configuração sem construí-la você mesmo, é literalmente isso que a Anested Clouds vende. Os padrões descritos neste post são os defaults de cada novo VPS que provisionamos — porque rodamos nossa própria empresa neles.
Precisa de ajuda com algo deste post?
Nossos engenheiros respondem diretamente — hospedagem, bancos de dados, código ou qualquer assunto deste post.