Módulo 3, Lição 2 — Colocando no ar: deploy de verdade

Tempo estimado: 5h · Pré-requisito: Lição 1 · Última lição do Módulo 3

---

1. "Funciona na minha máquina" — o problema mais antigo da programação

Toda aplicação nasce rodando no computador de quem construiu, numa espécie de bolha protegida. Deploy é o processo de tirar ela dessa bolha e colocá-la rodando de verdade, num servidor acessível pra qualquer pessoa — e é exatamente aí que tudo que você aprendeu nos Módulos 0 e 2 (VPS, SSH, Nginx, TLS) deixa de ser teoria e vira a coisa que sustenta uma aplicação real.

Essa mesma plataforma que você está usando passou (ou vai passar, se você estiver acompanhando ao vivo) por esse processo exato: local → VPS → domínio público com certificado válido.

---

2. Por que não basta só rodar npm start

Na sua máquina, rodar uma aplicação é simples: um comando, uma janela de terminal aberta, pronto. Numa VPS, isso quebra rápido:

• Se você fechar o terminal (ou a conexão SSH cair), o processo morre junto.
• Se a aplicação travar por algum erro, ninguém reinicia ela sozinha.
• Se a VPS reiniciar (atualização do sistema, por exemplo), nada volta a rodar sozinho.

2.1 PM2 — o "gerente" que nunca dorme

PM2 é um gerenciador de processos: ele roda sua aplicação em segundo plano, reinicia sozinho se ela cair, e guarda os logs organizados. É a peça que transforma "um comando que eu rodei" em "um serviço que fica no ar".

pm2 start npm --name "academia" -- start   # inicia e batiza o processo
pm2 save                                    # grava a lista atual
pm2 startup                                 # garante que volta sozinho após reboot da VPS

Com isso, mesmo que você feche o terminal SSH, a aplicação continua rodando — e se travar por algum motivo, o PM2 reinicia automaticamente.

---

3. Nginx como porteiro (retomando o Módulo 2)

Sua aplicação Next.js, rodando via PM2, escuta numa porta "interna" (por exemplo, 3000) — mas ninguém de fora deveria bater direto nessa porta. O Nginx, que você já viu configurado nas VPS ao longo do curso, entra de novo aqui com o mesmo papel: recebe as requisições que chegam nas portas públicas (80/443) e as encaminha internamente pra porta onde sua aplicação está — um padrão chamado proxy reverso.

server {
    server_name academia.seudominio.com;

    location / {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    listen 443 ssl;
    # certificado gerenciado pelo Certbot, ver seção 4
}

Por que não simplesmente deixar a aplicação escutar direto na porta 443? Porque o Nginx traz de graça um monte de coisa que você não quer reimplementar: TLS, compressão, cabeçalhos de segurança, limite de taxa de requisições (você já configurou tudo isso nas lições anteriores!) — e permite que várias aplicações diferentes dividam a mesma VPS, cada uma no seu próprio domínio/subdomínio, sem conflito de porta.

---

4. Certbot — o certificado que se renova sozinho

Um site acessado por https:// precisa de um certificado TLS válido (o mesmo assunto que apareceu quando você configurou a VPS pela primeira vez). Tirar esse certificado manualmente, e lembrar de renovar antes de expirar, é chato e arriscado de esquecer.

O Certbot automatiza isso de ponta a ponta: pede um certificado gratuito (via Let's Encrypt), configura o Nginx sozinho, e agenda a renovação automática — você não precisa lembrar de nada depois de rodar uma vez.

certbot --nginx -d academia.seudominio.com

---

5. O checklist completo — do código ao ar

Juntando tudo (inclusive o que você já sabe dos módulos anteriores), esse é o caminho real que uma aplicação percorre até virar um site de verdade:

1. Código pronto localmente, testado (Lição 1 deste módulo).
2. Banco de dados na VPS — o mesmo Postgres que você já viu rodar em outras lições, só que com um banco novo e isolado pra essa aplicação.
3. Build de produção — npm run build, que otimiza o código pra rodar rápido (diferente do modo de desenvolvimento, mais lento mas com recarregamento automático).
4. PM2 mantendo o processo vivo (seção 2).
5. Nginx como porteiro, encaminhando o domínio público pra porta interna (seção 3).
6. Certbot garantindo HTTPS válido e renovado sozinho (seção 4).
7. Firewall (UFW/fail2ban) — o mesmo que você configurou lá atrás, protegendo a porta SSH e liberando só 80/443 pro público.

Nenhum desses passos é novo de verdade — é a mesma caixa de ferramentas dos módulos anteriores, só que agora aplicada a "colocar uma aplicação no ar" em vez de "proteger um servidor".

---

6. Exercícios práticos

Exercício 1 — Se você tem uma VPS de prática (do Módulo 0), instale o PM2 nela:

npm install -g pm2

Exercício 2 — Rode qualquer script Node simples via PM2 (pm2 start meuarquivo.js), depois feche a conexão SSH e reabra — confirme com pm2 list que o processo continua rodando.

Exercício 3 (reflexão) — Por que faz sentido o Nginx (não a própria aplicação) cuidar do certificado TLS? Pense na resposta considerando o que aconteceria se cada aplicação numa mesma VPS tivesse que gerenciar seu próprio certificado separadamente.

Exercício 4 (gravação) — Se você já tem uma aplicação simples rodando local (mesmo que só um "Hello World"), grave o processo completo: subir na VPS, configurar PM2, apontar o Nginx, rodar o Certbot, e ver funcionando no navegador com o cadeado de HTTPS.

Responda o questionário abaixo pra fechar o Módulo 3.