Melhor alojamento para Next.js: plataformas geridas vs VPS

Next.js é uma framework React capaz de gerar dois tipos de saída muito diferentes, e a sua escolha de alojamento decorre diretamente de qual dos dois você distribui. Um site 100% estático é apenas um conjunto de ficheiros servidos por um CDN ; uma app renderizada no servidor é um processo Node.js de longa duração que tem de se manter vivo. Confunda os dois e acaba por pagar demais por um site estático, ou distribui uma app dinâmica onde ela não consegue correr. Este guia explica os modos de renderização e depois compara honestamente o compromisso entre uma plataforma gerida e um VPS auto-alojado.

Primeiro, decida como a sua app renderiza

A pergunta mais importante é se a sua aplicação é estática ou precisa de um servidor no momento do pedido. O Next.js suporta ambos, e têm requisitos de alojamento completamente diferentes.

• Exportação estática - com output: 'export', o Next.js constrói HTML, CSS e JavaScript simples em tempo de build. Não há servidor : o resultado é uma pasta de ficheiros que qualquer host estático ou CDN pode servir. Barato e simples, mas exclui tudo o que corre por pedido.
• Renderizado no servidor (SSR / ISR / rotas API) - a renderização no servidor, a regeneração estática incremental, os manipuladores de rotas e o middleware executam todos código quando chega um pedido. Isso precisa de um runtime Node.js que corra a sua build e se mantenha vivo para responder aos pedidos.

Pode verificar o que o seu projeto usa : se depende de getServerSideProps, componentes de servidor que fazem fetch no pedido, rotas API sob app/api ou pages/api, ou revalidação ISR, é uma app de servidor. Se cada página puder ser gerada antecipadamente, a exportação estática é uma opção.

Opção 1: uma exportação estática em qualquer host estático

Se a sua app for 100% estática, o alojamento é trivial e barato. Defina a saída como export, faça a build e distribua a pasta gerada num host estático ou CDN :

// next.config.js
module.exports = {
  output: 'export',
};

# a build produz uma pasta estatica 'out/'
npm run build

# 'out/' contem agora HTML, CSS e JS que pode carregar em qualquer lugar

A pasta out/ são apenas ficheiros, por isso funciona em qualquer host estático com um CDN global e HTTPS gratuito. É o mesmo modelo abordado no nosso guia sobre alojamento de sites estáticos. O senão é que uma exportação estática não consegue fazer renderização no servidor, ISR, otimização de imagens em tempo real nem rotas API - essas funcionalidades simplesmente não existem sem um servidor.

Opção 2: uma plataforma gerida

As plataformas geridas constroem a sua app a partir de um push Git e executam o servidor por si, tratando do escalonamento, do TLS e da pipeline de build. A Vercel é a mais notável aqui porque é a empresa que desenvolve o Next.js, por isso a sua plataforma acompanha de perto as novas funcionalidades da framework. Outras plataformas como a Netlify também suportam o Next.js através dos seus próprios adaptadores.

O apelo é real : faz git push e a plataforma executa todo o fluxo, por isso não há servidor para atualizar nem proxy inverso para configurar. O compromisso é o controlo e o custo. Você trabalha dentro do modelo de build e execução da plataforma, e uma tarifação por utilização pode subir à medida que crescem o tráfego, a execução de funções e a largura de banda. Para um projeto pequeno, os planos gratuitos ou baixos são generosos ; para uma app com muito tráfego, a fatura cresce com a utilização, que é precisamente o ponto em que o auto-alojamento começa a tornar-se atrativo.

Opção 3: auto-alojamento num VPS

Como uma app Next.js renderizada no servidor é, no fim de contas, um processo Node.js, pode executá-la você mesmo num VPS - da mesma forma que alojaria qualquer app Node. É a opção mais flexível e normalmente a mais barata em escala, em troca de assumir você mesmo o trabalho de operações. A build produz um servidor que arranca com next start :

# no servidor: instalar as dependencias e fazer a build
npm ci
npm run build

# arrancar o servidor de producao (porta 3000 por omissao)
npm run start

Como com qualquer processo Node de longa duração, não deve arrancar next start à mão numa sessão SSH. Use um gestor de processos como o PM2 para o manter vivo e reiniciá-lo após uma falha ou um reinício, e coloque um proxy inverso à frente dele. É exatamente o padrão do nosso guia sobre alojar uma app Node.js :

# manter o servidor Next.js vivo com PM2
pm2 start "npm run start" --name next-app
pm2 startup
pm2 save

Depois aponte o Nginx ao processo Node para que termine o TLS e encaminhe o tráfego público para a porta 3000 :

server {
  listen 80;
  server_name yourapp.com;

  location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
  }
}

Adicione HTTPS com um certificado automatizado gratuito (ferramentas como o Certbot tornam isto uma única linha). Para dimensionar a máquina, os critérios são os mesmos de qualquer app web - primeiro a memória, depois a CPU - abordados no nosso guia sobre como escolher o melhor VPS para um projeto web. Fornecedores focados numa boa relação recursos-preço, como a Contabo ou a Hetzner, oferecem RAM e vCPU generosos a um custo mensal baixo, o que se adequa bem a uma build e a um runtime Node.

Como as opções se comparam

Abordagem	Executa o quê	Você gere	Ideal quando
Exportação estática	Ficheiros num CDN (sem servidor)	Apenas uma build e upload	Cada página pode ser pré-gerada
Plataforma gerida	SSR, ISR, rotas API	Apenas o seu código e variáveis de ambiente	Quer publicar depressa, pouco trabalho de operações
VPS (auto-alojado)	SSR, ISR, rotas API	SO, Node, PM2, Nginx, TLS	Quer controlo e custo previsível

Como decidir

Parta de como a sua app renderiza, não do marketing de um fornecedor. Se cada página puder ser gerada antecipadamente, publique uma exportação estática e aloje-a a baixo custo num CDN. Se precisar de SSR, ISR ou rotas API, precisa de um runtime Node.js - e então resume-se a um compromisso familiar : uma plataforma gerida é a forma mais rápida de publicar e o menor trabalho de operações, enquanto um VPS é mais barato em escala e dá-lhe controlo total, em troca de executar você mesmo o Node, um gestor de processos, um proxy inverso e o TLS. Escolha a opção mais pequena que cubra o que a sua app realmente precisa, e suba de nível apenas quando o escalonamento ou a carga operacional se tornarem o verdadeiro estrangulamento.