Vercel Deployment Best Practices 2026: La Plataforma no es el Producto — el Framework es el Foso
Vercel no compite en hosting: posee Next.js, el framework por defecto que React recomienda. 5 pasos para desplegar sin pagar el peaje del lock-in.
Hay una empresa que decide cómo todo el ecosistema React escribe aplicaciones web — y el hosting es solo cómo cobra
Esa empresa es Vercel. Y si solo la estáis comparando por edge locations, cloud bills o latencia, estáis comparando lo que no importa.
El argumento habitual —el mismo de cada comparativa "Vercel vs. Netlify vs. Cloudflare"— es que Vercel es un host estático/serverless más, compitiendo en precio y rendimiento. Ese planteamiento es erróneo.
*El host nunca fue el producto. Era el canal de distribución. *
La palanca real de Vercel es que Next.js —el framework que creó— es la forma por defecto en que los nuevos desarrolladores de React aprenden a construir. La documentación oficial de react.dev, en su guía "Start a New React Project", sitúa a Next.js primero como framework full-stack recomendado.
Eso significa que el CLI de Vercel, sus convenciones de ficheros y su modelo de deploy se internalizan antes de que ningún desarrollador evalúe a un competidor. Cualquier rival puede igualar la latencia edge y las features. No puede desbancar al framework que los docs de React señalan por defecto.
Aquí va el marco de 5 pasos para desplegar bien — sin pagar el peaje invisible del lock-in.
El Problema: "Funciona en Local" No es una Estrategia de Deployment
❌ Lo que la mayoría hace: "Funciona en mi máquina, hacemos `vercel --prod` y nos olvidamos."
✅ Lo que deberíais hacer: tratar Vercel como un ecosistema de edge, no como un servidor Node genérico. Configurar caché, middleware y analytics desde el día uno.
El error fundacional es asumir que Next.js se comporta igual en cualquier host. Las funciones que hacen a Vercel interesante —ISR, Edge Middleware, preview deployments— solo materializan su valor cuando la app se construye Next.js-first y se configura explícitamente.
Escalad un proyecto existente en lugar de empezar con App Router, y os perderéis el 80% del beneficio. Es la diferencia entre desplegar en Vercel y construir para Vercel.
1. Empieza con App Router, No con un Host para una App Existente
El beneficio completo de Vercel —ISR en el edge, middleware, route handlers— solo aparece cuando la app nace con el modelo mental correcto. No añadas Vercel a una app Node/Express heredada.
Scaffold minimal end-to-end:
```bash
npx create-next-app@latest my-app
Sigue el asistente, elige App Router y TypeScript
vercel # primer deploy (entorno de preview)
vercel --prod # despliegue a producción
```
Ese es el claim del zero-config en acción: una app Next.js completa —con ISR, funciones serverless y edge middleware— despliega desde un solo comando. Sin configurar nginx, sin escribir Dockerfiles, sin aprovisionar una VPS.
Pero cuidado. Que sea gratis configurarlo no significa que debas ignorar la configuración. El zero-config es la puerta de entrada al soft lock-in: funciona tan bien que no os dais cuenta de que os estáis atando.
2. Dueño de Tu Config de Deployment — Comprométela en el Repo
La configuración en el dashboard es click-config no reproducible. El comportamiento que importa —headers de seguridad, reglas de caché, redirects— debe vivir en `vercel.json` y estar commiteada.
```json
{
"headers": [
{
"source": "/(.*)",
"headers": [
{ "key": "X-Frame-Options", "value": "DENY" },
{ "key": "X-Content-Type-Options", "value": "nosniff" },
{ "key": "Referrer-Policy", "value": "strict-origin-when-cross-origin" },
{ "key": "Cache-Control", "value": "public, s-maxage=60, stale-while-revalidate=600" }
]
}
],
"redirects": [
{ "source": "/blog/:slug", "destination": "/articulos/:slug", "permanent": true }
],
"rewrites": [
{ "source": "/old-path", "destination": "/new-path" }
]
}
```
Esta config complementa, no reemplaza la de Next.js. `headers` en el edge, `redirects` para SEO migrado y `rewrites` para rutas limpias. Todo reproducible entre entornos.
3. Cada Pull Request Produce un Preview Deployment — Úsalo Como Workflow, No Como Afterthought
El preview deployment por PR es la feature más infravalorada de Vercel, y no porque sea difícil de activar — lo es porque la mayoría la trata como un extra.
Conectad la integración de git o el CLI y configurad que cada pull request genere un entorno aislado. Eso convierte el preview en el núcleo de la review de código, no un accesorio.
Flujo que funciona:
1. Hacemos push a una rama feature.
2. Vercel genera una URL de preview aislada.
3. El cliente o el equipo revisa esa URL — no "imagina" cómo quedará.
4. Merge a main → deploy a producción.
Este flujo es trivial en Vercel y manual (o inexistente) en un VPS. Es parte del soft lock-in: os volvéis adictos al preview, y reproducirlo fuera es trabajo puro.
4. Edge Middleware: Fuerza el Modelo Mental del Edge Runtime
Añadir un caso de uso de Edge Middleware —auth check, redirect geográfico o A/B test— os obliga a pensar en el edge runtime, no en un servidor Node normal.
```ts
// middleware.ts
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';
export function middleware(request: NextRequest) {
const country = request.geo?.country ?? 'unknown';
// Reescritura geográfica en el edge
if (country === 'ES' && request.nextUrl.pathname === '/pricing') {
return NextResponse.rewrite(new URL('/pricing/es', request.url));
}
// A/B test simple con cookie
const variant = request.cookies.get('variant')?.value ?? 'control';
if (!request.cookies.get('variant')) {
const res = NextResponse.next();
res.cookies.set('variant', Math.random() > 0.5 ? 'test' : 'control', { maxAge: 3600 });
return res;
}
return NextResponse.next();
}
export const config = {
matcher: ['/pricing', '/api/:path*'],
};
```
Middleware se ejecuta antes de la caché CDN, en el edge, sin arrancar un proceso Node por petición. Esto es lo que un host genérico no ofrece nativamente — y es parte del asterisco oculto de "puedo desplegar Next.js en cualquier sitio".
El ISR es la otra pieza del modelo mental: `export const revalidate = 60;` en una página hace que sea estática y cacheada globalmente, mientras se re-renderiza en segundo plano.
```ts
// app/blog/[slug]/page.tsx
export const revalidate = 60; // stale-while-revalidate en el edge
export default async function PostPage({ params }: { params: { slug: string } }) {
const post = await fetchPost(params.slug);
return <article>{post.title}</article>;
}
```
El viejo tradeoff era "estático = rápido pero obsoleto" versus "server-rendered = fresco pero lento". ISR rompe ese tradeoff: la página es estática y además se refresca en segundo plano. Esto es lo que los hosts genéricos o no ofrecen o implementan como un cron cutre.
5. Instrumenta Desde el Día Uno — o Descubrirás Regresiones en Producción
Activa Vercel Web Analytics y Speed Insights (o herramienta equivalente de Core Web Vitals) antes de lanzar, no después.
El objetivo: que cada deployment muestre su impacto en rendimiento. Así las regresiones se cazan por deployment, no "descubiertas" por un cliente quejándose en producción.
Web Analytics: eventos de página, sin cookies y sin afectar al LCP.
Speed Insights: datos de campo reales (CrUX) por deployment.
Vínculo con los previews: comparad rendimiento entre PRs antes del merge.
El Debate del Lock-In: El Verdadero Astillero no es el Runtime, es el Framework
Ahora, la objeción obvia: "Puedo correr Next.js en AWS, Cloudflare o un VPS y mantener el control total."
Es técnicamente cierto. Next.js es open source y auto-hostable. Habéis de conceder eso.
Pero es una cuestión de coste total, no de monthly bill. Replicar en otro sitio ISR-at-edge, preview environments, middleware y analytics integrados es trivial en Vercel y trabajo manual (mucho) en cualquier otro sitio.
*Distinguid lock-in duro (runtime propietario) de lock-in blando (framework open source cuya mejor experiencia vive en un solo host). El blando es más insidioso porque es invisible hasta que intentas irte. *
❌ Lectura ingenua: "Es open source, no hay lock-in."
✅ Lectura correcta: "Es open source, pero la integración ISR + preview + middleware + AI SDK es significativamente mejor en Vercel. Esa asimetría ES el lock-in."
Si os auto-hosteáis, leed la documentación por lo que perdéis, no solo por lo que pagáis.
El Endgame: La Guerra del Bundler y el Giro a la IA
El movimiento Turborepo (adquirido en diciembre de 2021) y Turbopack (el bundler en Rust anunciado como reemplazo de Webpack) no es sobre conveniencia del desarrollador. Es sobre poseer el último eslabón de la cadena.
La estrategia es integración vertical completa: Next.js (framework) → Turbopack (bundler) → Edge Network (runtime) → Vercel (deploy). Webpack es la única pieza que Vercel no controlaba — y Turbopack es el intento directo de reemplazarlo.
Y luego está el giro decisivo: el Vercel AI SDK es deliberadamente framework-agnostic — soporta React, Vue, Svelte y runtimes server. Es lo opuesto al juego de lock-in de Next.js.
```ts
// app/api/chat/route.ts con el Vercel AI SDK
import { streamText } from 'ai';
import { openai } from '@ai-sdk/openai';
export async function POST(req: Request) {
const { messages } = await req.json();
const result = streamText({
model: openai('gpt-4o'),
messages,
});
return result.toAIStreamResponse();
}
```
La lógica: la UI generada por IA es la próxima frontera del desarrollo web, y quien conecte esa generación con producción gana. Al hacer el SDK multi-framework, Vercel hedgea la apuesta: aunque gane un framework de otro, Vercel sigue dueño de la fontanería de IA.
Conclusión: Desplegad Con los Ojos Abiertos
El resumen en cinco movimientos:
→ Construid Next.js-first con App Router, no añadáis Vercel a una app legacy.
→ Comprometead `vercel.json` con headers, redirects y rewrites — config reproducible, no click-config.
→ Previews de cada PR como núcleo del workflow de review, no un accesorio.
→ Edge Middleware para forzar el modelo mental del edge runtime.
→ Analytics e instrumentación desde el día uno, por deployment.
Vercel no es el mejor host porque sea barato ni el más rápido en latencia edge. Es el más relevante porque posee el lenguaje en el que escribís. Podéis dejarlo cuando queráis — pero notaréis cómo lo extrañáis.
El soft lock-in no se combate rechazando Next.js. Se combate entendiendo qué estáis firmando con cada click en "Deploy". Saber eso es la única ventaja real que podéis tener.
Lee el artículo completo en brianmenagomez.com
Más sobre mis servicios en brianmenagomez.com
Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF