Deploy de Next.js no Brasil: guia completo do git push à produção

Fazer deploy de Next.js no Brasil sempre foi uma escolha entre dois mundos ruins. De um lado, as PaaS gringas: experiência de deploy impecável, mas servidor fora do país, fatura em dólar e latência intercontinental em cada requisição SSR. Do outro, o VPS nacional: perto do usuário, mas você vira sysadmin — Nginx, PM2, SSL, deploy por SSH, plantão quando cai.

Este guia mostra o terceiro caminho: Next.js em produção no Brasil com um git push. Do repositório ao app no ar no Upuai, passando por variáveis de ambiente, domínio próprio, o que esperar de SSR/ISR em produção e quanto isso custa de verdade — em Real.

É um tutorial que funciona de ponta a ponta. Todos os comandos e limites citados são os reais da plataforma, hoje.

Por que hospedar Next.js no Brasil

Next.js brilha justamente nos modos que dependem do servidor: SSR, Server Components, API routes, ISR. E toda requisição que depende do servidor paga o custo da distância física até ele.

A física não negocia: o round-trip Brasil ↔ Virgínia fica em 140–200 ms — é o limite do cabo de fibra, não da sua internet. Esse tempo entra antes de o seu servidor começar a renderizar qualquer coisa. Num app SSR, é TTFB puro, somado a cada navegação, cada fetch de Server Component, cada chamada de API route. Detalhamos a mecânica (e por que isso define a percepção de “app rápido”) em Latência sub-20ms: o KPI silencioso.

CDN e edge ajudam no estático, mas não resolvem o dinâmico: se o servidor de origem está em us-east-1, o HTML renderizado por requisição continua cruzando o hemisfério. Servir do Brasil corta essa conta na origem — a resposta dinâmica nasce perto de quem usa.

Há ainda dois efeitos colaterais bem-vindos: fatura em Real (sem dólar, IOF nem spread de câmbio — fizemos essa matemática em Cloud no Brasil custa 78% a mais) e dados no país, o que simplifica conversa de LGPD com cliente e jurídico.

Pré-requisitos

Você precisa de três coisas:

Um app Next.js num repositório GitHub ou GitLab — App Router ou Pages Router, tanto faz. O create-next-app padrão, com os scripts build e start no package.json, já está pronto pra deploy.
Node declarado no projeto (boa prática): fixe a versão em engines no package.json ou num .nvmrc pra garantir build reproduzível.
Uma conta no Upuai — os 15 dias de teste não pedem cartão. Crie em app.upuai.com.br (login por GitHub OAuth ou código por e-mail).

Não precisa de Dockerfile, YAML de Kubernetes nem config de CI. O build usa o railpack, builder zero-config que detecta o Next.js pelo next.config.js/.mjs/.ts, roda o next build e sobe o servidor Node do framework.

Passo a passo: do repositório ao ar no Upuai

Existem dois caminhos que terminam no mesmo lugar. Nos dois, o estado final é: todo git push na branch conectada dispara build e deploy automáticos, com rollout sem downtime e rollback disponível.

Caminho 1 — pelo dashboard (recomendado pra primeira vez)

Entre em app.upuai.com.br e clique em novo projeto.
Na primeira vez, autorize o GitHub App do Upuai (a tela em app.upuai.com.br/projects/new guia a instalação) e escolha o repositório.
A plataforma detecta o Next.js automaticamente e builda com o railpack — sem config.
Ao final, seu app está no ar numa URL própria https://seu-app.upuai.com.br, com SSL.
Pronto: daqui em diante, git push na branch conectada = deploy. Merge na main, app atualizado.

Caminho 2 — pela CLI

# macOS / Linux
brew tap saiph-ti/upuai-cli
brew install upuai

# Windows (PowerShell)
scoop bucket add upuai https://github.com/saiph-ti/scoop-upuai-cli
scoop install upuai

Autentique uma única vez por máquina e crie o projeto já conectado ao repo:

upuai login          # GitHub OAuth no browser (ou: upuai login --email)

upuai init \
  --name meu-app \
  --repo sua-org/seu-repo \
  --branch main \
  --framework "Next.js" \
  --yes

upuai deploy --wait --yes

