---
title: "Como hospedar Next.js na VPS com PM2, Nginx e HTTPS"
description: "Hospede Next.js na VPS: build com next start ou standalone, PM2 com reinício no boot, Nginx com streaming, domínio, HTTPS e deploy sem derrubar o site."
url: "https://streethosting.com.br/guias/vps/hospedar-nextjs-vps"
category: "vps"
slug: "hospedar-nextjs-vps"
datePublished: "2026-09-28"
dateModified: "2026-09-28"
author: "Equipe StreetHosting"
difficulty: "intermediario"
language: "pt-BR"
keywords:
  - "hospedar nextjs vps"
  - "next.js output standalone"
  - "deploy nextjs pm2 nginx"
  - "nextjs self hosting vps"
  - "next start producao"
---

# Next.js em produção na sua VPS, do build ao HTTPS

Next.js roda completo em uma VPS com Node, incluindo renderização no servidor, ISR e Server Actions. Veja como fazer o build, manter o processo vivo com PM2, colocar o Nginx na frente e atualizar sem quebrar o site.

> **Resposta rápida**
>
> Para **hospedar Next.js na VPS**, instale o Node.js LTS, rode `npm ci` e `npm run build`, suba a aplicação com PM2 escutando só em 127.0.0.1:3000 e coloque o Nginx na frente com HTTPS do Let's Encrypt. Ative o reinício no boot com `pm2 startup` e desligue o buffering do Nginx para o streaming funcionar.

## next start, standalone ou export: qual usar

Antes de instalar qualquer coisa, decida como o site vai rodar. O Next.js tem três saídas de produção, e a escolha muda o que precisa existir na VPS.

| Modo | Como roda | Vantagem | Quando usar |
| --- | --- | --- | --- |
| next start | Processo Node com o node_modules completo do projeto | Mais simples, igual ao ambiente local | Build feito na própria VPS |
| output standalone | node server.js com só as dependências rastreadas | Pasta enxuta, sobe sem npm install | Build no CI ou em Docker, deploy por cópia de arquivos |
| output export | HTML estático servido direto pelo Nginx | Sem Node em produção, consumo mínimo | Site sem renderização no servidor, sem rotas de API e sem Server Actions |

