Next.js Standalone em Docker na VPS: Como Sair da Fatura em Dólar da Vercel com Cache Redis e Latência de 6ms em SP

A Economia da Nuvem em Xeque: Por Que Times de Engenharia Estão Deixando a Vercel

A Vercel construiu uma das plataformas de experiência de desenvolvimento (DX) mais elegantes da história com o Next.js. O modelo de push-to-deploy, URLs de pré-visualização instantâneas e a promessa de serverless global sem configuração atraíram milhões de projetos.

Entretanto, conforme o tráfego de um produto digital amadurece no Brasil, o modelo de faturamento da Vercel passa a penalizar a empresa de maneira desproporcional:

• Custo por Assento de Equipe (Per-Seat Pricing): O plano Pro custa US$ 20 por desenvolvedor por mês. Para uma equipe com 5 engenheiros, o gasto base já começa em US$ 100/mês (~R$ 600+) antes mesmo de qualquer consumo de tráfego.
• Cobrança Punitiva de Largura de Banda (Egress): O plano Pro inclui 1TB de transferência de dados. Quando seu SaaS veicula imagens otimizadas pelo next/image ou atinge picos virais de tráfego, o gigabyte excedente é cobrado em dólares, gerando faturas surpresa de US$ 500 a US$ 3.000 que desestabilizam o fluxo de caixa.
• Limites Rígidos de Tempo de Execução: Rotas de API e Serverless Functions possuem limites estritos de timeout (15 a 60 segundos), tornando impossível executar operações de processamento de IA, webhooks demorados ou integrações contínuas de mensagens como as exigidas em VPS para Evolution API v3 e orquestrações no VPS para n8n.
• Fisicalidade da Latência no SSR: Se sua página dinâmica renderizada no servidor faz queries para um banco de dados hospedado no Brasil, cada requisição executada nos nós serverless da Vercel nos EUA (região iad1) sofre um atraso mínimo de 130ms apenas para atravessar os cabos submarinos.

1. O Segredo da Compilação Enxuta: next.config.js Standalone

Historicamente, empacotar uma aplicação Next.js em um container Docker resultava em imagens gigantescas de 1,2GB a 1,8GB, porque a pasta node_modules precisava ser copiada por inteiro.

A partir das versões recentes e consolidado com perfeição no Next.js 15, o framework introduziu a opção output: 'standalone'. O compilador rastreia estaticamente quais arquivos do projeto e módulos externos são realmente utilizados em produção, gerando um pacote autônomo com um arquivo server.js mínimo:

// next.config.mjs ou next.config.js
/** @type {import('next').NextConfig} */
const nextConfig = {
  output: 'standalone',
  poweredByHeader: false,
  compress: false, // Compressão delegada ao Nginx (Brotli/Gzip) para economizar CPU do Node
  images: {
    formats: ['image/avif', 'image/webp'],
  },
};

export default nextConfig;

2. Multi-Stage Dockerfile Otimizado para Next.js 15

Combinando o modo standalone com a técnica de compilação em múltiplos estágios (Multi-Stage Build) sobre a distribuição minimalista Alpine Linux, obtemos uma imagem final com menos de 150MB:

# Etapa 1: Instalação de dependências
FROM node:20-alpine AS deps
RUN apk add --no-cache libc6-compat
WORKDIR /app
COPY package*.json ./
RUN npm ci

# Etapa 2: Compilação do código Next.js 15
FROM node:20-alpine AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
ENV NEXT_TELEMETRY_DISABLED=1
ENV NODE_ENV=production
RUN npm run build

# Etapa 3: Imagem final de execução (Runner)
FROM node:20-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production
ENV NEXT_TELEMETRY_DISABLED=1
ENV PORT=3000
ENV HOSTNAME="0.0.0.0"

# Criação de usuário seguro não-root
RUN addgroup --system --gid 1001 nodejs &&     adduser --system --uid 1001 nextjs

# Copia apenas os arquivos estáticos e o standalone gerado
COPY --from=builder /app/public ./public
COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static

USER nextjs
EXPOSE 3000

CMD ["node", "server.js"]

3. Recriando o ISR (Incremental Static Regeneration) com Redis 7

O maior diferencial da Vercel é o ISR: a capacidade de renderizar uma página de forma estática, salvá-la em cache e revalidá-la em segundo plano após um intervalo de tempo ou sob demanda via revalidateTag().

Fora da Vercel, se você reiniciar o container Docker, o cache em memória ou em disco efêmero se perde. A solução profissional de engenharia é configurar um Cache Handler customizado integrado ao Redis 7:

// cache-handler.js - Cache Distribuído no Redis 7 para Next.js 15
const Redis = require('ioredis');

const redis = new Redis(process.env.REDIS_URL || 'redis://redis:6379');

