Vercel: do primeiro deploy à arquitetura em produção

Como usar esta apostila

Cada módulo segue a mesma estrutura: objetivo, conteúdo com exemplos reais, uma caixa "No mercado" explicando como aquilo aparece em vagas e entrevistas, e um exercício prático. No final há um banco de perguntas de entrevista com respostas.

• Iniciante: siga na ordem, do módulo 1 ao 9, fazendo todos os exercícios. Isso já cobre o que a maioria das vagas júnior/pleno de front-end espera.
• Já usa Vercel: vá direto aos módulos 10–18. É onde ficam os diferenciais para pleno/sênior.
• Preparando entrevista: leia as caixas "No mercado" de todos os módulos e o módulo 20 inteiro.

O que é a Vercel

Objetivo: entender o que a plataforma faz, de onde veio e por que ela aparece em tantas vagas.

A Vercel é uma plataforma de nuvem focada em aplicações web. Ela cuida de tudo que acontece depois que você escreve o código: build, deploy, CDN global, funções serverless, cache, domínios, HTTPS, observabilidade e segurança. A empresa foi fundada por Guillermo Rauch em 2015 (como ZEIT, renomeada Vercel em 2020) e é a criadora do Next.js, o framework React mais usado do mercado.

O problema que ela resolve

Sem uma plataforma assim, colocar um app profissional no ar exige montar e manter: servidor ou cluster, pipeline de CI/CD, CDN, certificados SSL, escalabilidade automática, ambientes de homologação e rollback. A Vercel entrega isso com um git push. O conceito central é a Framework-defined Infrastructure: a plataforma lê o seu código (Next.js, Nuxt, SvelteKit, Astro, Remix, Vite etc.) e provisiona sozinha a infraestrutura ideal — páginas estáticas viram arquivos na CDN, rotas dinâmicas viram funções serverless, middleware roda na borda.

Os três pilares

• Workflow de deploy: cada push gera um deploy; cada Pull Request ganha uma URL de preview; a branch principal vira produção.
• Rede global (Edge Network): CDN com pontos de presença no mundo todo (incluindo Brasil — região gru1, São Paulo), servindo conteúdo perto do usuário.
• Compute serverless: Vercel Functions com o modelo Fluid Compute (você paga por CPU ativa, não por tempo parado — módulo 16).

Planos

Primeiro deploy e o fluxo Git

Objetivo: colocar um projeto no ar e entender previews, produção e rollback — o coração do workflow.

Deploy pelo Git (o jeito profissional)

1. Suba seu projeto para um repositório (GitHub, GitLab ou Bitbucket).
2. No dashboard, clique em Add New → Project e importe o repositório.
3. A Vercel detecta o framework e preenche build command e output automaticamente. Confirme e clique em Deploy.
4. Em ~1 minuto você recebe uma URL seu-projeto.vercel.app com HTTPS.

Os três tipos de deployment

Preview Deployments são o superpoder do fluxo: cada Pull Request ganha um ambiente idêntico ao de produção, com link postado automaticamente no PR. Designer, QA e PM testam antes do merge. Com Comments ativado, stakeholders comentam direto na tela do preview.

Rollback instantâneo

Todo deploy fica imutável no histórico. Se produção quebrar: Project → Deployments → escolha um deploy anterior → Instant Rollback. A troca é de segundos, porque nada é rebuildado — a Vercel só reaponta o domínio para o deploy antigo.

Vercel CLI

Objetivo: dominar a linha de comando — indispensável para debug, scripts e CI/CD.

npm i -g vercel      # instalar
vercel login         # autenticar
vercel link          # conectar a pasta local a um projeto Vercel

Comandos essenciais

Domínios, DNS e HTTPS

Objetivo: sair do .vercel.app e configurar um domínio próprio como um profissional.

Conectando um domínio

Em Project → Settings → Domains, adicione o domínio. A Vercel mostra exatamente os registros a criar no seu provedor (Registro.br, Cloudflare, GoDaddy…):

• Domínio raiz (meusite.com.br): registro A apontando para 76.76.21.21.
• Subdomínio (www, app, blog): registro CNAME para cname.vercel-dns.com.
• Alternativa: delegar os nameservers para a Vercel e gerenciar todo o DNS por lá (necessário para wildcard *.meusite.com).