O --wait bloqueia até o deploy chegar num status final e retorna a URL pública. Pra acompanhar o build em tempo real: upuai logs --build (build) e upuai logs --deploy (release + rollout). Sem repo git conectado — ou pra testar código local não commitado — existe o upuai up, que empacota o diretório atual e deploya direto (ignorando .git, node_modules e .env* automaticamente).

Um detalhe que em outras plataformas vira meia hora de debug: o Upuai injeta a variável PORT no container, e o next start respeita PORT nativamente. Não há nada pra configurar de porta.

E se você trabalha com agente de IA (Claude Code, Cursor), a plataforma tem uma skill oficial de deploy — o agente executa esse fluxo inteiro por você, via CLI.

Variáveis de ambiente e domínio próprio

Variáveis de ambiente

Pelo dashboard ou pela CLI:

upuai vars set DATABASE_URL=postgres://... --yes
upuai vars set NEXT_PUBLIC_API_URL=https://api.meuapp.com.br CHAVE2=valor --yes

Três coisas que importam num app Next.js:

NEXT_PUBLIC_* funciona sem gambiarra. Essas variáveis são embutidas no bundle em build time — e no Upuai, por padrão, toda variável vale pra build e runtime. Setou, deployou, está no bundle.
Segredos podem ficar só no runtime: upuai variables set STRIPE_SECRET=xxx --scope runtime mantém a chave fora da imagem de build.
Variáveis valem a partir do próximo deploy. Mudou algo e quer aplicar já? upuai redeploy --yes.

E o básico que ainda derruba gente experiente: .env não vai pro repositório. No Upuai ele também nunca sobe por engano — o empacotamento exclui .env* sempre.

Domínio próprio

upuai domains add app.seudominio.com.br --yes

O comando retorna os registros DNS (CNAME/TXT) pra apontar no seu provedor. A validação roda automaticamente a cada 60 segundos, e o certificado TLS via Let’s Encrypt é emitido e renovado sozinho. Enquanto o DNS propaga, a URL seu-app.upuai.com.br segue respondendo. Até o período de teste inclui 1 domínio próprio.

SSR, ISR e API routes: o que esperar em produção

Aqui está a diferença estrutural que mais afeta um app Next.js: no Upuai, seu app roda como um servidor Node completo, num container de longa duração — não fatiado em funções serverless. É o modelo de self-hosting oficial do Next (next start), com implicações práticas boas de conhecer:

SSR e Server Components: funcionam sem adaptador e sem cold start — o processo está sempre de pé. O ganho de latência do datacenter local aparece direto no TTFB.
API routes e route handlers: são endpoints do mesmo servidor. Sem limite de duração agressivo de função serverless, sem empacotamento separado por rota.
ISR: funciona como no self-hosting padrão do Next — revalidate e revalidação on-demand operando com cache em disco da instância. A nuance honesta: se você escalar pra múltiplas réplicas (upuai scale 3 --yes), cada réplica mantém seu próprio cache ISR; é o comportamento documentado do Next self-hosted, e o framework suporta um cache handler customizado (Redis, por exemplo) se você precisar de cache compartilhado.
Middleware e next/image: rodam no próprio servidor Node. A otimização de imagem acontece na sua instância, sem serviço externo.

Precisa fugir do padrão (monorepo, comando de build próprio, health check)? Declare num upuai.toml versionado no repo:

#:schema https://upuai.com.br/schemas/upuai-toml-v1.json

[build]
buildCommand = "pnpm build"

[deploy]
healthCheckPath = "/api/health"

Pra monorepos, o --root-dir apps/web no init (ou upuai config set --root-dir apps/web) aponta o build pro subdiretório certo. E se um deploy quebrar em produção: upuai rollback --list mostra o histórico e upuai rollback --to <id> --yes reverte.

Custos: do teste grátis ao app em produção

Preços em Real, sem cartão internacional, sem IOF e sem surpresa de câmbio na fatura.

Plano	Preço/mês	Projetos	Serviços/projeto	Storage	Domínios próprios	Logs
Teste (15 dias)	grátis, sem cartão	1	2	4 GB	1	12h
Starter	R$ 19	2	3	10 GB	5	24h
Plus	R$ 49	3	4	25 GB	8	48h
Pro	R$ 99	5	5	50 GB	10	72h