Este guia cobre os dois primeiros, que mantêm todos os recursos do framework. A base de Node, PM2 e Nginx é a mesma de qualquer aplicação Node, detalhada no guia de [hospedar Node.js na VPS](https://streethosting.com.br/guias/vps/hospedar-api-nodejs-vps-brasil); aqui o foco é no que o Next.js tem de particular: build pesado, variáveis embutidas no JavaScript, arquivos estáticos e streaming.

O export estático merece consideração antes de descartar. Landing pages, documentação e blogs sem conteúdo por usuário ficam mais baratos e mais rápidos servidos como HTML puro pelo Nginx, sem processo Node para manter. A troca é perder tudo que depende de servidor: rotas de API, Server Actions, ISR, cookies lidos na renderização e otimização de imagem sem um loader externo.

## Preparar a VPS: Node.js LTS e PM2

O Next.js 16 exige Node.js 20.9 ou mais novo, mas a linha 20 já saiu de suporte. Use a LTS ativa, o Node.js 24, instalada pelo repositório da NodeSource. Assim o binário fica em `/usr/bin/node` e o PM2 encontra o mesmo Node no boot, sem surpresa de caminho.

```
curl -fsSL https://deb.nodesource.com/setup_24.x | sudo -E bash -
sudo apt install -y nodejs git
node -v
sudo npm install -g pm2

sudo mkdir -p /var/www/meu-site
sudo chown $USER:$USER /var/www/meu-site
```

Rode tudo com um usuário comum com sudo, nunca como root. A pasta em `/var/www` evita um problema do Ubuntu 24.04: as pastas pessoais em `/home` vêm fechadas para outros usuários, e o Nginx não conseguiria ler arquivos de lá se um dia você quiser servir estáticos direto do disco.

> **Atenção**
>
> O `next build` consome bem mais memória do que o site rodando. Em VPS de 2 GB, crie swap antes do primeiro build, seguindo o guia de [swap no Ubuntu](https://streethosting.com.br/guias/vps/configurar-swap-ubuntu-vps), ou o processo morre no meio sem mensagem clara.

## Build e variáveis de ambiente

Organize a pasta em três partes desde o primeiro deploy: `releases` guarda cada versão construída, `shared` guarda o que não muda entre versões (o arquivo de ambiente) e `current` é um link simbólico para a versão no ar. Parece exagero agora, mas é essa estrutura que permite atualizar sem derrubar o site mais adiante.

```
cd /var/www/meu-site
mkdir -p releases shared
nano shared/.env.production
chmod 600 shared/.env.production

git clone https://github.com/sua-conta/meu-site.git releases/v1
cp shared/.env.production releases/v1/
cd releases/v1
npm ci
npm run build

ln -sfn /var/www/meu-site/releases/v1 /var/www/meu-site/current
```

O `npm ci` instala as dependências exatamente como estão no lockfile, sem atualizar nada por conta própria, o que evita que a produção rode versões diferentes das que você testou.

O detalhe que mais confunde quem sai da hospedagem gerenciada está nas variáveis. Por padrão, variáveis de ambiente só existem no servidor. As que começam com `NEXT_PUBLIC_` são copiadas para dentro do JavaScript do navegador durante o build. Resultado: trocar uma delas no arquivo e reiniciar não muda nada, é preciso rodar o build de novo. Páginas geradas estaticamente no build também congelam os valores lidos naquele momento.

### Modo standalone

Para o modo standalone, ative a opção no arquivo de configuração:

```
// next.config.ts
import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  output: "standalone",
};

export default nextConfig;
```

O build cria `.next/standalone` com um `server.js` e só os pacotes que o código realmente usa. As pastas `public` e `.next/static` não são copiadas por padrão; sem elas o site abre sem CSS, sem JavaScript e sem imagens. Copie depois de cada build:

```
cp -r public .next/standalone/
cp -r .next/static .next/standalone/.next/
```

> **Dica**
>
> Se o build acontece no CI, use um executor Linux x64, igual à VPS. A pasta standalone leva binários nativos, como o sharp usado na otimização de imagens, e um build feito no Windows ou no macOS copia o binário errado.

## Rodando com PM2 e reinício no boot

O PM2 mantém o processo vivo, reinicia se ele cair e sobe de novo depois de um reboot. Crie o arquivo de configuração em `/var/www/meu-site`, fora das versões, apontando para o link `current`. Para `next start`:

```
// /var/www/meu-site/ecosystem.config.js
module.exports = {
  apps: [
    {
      name: "meu-site",
      cwd: "/var/www/meu-site/current",
      script: "node_modules/next/dist/bin/next",
      args: "start -H 127.0.0.1 -p 3000",
      instances: 1,
      exec_mode: "fork",
      max_memory_restart: "700M",
      env: { NODE_ENV: "production" },
    },
  ],
};
```

No modo standalone, o processo é o próprio `server.js`, que lê a porta e o endereço das variáveis `PORT` e `HOSTNAME`. Passe também as variáveis de runtime que a aplicação usa:

```
{
  name: "meu-site",
  cwd: "/var/www/meu-site/current/.next/standalone",
  script: "server.js",
  env: {
    NODE_ENV: "production",
    PORT: "3000",
    HOSTNAME: "127.0.0.1",
    DATABASE_URL: "postgresql://app:senha@127.0.0.1:5432/app",
  },
}
```

Inicie, salve a lista de processos e gere o serviço de boot:

```
cd /var/www/meu-site
pm2 start ecosystem.config.js
pm2 save
pm2 startup systemd
# copie e rode a linha com sudo que o comando acima imprimir
curl -I http://127.0.0.1:3000
```

Escutar em 127.0.0.1 é proposital: a porta 3000 fica inalcançável de fora e todo o tráfego passa pelo Nginx. As diferenças entre PM2 e um serviço systemd puro estão no guia de [PM2 e systemd na VPS](https://streethosting.com.br/guias/vps/configurar-pm2-startup-systemd-vps).

Os logs do PM2 crescem sem limite por padrão. Instale o módulo de rotação uma vez e esqueça o assunto: `pm2 install pm2-logrotate`. Para acompanhar erros em tempo real, use `pm2 logs meu-site`.

Comece com uma instância. O modo cluster do PM2 funciona, mas cada processo guarda o próprio cache em memória, e revalidações de ISR ou por tag podem não chegar a todos ao mesmo tempo. Se precisar de mais processos, leia antes a parte de múltiplas instâncias da documentação de self hosting do Next.js.

## Nginx, domínio e HTTPS

Aponte o domínio para o IP da VPS com um registro A para o domínio e outro para o www, como explica o guia de [DNS para VPS](https://streethosting.com.br/guias/vps/apontar-dominio-vps-registro-dns). Depois instale o Nginx e crie o site:

```
sudo apt install -y nginx
sudo nano /etc/nginx/sites-available/meu-site
```

```
server {
    listen 80;
    listen [::]:80;
    server_name seu-dominio.com.br www.seu-dominio.com.br;

    client_max_body_size 10m;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_buffering off;
    }
}
```

- **Cabeçalhos Forwarded:** o Next.js usa o Host e o protocolo originais para montar URLs e validar a origem das Server Actions. Sem eles, formulários podem falhar atrás do proxy.
- **proxy_buffering off:** o App Router envia a página em partes (loading e Suspense). Com buffering ligado, o Nginx segura tudo e entrega de uma vez, anulando o streaming.
- **client_max_body_size:** o padrão do Nginx é 1 MB. Ajuste se o site recebe uploads.

Ative o site, libere o firewall e emita o certificado:

```
sudo ln -s /etc/nginx/sites-available/meu-site /etc/nginx/sites-enabled/
sudo rm -f /etc/nginx/sites-enabled/default
sudo nginx -t && sudo systemctl reload nginx

sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable

sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d seu-dominio.com.br -d www.seu-dominio.com.br
sudo certbot renew --dry-run
```

O Certbot edita o bloco do Nginx, cria o redirecionamento de HTTP para HTTPS e agenda a renovação automática pelo timer do systemd. Cabeçalhos de segurança e diagnóstico de falhas de emissão estão no guia de [certificado SSL com Let's Encrypt e Nginx](https://streethosting.com.br/guias/vps/certificado-ssl-vps-lets-encrypt-nginx).

### E o cache dos arquivos estáticos?

Não precisa configurar no Nginx. O Next.js já responde os arquivos de `/_next/static` com cache público de um ano marcado como imutável, porque o nome de cada arquivo carrega um hash do conteúdo. Páginas dinâmicas saem com cache privado, para que dados de um usuário nunca fiquem guardados para outro. Se um dia você colocar uma CDN na frente, ela aproveita esses mesmos cabeçalhos sem regra extra.

## Atualizar sem derrubar o site

O jeito ingênuo de atualizar é `git pull` seguido de `npm run build` na mesma pasta. O problema: o build apaga e recria a pasta `.next` enquanto o site ainda roda a partir dela, e durante minutos visitantes recebem páginas quebradas. A solução é construir cada versão em uma pasta separada e só trocar um link simbólico quando o build terminar.

```
#!/usr/bin/env bash
# /var/www/meu-site/deploy.sh
set -euo pipefail

APP=/var/www/meu-site
RELEASE="$APP/releases/$(date +%Y%m%d%H%M%S)"

git clone --depth 1 https://github.com/sua-conta/meu-site.git "$RELEASE"
cp "$APP/shared/.env.production" "$RELEASE/"
cd "$RELEASE"
npm ci
npm run build

ln -sfn "$RELEASE" "$APP/current"
pm2 startOrReload "$APP/ecosystem.config.js" --update-env

# guarda as cinco versões mais recentes para rollback
ls -dt "$APP"/releases/* | tail -n +6 | xargs -r rm -rf
```

É a mesma sequência do primeiro deploy, só que automática: a versão nova é construída em outra pasta enquanto a antiga continua atendendo, e o link `current` só muda quando o build termina sem erro. Se estiver usando standalone, acrescente as duas cópias de pastas logo depois do build. Voltar uma versão é apontar o link para a pasta anterior e recarregar o PM2. Com uma instância em modo fork, o reload ainda deixa um intervalo de um ou dois segundos; o build, que é a parte demorada, já não afeta ninguém.

Esse script é o ponto de partida para automatizar com um pipeline. Se preferir que um painel faça build, troca de versão e rollback por você, o [Coolify](https://streethosting.com.br/guias/vps/instalar-coolify-vps) resolve o mesmo problema com containers.

## Erros comuns e como resolver

| Sintoma | Causa provável | Como resolver |
| --- | --- | --- |
| Build morre com Killed ou heap out of memory | RAM insuficiente no pico do build | Crie swap, faça o build no CI ou aumente a RAM |
| Site sem CSS e JavaScript no standalone | public e .next/static não foram copiadas | Copie as duas pastas depois de cada build |
| Variável NEXT_PUBLIC_ vazia no navegador | Não estava definida no momento do build | Defina no arquivo de produção e rode o build de novo |
| 502 Bad Gateway | Processo parado ou escutando em outra porta | Confira pm2 status e os logs do processo no PM2 |
| Carregamento chega todo de uma vez | Buffering do Nginx segurando o streaming | Adicione proxy_buffering off no location |
| Failed to find Server Action após deploy | Navegador ainda com a página da versão anterior | Recarregar resolve; configure deploymentId para forçar a troca |
| Site fora depois de reiniciar a VPS | pm2 save ou pm2 startup não foram executados | Rode os dois e teste com um reboot |

A otimização de imagens do componente Image roda na hora da requisição e usa CPU. O resultado fica em cache no disco, então o primeiro acesso a cada imagem é o mais caro. Em páginas com muitas fotos, prefira arquivos já no tamanho certo para não gastar processamento à toa.

## Qual VPS escolher para Next.js

A renderização no servidor acontece no laço de eventos do Node, que usa um núcleo por processo. Na prática, o tempo de resposta de cada página depende muito da velocidade por núcleo. Por isso a [VPS Ryzen 9 9950X](https://streethosting.com.br/vps/ryzen), com até 5,7 GHz e memória DDR5, é a indicação para sites com SSR. O segundo fator é a RAM do build, que define o plano mínimo quando você compila na própria VPS.

| Cenário | Plano sugerido | Preço mensal |
| --- | --- | --- |
| Site pequeno com build feito no CI | Ryzen 1 vCPU, 2 GB DDR5, 20 GB NVMe | R$ 39,00 |
| Build na VPS e SSR com tráfego moderado | Ryzen 2 vCPU, 4 GB DDR5, 40 GB NVMe | R$ 64,00 |
| Vários sites ou site com banco na mesma VPS | Ryzen 4 vCPU, 8 GB DDR5, 80 GB NVMe | R$ 114,00 |
| Loja ou portal com muito acesso e cluster | Ryzen 6 vCPU, 16 GB DDR5, 160 GB NVMe | R$ 214,00 |

O datacenter fica em São Paulo, o que encurta o tempo até o primeiro byte para visitantes no Brasil, e toda VPS tem AntiDDoS incluso, acesso root e ativação em até 60 segundos. Para comparar com a linha Xeon, que entrega mais vCPU por real com clock menor, veja os [planos VPS](https://streethosting.com.br/vps).

- [ ] Node.js 24 LTS instalado pela NodeSource
- [ ] Swap criada se a VPS tem 2 GB
- [ ] Aplicação escutando em 127.0.0.1:3000
- [ ] pm2 save e pm2 startup executados
- [ ] Nginx com cabeçalhos Forwarded e proxy_buffering off
- [ ] Certificado emitido e renovação testada com dry run
- [ ] Deploy em pastas separadas com link simbólico

## Perguntas frequentes

### Next.js funciona completo em uma VPS?

Funciona. Com next start, renderização no servidor, ISR, Server Actions, otimização de imagem e o arquivo de proxy funcionam sem configuração extra. O que muda é que cache, escala e atualização passam a ser responsabilidade sua.

### Qual versão do Node.js usar com Next.js 16?

O Next.js 16 exige no mínimo Node.js 20.9, mas a linha 20 já saiu de suporte. Use a versão LTS ativa, que em setembro de 2026 é o Node.js 24, e mantenha a mesma versão major no computador de desenvolvimento e na VPS.

### Preciso de Nginx se o Next.js já é um servidor?

É o recomendado pela própria documentação. O Nginx termina o HTTPS, lida com conexões lentas, limita tamanho de requisição e protege o processo Node de tráfego malformado, deixando o Next.js livre para renderizar páginas.

### Quanto de RAM o build do Next.js precisa?

Depende do projeto, mas builds de projetos médios costumam passar de 1 GB de pico e podem falhar em VPS de 2 GB sem swap. Com 4 GB o build fica confortável; outra saída é fazer o build no CI e enviar só a pasta standalone.

### Devo usar next start ou output standalone?

next start é mais simples quando o build acontece na própria VPS. O standalone gera uma pasta enxuta com server.js e só as dependências necessárias, ideal para build no CI ou em Docker. Os dois entregam os mesmos recursos em produção.

## Guias relacionados

- [Como hospedar aplicação Node.js em VPS no Brasil](https://streethosting.com.br/guias/vps/hospedar-api-nodejs-vps-brasil.md)
- [PM2 ou systemd: manter sua aplicação Node sempre online na VPS](https://streethosting.com.br/guias/vps/configurar-pm2-startup-systemd-vps.md)
- [Como configurar o Nginx como reverse proxy na VPS](https://streethosting.com.br/guias/vps/configurar-nginx-reverse-proxy-vps.md)
- [Como instalar Coolify na VPS e fazer deploy com HTTPS](https://streethosting.com.br/guias/vps/instalar-coolify-vps.md)
- [Deploy com GitHub Actions na VPS: pipeline passo a passo](https://streethosting.com.br/guias/vps/deploy-github-actions-vps.md)

## Produtos citados

- https://streethosting.com.br/vps/ryzen
- https://streethosting.com.br/vps

## Dados estruturados

```json
[
  {
    "@context": "https://schema.org",
    "@type": [
      "Article",
      "TechArticle"
    ],
    "headline": "Next.js em produção na sua VPS, do build ao HTTPS",
    "name": "Como hospedar Next.js na VPS com PM2, Nginx e HTTPS",
    "abstract": "Next.js roda completo em uma VPS com Node, incluindo renderização no servidor, ISR e Server Actions. Veja como fazer o build, manter o processo vivo com PM2, colocar o Nginx na frente e atualizar sem quebrar o site.",
    "description": "Hospede Next.js na VPS: build com next start ou standalone, PM2 com reinício no boot, Nginx com streaming, domínio, HTTPS e deploy sem derrubar o site.",
    "datePublished": "2026-09-28",
    "dateModified": "2026-09-28",
    "author": {
      "@type": "Organization",
      "name": "Equipe StreetHosting"
    },
    "publisher": {
      "@type": "Organization",
      "name": "StreetHosting",
      "url": "https://streethosting.com.br"
    },
    "inLanguage": "pt-BR",
    "mainEntityOfPage": {
      "@type": "WebPage",
      "@id": "https://streethosting.com.br/guias/vps/hospedar-nextjs-vps"
    }
  },
  {
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
      {
        "@type": "Question",
        "name": "Next.js funciona completo em uma VPS?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Funciona. Com next start, renderização no servidor, ISR, Server Actions, otimização de imagem e o arquivo de proxy funcionam sem configuração extra. O que muda é que cache, escala e atualização passam a ser responsabilidade sua."
        }
      },
      {
        "@type": "Question",
        "name": "Qual versão do Node.js usar com Next.js 16?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "O Next.js 16 exige no mínimo Node.js 20.9, mas a linha 20 já saiu de suporte. Use a versão LTS ativa, que em setembro de 2026 é o Node.js 24, e mantenha a mesma versão major no computador de desenvolvimento e na VPS."
        }
      },
      {
        "@type": "Question",
        "name": "Preciso de Nginx se o Next.js já é um servidor?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "É o recomendado pela própria documentação. O Nginx termina o HTTPS, lida com conexões lentas, limita tamanho de requisição e protege o processo Node de tráfego malformado, deixando o Next.js livre para renderizar páginas."
        }
      },
      {
        "@type": "Question",
        "name": "Quanto de RAM o build do Next.js precisa?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Depende do projeto, mas builds de projetos médios costumam passar de 1 GB de pico e podem falhar em VPS de 2 GB sem swap. Com 4 GB o build fica confortável; outra saída é fazer o build no CI e enviar só a pasta standalone."
        }
      },
      {
        "@type": "Question",
        "name": "Devo usar next start ou output standalone?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "next start é mais simples quando o build acontece na própria VPS. O standalone gera uma pasta enxuta com server.js e só as dependências necessárias, ideal para build no CI ou em Docker. Os dois entregam os mesmos recursos em produção."
        }
      }
    ]
  }
]
```