The real value here isn't speed, it's absence of work. Every other platform can host Next.js, but reproducing ISR's background regeneration or middleware's edge execution yourself means understanding Next.js's build manifest and building adapters. Vercel is the reference implementation.

// middleware.ts — runs at the edge, before the route renders
import { NextResponse } from 'next/server';

export function middleware(request) {
  const session = request.cookies.get('session');
  if (!session && request.nextUrl.pathname.startsWith('/account')) {
    return NextResponse.redirect(new URL('/login', request.url));
  }
  return NextResponse.next();
}

export const config = { matcher: '/account/:path*' };

# 1. Push a feature branch
git checkout -b feat/search
git push -u origin feat/search
# → Vercel builds it, comments a preview URL on the PR:
#   https://docs-git-feat-search-yourteam.vercel.app

# 2. Share that URL. Someone finds a bug. Push a fix.
#    Same branch, new commit, new preview URL. Old one still works.

# 3. Merge to main
# → production build, live on docs.example.com

# 4. Something's broken in production
#    Dashboard → previous deployment → "Promote to Production"
#    Live again in seconds. No rebuild.

Choose it when you're building a Next.js app, the team is small or has no dedicated infrastructure person, and traffic is moderate or predictable. The time you don't spend on deployment is worth more than the premium you pay per request.

Think twice when you have very high bandwidth traffic (metered pricing gets expensive fast), need long-running or stateful processes, or have compliance requirements that dictate where and how compute runs.

O valor real aqui não é velocidade, é ausência de trabalho. Qualquer outra plataforma pode hospedar Next.js, mas reproduzir a regeneração em background do ISR ou a execução no edge do middleware por conta própria exige entender o manifesto de build do Next.js e construir adaptadores. A Vercel é a implementação de referência.

// middleware.ts — roda no edge, antes da rota renderizar
import { NextResponse } from 'next/server';

export function middleware(request) {
  const session = request.cookies.get('session');
  if (!session && request.nextUrl.pathname.startsWith('/account')) {
    return NextResponse.redirect(new URL('/login', request.url));
  }
  return NextResponse.next();
}

export const config = { matcher: '/account/:path*' };

# 1. Push numa branch de feature
git checkout -b feat/search
git push -u origin feat/search
# → a Vercel builda e comenta uma preview URL no PR:
#   https://docs-git-feat-search-seutime.vercel.app

# 2. Compartilhe essa URL. Alguém acha um bug. Você corrige e dá push.
#    Mesma branch, commit novo, preview URL nova. A antiga continua funcionando.

# 3. Merge na main
# → build de produção, no ar em docs.exemplo.com

# 4. Algo quebrou em produção
#    Dashboard → deploy anterior → "Promote to Production"
#    No ar de novo em segundos. Sem rebuild.

Escolha ela quando você está construindo um app Next.js, o time é pequeno ou não tem ninguém dedicado a infraestrutura, e o tráfego é moderado ou previsível. O tempo que você não gasta com deploy vale mais do que o prêmio que você paga por requisição.

Pense duas vezes quando você tem tráfego de banda muito alto (cobrança por uso encarece rápido), precisa de processos longos ou com estado, ou tem requisitos de compliance que ditam onde e como a computação roda.