No anual, todos os planos pagos saem por 10× o valor mensal — 2 meses grátis.

Na prática, pra um app Next.js:

Teste (15 dias): cobre um MVP de verdade — o app Next.js + um Postgres gerenciado são 2 serviços, exatamente o limite. Repo de até 100 MB, e o build roda num runner dedicado de 4 vCPUs / 4 GB (build de Next.js médio passa confortável). Pra manter no ar depois dos 15 dias, o degrau é o Starter.
Starter (R$ 19): espaço pra separar um worker ou segundo serviço, mais storage e domínios.
Pro (R$ 99): 2 ambientes (staging + produção com upuai promote), 16 vCPUs / 16 GB pro workspace inteiro (um único serviço pode usar tudo) e folga pra portfólio inteiro de apps.

Se o app serve upload de arquivos, vale conhecer o object storage S3-compatível da plataforma — sem cobrança de egress, que é onde a fatura de storage costuma explodir (explicamos o mecanismo aqui).

Quando outra opção faz sentido

Comparativo honesto, porque nenhuma plataforma ganha em todos os cenários:

Vercel — se seu público é global e você depende pesado de edge network e preview deployment por PR, a criadora do Next.js é uma escolha coerente. O preço: plano em dólar + IOF, e o backend dinâmico tipicamente longe do usuário brasileiro.
Railway / Render / Fly — mesma família de DX moderna. Alguns têm presença parcial na região, mas a fatura segue em dólar e o stack completo (app + banco + storage) raramente fica todo no Brasil.
VPS + Coolify/self-host — custo de infra mínimo e controle total, se você aceita operar: atualização, segurança, SSL, deploy e plantão são seus.

Fizemos a análise longa, com preços e cenários, em Vercel, Railway, Heroku ou Upuai: qual PaaS escolher em 2026. O resumo: se seu usuário está no Brasil e você quer fatura em Real com dados no país, servir daqui é a vantagem estrutural — o resto é detalhe de plano.

FAQ

Preciso de Dockerfile pra fazer deploy de Next.js no Upuai?

Não. O builder padrão (railpack) detecta e builda o Next.js sem nenhum arquivo de configuração. Dockerfile é opt-in: só é usado se você escolher explicitamente o builder dockerfile — ter um Dockerfile no repo não muda nada sozinho.

App Router, Server Components e Server Actions funcionam?

Sim. O app roda como servidor Node completo — o mesmo modelo do next start que a documentação do Next descreve pra self-hosting. SSR, RSC, Server Actions, API routes e middleware funcionam sem adaptação.

Como uso Postgres com o Next.js?

upuai add --type database --engine postgres provisiona um Postgres gerenciado no mesmo projeto e injeta a DATABASE_URL automaticamente no seu app. Migrations entram no upuai.toml como releaseCommand (ex.: npx prisma migrate deploy) — rodam antes de cada rollout, e se falharem o deploy não recebe tráfego.

O período de teste aguenta um app em produção?

Pra testar com tráfego real, sim — com os limites da tabela acima (1 projeto, 2 serviços, 4 GB, logs de 12h), por 15 dias. Produção de verdade pede um plano pago ao fim do teste: o degrau pro Starter é R$ 19, pro Plus, R$ 49, e pro Pro, R$ 99 — sem migração, só upgrade de plano.

O deploy quebrou. E agora?

upuai logs --build mostra o log do build, upuai logs --deploy mostra release e rollout, upuai logs -f acompanha o runtime ao vivo. Enquanto isso, a versão anterior continua servindo — o rollout só troca o tráfego se o deploy novo ficar saudável. Pra reverter uma mudança ruim: upuai rollback --to <id> --yes.

Do push à produção

O caminho inteiro, revisitado: conta sem cartão → conectar o repositório → build automático → app no ar num domínio com SSL → e daí em diante, cada git push é um deploy. Sem Dockerfile, sem YAML, sem plantão de servidor — com o app respondendo de um datacenter no Brasil e a fatura em Real.

Comece seus 15 dias grátis — sem cartão →

Prefere começar pelo terminal? A documentação da CLI tem a referência completa de comandos.