O certificado SSL é automático e renovado sozinho (Let's Encrypt). Você nunca gerencia certificado na mão.

Boas práticas

• Defina um domínio canônico: configure www → apex (ou o contrário) como redirect 308 na própria tela de Domains.
• Aponte domínios diferentes para branches diferentes (ex.: staging.meusite.com → branch staging).
• Propagação de DNS pode levar de minutos a horas — verifique com dig ou whatsmydns.net antes de achar que algo quebrou.

Variáveis de ambiente e segredos

Objetivo: gerenciar chaves de API e configurações por ambiente sem nunca vazar um segredo.

Os três ambientes

Cada variável em Settings → Environment Variables pode valer para Production, Preview e/ou Development — e, dentro de Preview, até para uma branch específica. Isso permite, por exemplo, apontar previews para um banco de testes e produção para o banco real.

# fluxo típico no dia a dia
vercel env add DATABASE_URL production   # cria via CLI
vercel env pull .env.local               # sincroniza para rodar local
# .env.local está no .gitignore — nunca comite segredos!

Regras de ouro

• Servidor vs. navegador: no Next.js, só variáveis com prefixo NEXT_PUBLIC_ chegam ao browser. Todo o resto fica no servidor. Jamais coloque uma chave secreta com esse prefixo.
• Sensitive: marque segredos como "Sensitive" — nem o dashboard mostra o valor depois de salvo.
• Variáveis são injetadas no build e no runtime; ao alterar uma variável usada no build, faça redeploy para ela valer.
• Rotacione chaves vazadas imediatamente e use tokens com escopo mínimo.

vercel.json a fundo

Objetivo: controlar roteamento, headers, crons e comportamento das funções por configuração declarativa.

O arquivo vercel.json na raiz do projeto configura a plataforma. Os campos mais usados no trabalho real:

{
  "redirects": [
    { "source": "/blog-antigo/:slug", "destination": "/blog/:slug", "permanent": true }
  ],
  "rewrites": [
    { "source": "/api/proxy/:path*", "destination": "https://api.externa.com/:path*" }
  ],
  "headers": [
    {
      "source": "/(.*)",
      "headers": [
        { "key": "X-Content-Type-Options", "value": "nosniff" },
        { "key": "X-Frame-Options", "value": "DENY" },
        { "key": "Strict-Transport-Security", "value": "max-age=63072000; includeSubDomains; preload" }
      ]
    }
  ],
  "crons": [
    { "path": "/api/relatorio-diario", "schedule": "0 9 * * *" }
  ],
  "functions": {
    "api/pesada.ts": { "maxDuration": 300, "memory": 1769 }
  },
  "regions": ["gru1"]
}

Conceitos-chave

• Redirect vs. Rewrite: redirect muda a URL no navegador (301/302/307/308) — use para SEO e migrações. Rewrite serve outro conteúdo mantendo a URL — use para proxy de APIs, multi-tenant e A/B tests.
• permanent: true gera 308 (preserva método HTTP) e é cacheado agressivamente pelos navegadores — cuidado ao usar antes de ter certeza.
• Cron Jobs: a Vercel chama a rota no horário (sintaxe cron, UTC). Proteja a rota validando o header Authorization com CRON_SECRET.
• regions define onde as funções executam. gru1 (São Paulo) reduz latência para usuários e bancos de dados no Brasil.
• Em Next.js, prefira next.config.js para redirects/headers quando possível; vercel.json é a opção agnóstica de framework.

Next.js na Vercel: renderização e infraestrutura

Objetivo: entender como cada estratégia de renderização vira infraestrutura — o assunto favorito das entrevistas.

A Vercel transforma seu código Next.js em infraestrutura automaticamente. Saber o que vira o quê é o conhecimento mais cobrado em entrevistas de front-end moderno:

Recursos que só funcionam "de graça" na Vercel

• Image Optimization: next/image redimensiona, converte para WebP/AVIF e cacheia na borda — impacto direto em Core Web Vitals.
• Font Optimization: next/font hospeda a fonte junto do site, eliminando request externo e layout shift.
• Server Actions e Route Handlers viram funções sem nenhuma configuração.
• Skew Protection: durante um deploy, usuários com a versão antiga do front continuam falando com o backend da mesma versão — elimina erros de "deploy no meio da sessão".

Vercel Functions

Objetivo: escrever, configurar e depurar o backend serverless que atende suas rotas dinâmicas e APIs.

Como criar

Em Next.js (App Router), qualquer route.ts é uma função. Em projetos sem framework, arquivos na pasta api/ viram endpoints:

export async function GET(request: Request) {
  const { searchParams } = new URL(request.url);
  const nome = searchParams.get("nome") ?? "mundo";
  return Response.json({ mensagem: `Olá, ${nome}!` });
}

export async function POST(request: Request) {
  const body = await request.json();
  // validar, gravar no banco, chamar API externa...
  return Response.json({ ok: true }, { status: 201 });
}

O que você precisa saber

• Runtimes: Node.js é o padrão; a plataforma também roda Python, Go e Ruby — e desde 2026 suporta frameworks de backend completos como FastAPI, Flask, Express e Hono (módulo 18).
• Limites práticos: duração configurável por função (maxDuration) — com Fluid Compute, funções podem rodar por até 30 minutos, o que viabiliza workloads de IA e processamento longo.
• Streaming: retorne ReadableStream para respostas progressivas (essencial para chat com LLMs).
• waitUntil(): execute trabalho depois de responder (analytics, e-mail, log) sem segurar o usuário:

import { waitUntil } from "@vercel/functions";

export async function POST(req: Request) {
  const pedido = await criarPedido(await req.json());
  waitUntil(enviarEmailDeConfirmacao(pedido)); // roda após a resposta
  return Response.json(pedido, { status: 201 });
}

Edge Network, Middleware e geolocalização

Objetivo: interceptar requisições na borda da rede para auth, redirecionamentos, A/B tests e personalização por região.

A Edge Network é a camada global da Vercel: recebe toda requisição no ponto de presença mais próximo do usuário, serve cache e aplica firewall antes de qualquer código seu rodar. O Middleware é o código que você executa nessa camada, antes da rota:

import { NextResponse } from "next/server";
import type { NextRequest } from "next/server";

export function middleware(request: NextRequest) {
  // 1. Proteção de rota
  const sessao = request.cookies.get("sessao");
  if (!sessao && request.nextUrl.pathname.startsWith("/app")) {
    return NextResponse.redirect(new URL("/login", request.url));
  }

  // 2. Personalização por país (header injetado pela Vercel)
  const pais = request.headers.get("x-vercel-ip-country") ?? "BR";
  const resposta = NextResponse.next();
  resposta.headers.set("x-pais", pais);

  // 3. A/B test simples via cookie + rewrite
  const grupo = request.cookies.get("ab")?.value ?? (Math.random() < 0.5 ? "a" : "b");
  if (request.nextUrl.pathname === "/promo") {
    const r = NextResponse.rewrite(new URL(`/promo/${grupo}`, request.url));
    r.cookies.set("ab", grupo);
    return r;
  }
  return resposta;
}

export const config = { matcher: ["/app/:path*", "/promo"] };

Pontos importantes

• Use o matcher para limitar onde o middleware roda — rodar em tudo (inclusive assets) custa e atrasa.
• Middleware deve ser leve e rápido: checar cookie, reescrever, redirecionar. Consulta pesada a banco aqui é anti-padrão — para dados na borda, use Edge Config (módulo 11).
• Geolocalização vem de graça nos headers: x-vercel-ip-country, ip-country-region, ip-city — ótima para moeda, idioma e compliance regional.
• Casos de uso matadores: gate de autenticação, paywall, redirect por idioma, feature flags, bloqueio de bots, multi-tenant por subdomínio.

Caching avançado e ISR na prática

Objetivo: dominar as camadas de cache — a habilidade que mais separa sênior de pleno em performance e custo.

As camadas de cache na Vercel

1. Cache do navegador — controlado por Cache-Control: max-age.
2. CDN / Edge Cache — controlado por s-maxage e stale-while-revalidate; compartilhado entre todos os usuários da região.
3. ISR / Data Cache do framework — cache de páginas e de fetch gerenciado pelo Next.js, com revalidação por tempo ou sob demanda.

export async function GET() {
  const dados = await buscarCotacoes();
  return Response.json(dados, {
    headers: {
      // navegador não guarda; CDN guarda 60s e serve versão
      // "velha" por até 5min enquanto revalida em background
      "Cache-Control": "public, max-age=0, s-maxage=60, stale-while-revalidate=300"
    }
  });
}

// pagina: cacheia o fetch e etiqueta
const posts = await fetch("https://cms.com/posts", {
  next: { tags: ["posts"], revalidate: 3600 }
}).then(r => r.json());

// app/api/revalidar/route.ts — chamado pelo webhook do CMS
import { revalidateTag } from "next/cache";
export async function POST(req: Request) {
  if (req.headers.get("x-secret") !== process.env.REVALIDATE_SECRET)
    return new Response("nope", { status: 401 });
  revalidateTag("posts");
  return Response.json({ revalidado: true });
}

Depurando cache como gente grande

• Inspecione o header de resposta x-vercel-cache: HIT (veio da CDN), MISS (executou a função), STALE (serviu velho e revalidou atrás), PRERENDER (estático), BYPASS (sem cache).
• Todo deploy novo invalida o cache da CDN automaticamente — você nunca serve versão antiga do site após deploy.
• stale-while-revalidate é o padrão-ouro para dados que podem atrasar alguns segundos: latência de cache com frescor quase em tempo real.
• Cache é também ferramenta de custo: cada HIT é uma invocação de função que você não pagou.

Storage: Edge Config, Blob e Marketplace

Objetivo: escolher e usar a camada de dados certa para cada problema.

Desde 2024/2025 a Vercel migrou seus bancos próprios para o Marketplace: você provisiona Neon, Upstash e até serviços AWS direto do dashboard, com billing unificado e variáveis de ambiente injetadas automaticamente no projeto.

import { get } from "@vercel/edge-config";

export async function middleware(request: NextRequest) {
  const manutencao = await get("modo_manutencao"); // ~1ms na borda
  if (manutencao && !request.nextUrl.pathname.startsWith("/manutencao")) {
    return NextResponse.rewrite(new URL("/manutencao", request.url));
  }
  return NextResponse.next();
}

import { put } from "@vercel/blob";

export async function POST(request: Request) {
  const form = await request.formData();
  const arquivo = form.get("arquivo") as File;
  const blob = await put(`uploads/${arquivo.name}`, arquivo, {
    access: "public",
    addRandomSuffix: true
  });
  return Response.json({ url: blob.url });
}

Observabilidade: analytics, vitals e logs

Objetivo: medir antes de otimizar — e provar impacto com números, como um sênior.

As ferramentas

• Web Analytics: pageviews, visitantes, referrers e custom events, sem cookies e amigável à LGPD. Instala com @vercel/analytics e um componente.
• Speed Insights: Core Web Vitals reais (LCP, CLS, INP) coletados dos seus usuários, por página e por dispositivo — o dado que o Google usa para ranquear.
• Logs de runtime: todo console.log/error das funções, filtrável por rota, status e deployment no dashboard.
• Log Drains: exportação contínua dos logs para Datadog, Axiom, Grafana, New Relic — obrigatório em empresa com stack de observabilidade centralizada.
• OpenTelemetry: traces distribuídos das funções para acompanhar uma requisição atravessando serviços.
• Monitoring e alertas (planos pagos): queries sobre tráfego/erros e notificação de anomalias.

import { Analytics } from "@vercel/analytics/react";
import { SpeedInsights } from "@vercel/speed-insights/next";

export default function RootLayout({ children }) {
  return (
    <html lang="pt-BR">
      <body>
        {children}
        <Analytics />
        <SpeedInsights />
      </body>
    </html>
  );
}

Fluxo de investigação de um erro em produção

1. Alerta ou reclamação → abrir Logs filtrando por status >= 500.
2. Identificar a rota e o deployment → conferir se começou após um deploy específico.
3. Se sim: Instant Rollback primeiro, investigação depois.
4. Reproduzir no preview, corrigir, e acompanhar a taxa de erro cair.

Segurança na plataforma

Objetivo: proteger app, deploys e credenciais — requisitos cada vez mais explícitos em vagas.

Camadas de proteção

• Mitigação de DDoS automática na Edge Network, para todos os planos, sem configuração.
• Vercel Firewall (WAF): regras customizadas por caminho, país, IP, user-agent, ASN — com ações de bloquear, desafiar ou logar; inclui managed rules para ataques conhecidos (SQLi, XSS).
• Rate limiting declarativo no Firewall para proteger rotas caras (login, busca, APIs de IA).
• Bot management / BotID: distingue bots legítimos (Googlebot), agentes de IA e tráfego malicioso — decisivo na era dos crawlers de LLM.
• Deployment Protection: previews protegidos por login Vercel, senha ou IPs confiáveis — evita vazar features não lançadas (recurso que já derrubou surpresa de lançamento de muita empresa).
• RBAC e times: papéis (owner, member, developer, viewer, billing) controlando quem faz deploy, quem vê env vars e quem administra domínio.

Segredos sem segredos: OIDC Federation

Em vez de guardar AWS_ACCESS_KEY_ID como variável de ambiente, a função Vercel apresenta um token OIDC de curta duração ao provedor (AWS/GCP/Azure), que o troca por credenciais temporárias. Nada de chave de longa duração para vazar — é a resposta "nível staff" para gestão de credenciais.

Checklist de segurança de projeto

1. Headers de segurança (HSTS, nosniff, frame-options — módulo 6).
2. Segredos como Sensitive; zero segredos no client (NEXT_PUBLIC_ auditado).
3. Rate limit em rotas de autenticação e de custo alto.
4. Deployment Protection ligado em previews de produto fechado.
5. Rotas de cron e revalidação validando secret no header.
6. Papéis de time no privilégio mínimo; 2FA obrigatório.

CI/CD profissional

Objetivo: montar pipelines com testes bloqueantes, deploys controlados e releases graduais.

O fluxo nativo (suficiente para muita empresa)

Git conectado já é um CI/CD: build por push, preview por PR, produção por merge. Refinamentos nativos: Checks (integrações que bloqueiam o deploy se testes/Lighthouse falharem), Deploy Hooks (URLs que disparam rebuild — perfeitas para webhook de CMS), Ignored Build Step (pular builds quando nada relevante mudou) e proteção de branch no próprio Git.

Pipeline com GitHub Actions (controle total)

Quando o time exige testes, lint e migrações antes de qualquer deploy, o padrão é buildar no CI e enviar o resultado pronto:

name: Deploy
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20 }
      - run: npm ci
      - run: npm test                      # testes bloqueiam o deploy
      - run: npm i -g vercel
      - run: vercel pull --yes --environment=production --token=${{ secrets.VERCEL_TOKEN }}
      - run: vercel build --prod --token=${{ secrets.VERCEL_TOKEN }}
      - run: vercel deploy --prebuilt --prod --token=${{ secrets.VERCEL_TOKEN }}