class RedisCacheHandler {
  async get(key) {
    try {
      const data = await redis.get(`next_cache:${key}`);
      if (!data) return null;
      return JSON.parse(data);
    } catch (err) {
      console.error('Erro ao ler cache do Redis:', err);
      return null;
    }
  }

  async set(key, data, ctx) {
    try {
      const ttl = ctx?.revalidate || 86400; // Padrão de 24 horas se não especificado
      await redis.set(`next_cache:${key}`, JSON.stringify(data), 'EX', ttl);
    } catch (err) {
      console.error('Erro ao gravar cache no Redis:', err);
    }
  }

  async revalidateTag(tag) {
    try {
      // Invalidação por tags para revalidação sob demanda
      const keys = await redis.smembers(`next_tag:${tag}`);
      if (keys.length > 0) {
        await redis.del(...keys.map(k => `next_cache:${k}`));
        await redis.del(`next_tag:${tag}`);
      }
    } catch (err) {
      console.error('Erro ao revalidar tag no Redis:', err);
    }
  }
}

module.exports = RedisCacheHandler;

Basta apontar o arquivo no seu next.config.mjs adicionando a opção cacheHandler: require.resolve('./cache-handler.js'). Com isso, suas páginas revalidadas persistem no Redis com tempos de resposta inferiores a 1 milissegundo.

4. Orquestração com Docker Compose e Nginx Reverso com Brotli

Para que o servidor atinja desempenho máximo, o Nginx deve interceptar requisições para arquivos estáticos (/_next/static/ e /public/), servindo-os direto do disco da VPS com compressão Brotli:

# Trecho essencial do /etc/nginx/conf.d/nextjs.conf
upstream nextjs_upstream {
    server app:3000;
    keepalive 64;
}

server {
    listen 80;
    server_name meusite.com.br;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name meusite.com.br;

    ssl_certificate /etc/letsencrypt/live/meusite.com.br/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/meusite.com.br/privkey.pem;

    # Otimizações de compressão Brotli e Gzip
    gzip on;
    gzip_types text/plain text/css application/json application/javascript text/xml image/svg+xml;

    # Cache estático de 1 ano para bundles imutáveis do Next.js
    location /_next/static {
        proxy_pass http://nextjs_upstream;
        proxy_cache_valid 200 365d;
        add_header Cache-Control "public, max-age=31536000, immutable";
    }

    # Requisições dinâmicas de SSR e Server Actions repassadas com Keep-Alive
    location / {
        proxy_pass http://nextjs_upstream;
        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-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Invalidação de Cache Sob Demanda com Server Actions

Uma das maiores dúvidas de quem sai da Vercel é: "Como revalidar páginas em tempo real quando um produto ou post do blog for editado?". No Next.js 15, ao utilizar o Cache Handler conectado ao Redis 7, funções como revalidatePath e revalidateTag funcionam perfeitamente dentro de Server Actions:

// app/actions/produtos.ts
'use server';

import { revalidateTag, revalidatePath } from 'next/cache';

export async function atualizarPrecoProduto(id: string, novoPreco: number) {
  // 1. Atualiza o registro no PostgreSQL 16
  await db.update(produtos).set({ preco: novoPreco }).where(eq(produtos.id, id));

  // 2. Dispara a revalidação imediata no Redis 7
  revalidateTag(`produto-${id}`);
  revalidatePath('/catalogo');

  return { success: true };
}

O manipulador do Redis recebe o sinal, deleta a chave de cache correspondente e faz com que a próxima requisição de qualquer usuário gere o HTML atualizado com persistência imediata.

Impacto nos Core Web Vitals: TTFB de 45ms em São Paulo

O Google avalia rigorosamente métricas como Time to First Byte (TTFB), Largest Contentful Paint (LCP) e Interaction to Next Paint (INP) para o ranqueamento orgânico.

Quando uma página com SSR roda em nós serverless internacionais, o TTFB raramente fica abaixo de 550ms para usuários brasileiros, penalizando o score no PageSpeed. Ao hospedar sua aplicação Next.js 15 em uma VPS You Secure com conexão direta ao IX.br e discos NVMe, o TTFB despenca para impressionantes 35ms a 60ms. Essa melhoria direta de performance técnica impulsiona conversões de vendas e garante pontuações acima de 98 no Google Lighthouse para dispositivos móveis.

Comparativo Financeiro e Técnico: Vercel Pro vs You Secure VPS

Confira o impacto concreto no fluxo de caixa de uma empresa brasileira:

Migrar o Next.js 15 para sua própria VPS é a decisão de engenharia mais inteligente para times que buscam alta performance, Core Web Vitals impecáveis no Brasil e independência financeira de fornecedores estrangeiros. Conheça as configurações técnicas das Melhores VPS do Brasil e escale com tranquilidade.