O trio pull → build → deploy --prebuilt usa a Build Output API: o build acontece no seu CI e a Vercel só recebe o artefato — mesmo pipeline para preview (sem --prod).

Release avançado

• Promote: desacople deploy de release — suba para produção "desligado" e promova quando quiser (vercel promote).
• Feature flags: com Edge Config + Flags SDK, ligue features por porcentagem de usuários, plano ou país — rollout gradual e kill switch sem redeploy.
• Skew Protection elimina a classe de bugs "usuário com front antigo chamando API nova" durante releases.
• Rollback como cultura: reverter primeiro, investigar depois. Na Vercel isso custa segundos, então use.

Monorepos e Turborepo

Objetivo: organizar múltiplos apps e pacotes num só repositório com builds rápidos — o padrão de empresas médias e grandes.

Num monorepo, site institucional, app, docs e pacotes compartilhados (UI, config, tipos) vivem juntos. O Turborepo (mantido pela Vercel) orquestra as tarefas com cache e paralelismo:

meu-monorepo/
├── apps/
│   ├── web/        → projeto Vercel 1 (site)
│   └── app/        → projeto Vercel 2 (dashboard)
├── packages/
│   ├── ui/         → design system compartilhado
│   └── config/     → eslint, tsconfig, tailwind
└── turbo.json

{
  "tasks": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": [".next/**", "!.next/cache/**"]
    },
    "test": { "dependsOn": ["build"] },
    "lint": {}
  }
}

Como a Vercel encaixa

• Um projeto Vercel por app: importe o mesmo repositório duas vezes, definindo o Root Directory (apps/web, apps/app) de cada projeto.
• Remote Caching de graça: o cache do Turborepo é compartilhado entre sua máquina, o CI e os builds da Vercel. Se ninguém mexeu no pacote ui, o build dele é reaproveitado — builds de minutos caem para segundos.
• Builds condicionais: com npx turbo-ignore no Ignored Build Step, um push que só mudou o site não rebuilda o dashboard.
• Mudou um pacote compartilhado? Todos os apps que dependem dele rebuildam — e só eles.

Fluid Compute e engenharia de custos

Objetivo: entender o modelo de execução moderno da Vercel e otimizar a fatura como responsabilidade de engenharia.

O que é Fluid Compute

O serverless clássico (estilo Lambda) seguia "1 requisição = 1 instância": cold start frequente e desperdício — você pagava a instância inteira enquanto ela esperava o banco ou uma API de IA responder. O Fluid Compute (padrão desde 2025, sobre microVMs próprias da Vercel) muda o modelo:

• Concorrência por instância: uma mesma instância atende várias requisições simultâneas, aproveitando o tempo de I/O ocioso.
• Menos cold starts: instâncias reutilizadas + cache de bytecode (o V8 não recompila sua função a cada invocação).
• Active CPU pricing: você paga por milissegundos de CPU ativa + um valor baixo por memória provisionada. Tempo esperando I/O quase não custa — para workloads de IA e APIs (majoritariamente espera), a conta pode cair drasticamente.
• Execuções longas: até 30 minutos, viabilizando geração de vídeo, relatórios pesados e agentes de IA.
• waitUntil ganha eficiência: o pós-processamento roda na capacidade ociosa da própria instância.

Playbook de otimização de custos

1. Cache primeiro: todo HIT na CDN é invocação não paga (módulo 10). É a alavanca nº 1.
2. Estático onde der: SSR desnecessário é o maior gerador de custo evitável.
3. Imagens: limite os tamanhos gerados pelo Image Optimization; imagem de terceiros sem controle infla transformações.
4. Funções enxutas: menos CPU por request = menos custo; mova trabalho pesado para jobs/queues.
5. Proteja rotas caras: rate limit e bot filtering evitam pagar pela CPU de scrapers.
6. Spend Management: configure alertas e teto de gastos com pausa automática — apresentar isso num time demonstra senioridade.

IA na Vercel: AI SDK, Gateway, v0 e agentes

Objetivo: dominar o stack de IA da plataforma — a área que mais abre vagas em 2026.

AI SDK

O Vercel AI SDK é a biblioteca TypeScript mais usada para apps de IA: interface única para dezenas de modelos (OpenAI, Anthropic, Google…), streaming pronto, saída estruturada e tool calling.

import { streamText } from "ai";

export async function POST(req: Request) {
  const { messages } = await req.json();
  const result = streamText({
    model: "anthropic/claude-sonnet-4-6", // resolvido pelo AI Gateway
    system: "Você é um assistente de suporte da loja.",
    messages
  });
  return result.toUIMessageStreamResponse(); // streaming p/ useChat()
}

As peças do stack

Por que a Vercel é forte para IA

• Streaming nativo nas funções (respostas token a token);
• Fluid Compute cobra pouco pela espera do modelo (inferência é 95% I/O) e permite execuções de minutos;
• waitUntil para gravar histórico/telemetria após responder;
• BotID e Firewall para proteger endpoints de IA — os mais visados para abuso de custo.

Backends completos e arquitetura enterprise

Objetivo: enxergar a Vercel além do front — e saber decidir quando usá-la ou não.

Vercel como plataforma de backend (2026)

• Frameworks de backend: Express, Hono, Fastify, e Python (FastAPI, Flask) rodam nativamente — inclusive serviços backend-only, sem front.
• Queues: filas gerenciadas para processamento assíncrono confiável (e-mails, webhooks, pipelines).
• Cron + workflows duráveis: tarefas agendadas e fluxos de longa duração.
• Container Registry e Sandbox: imagens otimizadas para Fluid, spin-up rápido.
• Multi-região e failover: funções replicadas com tolerância a queda de região.
• Microfrontends: vários projetos servidos sob um domínio (via rewrites ou suporte nativo), permitindo times independentes com deploys independentes.

Arquitetura de referência de um SaaS

Usuário
  │
  ▼
Edge Network ──► Firewall/WAF + Bot filtering + Rate limit
  │
  ├─ Cache HIT ──► resposta da CDN (maioria do tráfego)
  ▼
Middleware (auth gate, geo, flags via Edge Config)
  │
  ├─ Páginas: estático + ISR + streaming (Next.js)
  ├─ APIs: Vercel Functions (Fluid, região gru1)
  │     ├─► Neon Postgres (pooled)
  │     ├─► Upstash Redis (cache/rate limit)
  │     └─► Blob (arquivos)  ·  AI Gateway (LLMs)
  └─ Assíncrono: Queues + Cron + waitUntil
Observabilidade: Logs → Drain (Datadog) · Speed Insights · Alertas

Quando a Vercel NÃO é a resposta

• Conexões persistentes de longa duração (WebSocket dedicado, servidor de jogo) — use um serviço próprio (Fly.io, Railway, ECS) ao lado, ou serviços de realtime gerenciado (Pusher, Ably, Supabase Realtime).
• Processamento contínuo 24/7 de CPU cheia (transcodificação em massa, treinamento de modelos) — workers dedicados custam menos.
• Requisitos rígidos de residência de dados/rede privada que exijam VPC própria — avalie Enterprise (com secure compute) ou hospede o backend na sua nuvem e a borda na Vercel.

A resposta madura raramente é "tudo ou nada": borda + front + APIs na Vercel, e cargas especializadas onde fizerem sentido — conversando via HTTP e filas.

Vercel no mercado de trabalho

Objetivo: transformar tudo o que você aprendeu em entrevista marcada e proposta assinada.

Onde esse conhecimento é pedido

• Front-end pleno/sênior (React/Next.js): a maioria absoluta das vagas Next.js pressupõe deploy e operação na Vercel.
• Full-stack em startups: o stack Vercel + Neon/Supabase + AI SDK domina os MVPs; founding engineers vivem nele.
• Agências e consultorias: muitos projetos simultâneos → previews, domínios e Web Vitals no dia a dia.
• AI Engineer: AI SDK, AI Gateway e streaming aparecem nominalmente nas descrições.
• Freelance internacional: gringos contratando "Next.js developer" esperam entrega ponta a ponta — e a Vercel é a ponta.

Faixas salariais (referência ampla, Brasil, 2026)

Valores variam muito por região, empresa e negociação — use como ordem de grandeza, não como promessa. O ponto: o domínio de deploy/infra descrito nesta apostila é justamente um dos fatores que puxam do meio da faixa para o topo.

Os 3 projetos de portfólio que abrem portas

1. SaaS completo: Next.js + auth + Neon Postgres + Stripe (modo teste) + ISR no conteúdo público + dashboard SSR. Demonstra os módulos 5–11.
2. App de IA: chat com AI SDK, streaming, tool calling e rate limiting (módulo 17). É o projeto que mais gera conversa em 2026.
3. Monorepo com site + app + design system e Turborepo com remote caching (módulo 15). Fala a língua das empresas maiores.

Como apresentar (isso importa tanto quanto o código)

• Demo no ar com domínio próprio — link direto no topo do README e do currículo.
• README que vende: print/gif, decisões de arquitetura (por que ISR aqui, por que Edge Config ali), e um diagrama tipo módulo 18.
• Números: nota do Lighthouse, LCP do Speed Insights, tempo de build com/sem remote cache.
• Histórico limpo: commits organizados, zero segredo commitado, CI verde visível.
• No LinkedIn, escreva 2–3 posts curtos sobre o que aprendeu (ex.: "como derrubei meu LCP de 4s para 1,8s") — recrutador tech pesquisa por esses termos.

Banco de perguntas de entrevista + glossário

Clique em cada pergunta para ver a resposta-modelo. Treine respondendo em voz alta antes de abrir.

Glossário rápido