Vercel Deployment Best Practices: El Framework de 5 Pasos para Desplegar Sin Pagar el Peaje del Lock-In
Guía definitiva de Vercel deployment best practices: audit de runtime, ISR estratégico, Edge vs Node.js, y el framework de 5 pasos para evitar el lock-in arquitectónico.
Vercel Hace que Deployar sea Mágico. Esa Magia Tiene un Precio que No Ves en el Dashboard
El 90% de los desarrolladores trata Vercel como "un Netlify con esteroides". Una plataforma de deploy que igual te vale.
*Error. *
Vercel no es un hosting genérico. Es un ecosistema arquitectónicamente opinado que moldea cada decisión de diseño que tomas. Elegir Vercel es comprar un modelo edge-first, serverless-first, Next.js-centric.
El problema no es que Vercel sea malo. Es que la mayoría firmáis el contrato de runtime sin leer la letra pequeña.
Y luego llega el día en que necesitáis una WebSocket persistente. O un job que ejecute más de 60 segundos. O un driver de base de datos que dependa de `fs`. Y descubrís que vuestra app no os pertenece del todo.
Este artículo no va de "Vercel es malo". Va de cómo desplegar con conciencia arquitectónica. Las vercel deployment best practices que el 90% ignora.
---
El Contrato que Firmas Cuando Haces Clic en "Deploy"
Vercel domina porque resolvió el problema real: deploy con un push a Git. Zero configuración. Preview deployments automáticos. Escalado que no piensas.
Pero ese "zero-config" es una abstracción que esconde decisiones arquitectónicas profundas.
1. El Edge Runtime NO es Node.js
Este es el malentendido más caro.
La Edge Runtime de Vercel corre sobre V8 isolates, no sobre Node.js. No tienes acceso a:
❌ `fs` — olvídate de leer ficheros del sistema
❌ `child_process` — nada de spawn procesos hijo
❌ Módulos nativos — adiós a dependencias C++
❌ Stream APIs completas — el modelo de streaming es restringido
❌ Partes de `crypto` — el subconjunto es limitado
¿Qué implica esto? Que si migras middleware de Express, un ORM con connection pooling, o cualquier librería que dependa del ecosistema Node.js completo, te estrellas.
```typescript
// ❌ Esto NO funciona en Edge Runtime
import fs from 'fs';
import { createServer } from 'http';
export const runtime = 'edge'; // <- Boom en build time
export async function GET() {
const data = fs.readFileSync('./data.json', 'utf-8');
return Response.json(JSON.parse(data));
}
```
```typescript
// ✅ Esto SÍ funciona en Edge Runtime
export const runtime = 'edge';
export async function GET() {
const res = await fetch('https://api.example.com/data');
const data = await res.json();
return Response.json(data);
}
```
La regla es simple: Edge para operaciones ligeras y rápidas. Node.js runtime cuando necesitas APIs completas.
Los 5 Límites que el Dashboard No Te Muestra
2. Timeout de 60 Segundos en Serverless Functions
En el plan Pro, las funciones serverless tienen un timeout de 60 segundos (300 con request). En el Hobby, 10 segundos.
*Para una API que procesa un CSV, genera un PDF, o consulta múltiples fuentes externas, 60 segundos es poco. *
```typescript
// ❌ Patrón frágil: asumes que tu función terminará antes del timeout
export async function POST(request: Request) {
const data = await request.json();
const result = await processLargeDataset(data); // Puede tardar 90s
return Response.json(result); // Timeout: el cliente recibe 504
}
```
```typescript
// ✅ Patrón robusto: timeout-aware con Promise.race
export async function POST(request: Request) {
const data = await request.json();
const timeout = new Promise((_, reject) =>
setTimeout(() => reject(new Error('Function timeout')), 55000)
);
try {
const result = await Promise.race([
processLargeDataset(data),
timeout
]);
return Response.json(result);
} catch (error) {
return Response.json(
{ error: 'Processing timeout' },
{ status: 503 }
);
}
}
```
Si necesitas computación larga, Vercel no es tu plataforma. Offload a un worker externo.
3. WebSockets: El Talón de Aquiles de Vercel
Vercel soporta WebSockets en Serverless y Edge Functions... en beta.
*La realidad: * No hay sticky sessions garantizadas. El timeout de 60 segundos mata conexiones persistentes. No hay multiplexación nativa.
Para una app de chat, colaboración en tiempo real, o gaming, usar Vercel para las WebSockets es autoflagelación.
```typescript
// ❌ Esto funcionará unos minutos... y luego se caerá
import { WebSocket } from 'ws';
export async function GET() {
// En Edge Runtime no tienes acceso completo a ws
// En Serverless Functions, el timeout mata la conexión
const ws = new WebSocket('wss://api.example.com');
ws.on('message', (data) => {
console.log('Received:', data);
});
return new Response('WebSocket connected');
}
```
La solución práctica: Frontend en Vercel. Backend WebSocket en Fly.io, Railway, o un VPS con Node.js. Desacopla lo que es estado de lo que es contenido.
4. ISR: La Feature Más Pegajosa (y Peligrosa)
Incremental Static Regeneration es brillante para contenido. Pero tiene un lado oscuro: la complejidad de invalidación de caché.
```typescript
// ✅ ISR básico — funciona para contenido que cambia predeciblemente
export async function getStaticProps() {
const data = await fetch('https://api.example.com/posts');
const posts = await data.json();
return {
props: { posts },
revalidate: 3600 // Revalida cada hora
};
}
```
```typescript
// ⚠️ ISR con revalidación on-demand — potente pero frágil
import { revalidateTag } from 'next/cache';
export async function POST(request: Request) {
const body = await request.json();
// Actualizas datos en la base de datos
await updatePost(body.id, body.data);
// Invalidas la caché
revalidateTag(`post-${body.id}`);
return Response.json({ success: true });
}
```
¿El problema? Cuando tienes múltiples fuentes de datos, revalidación por tiempo mezclada con revalidación on-demand, y páginas con dependencias cruzadas, la estacionalidad de los datos se vuelve impredecible.
ISR funciona mejor cuando:
✅ Los datos cambian de forma predecible
✅ No necesitas frescura en tiempo real
✅ El contenido es público, no personalizado
ISR no funciona para:
❌ Datos específicos de usuario (usa Server Components con streaming)
❌ Información que cambia cada pocos segundos
❌ Páginas con muchas dependencias de datos anidadas
5. El Lock-In No es un Bug. Es la Feature
Vercel es mantenido por el mismo equipo que creó Next.js. La integración es tan profunda que `next build` optimiza el output para la infraestructura de Vercel.
*¿Puedes migrar a AWS o Cloudflare? * Sí. Pero no es trivial.
El lock-in real no es técnico. Next.js es open source. Puedes llevar el build output a cualquier sitio.
El lock-in real es arquitectónico. Has diseñado tu app alrededor del modelo edge de Vercel. Has construido con ISR. Has usado Edge Middleware. Has hecho que tu backend dependa del runtime restringido.
Migrar no es reescribir `vercel.json`. Es rediseñar media app.
---
El Marco de 5 Pasos para un Deployment Consciente en Vercel
Aquí está el framework que uso para auditar proyectos antes de desplegar en Vercel.
Paso 1: Audita tus Requisitos de Runtime
Haz una lista de cada API route, cada Server Action, cada background job.
Pregunta por cada uno:
¿Necesita acceso a `fs`, `child_process`, o módulos nativos? → Node.js runtime forzado
¿Es una operación ligera (<50ms) sin dependencias de sistema? → Edge runtime
¿Cuánto tiempo necesita ejecutarse? → Si >60s, no puede vivir en Vercel
Regla práctica: Si más del 30% de tus rutas necesitan Node.js runtime completo, reconsidera si Vercel es la plataforma adecuada.
Paso 2: Elige el Runtime por Ruta, No Globalmente
No declares `runtime: 'edge'` en todo el proyecto porque "es más rápido".
```typescript
// ✅ Por ruta: Edge para lo rápido, Node.js para lo pesado
// app/api/light/route.ts
export const runtime = 'edge';
export async function GET() {
return Response.json({ status: 'ok' });
}
// app/api/heavy/route.ts
export const runtime = 'nodejs';
export async function POST(request: Request) {
const data = await processLargeFile(request);
return Response.json(data);
}
```
Paso 3: Implementa ISR con Conciencia de Estacionalidad
Usa ISR solo para contenido donde la estacionalidad sea aceptable.
Contenido de blog: `revalidate: 3600` — perfecto
Catálogo de productos con stock en tiempo real: no uses ISR
Páginas de usuario: no uses ISR
Para datos en tiempo real: Server Components con streaming o fetch directo desde el cliente.
Paso 4: Prepara un Plan de Salida
Haz este ejercicio: "Si mañana Vercel duplica sus precios, ¿cuánto tardaría en migrar?"
Identifica qué features de Vercel estás usando (Edge Middleware, ISR, Edge Config, etc.)
Documenta alternativas open source o multi-cloud para cada una
Mantén un `Dockerfile` funcional en el repo — aunque no lo uses
Señal de alarma: Si no puedes ejecutar tu app localmente con `node server.js` sin Vercel CLI, estás atrapado.
Paso 5: Desacopla lo Stateful de lo Stateless
Esta es la regla de oro.
Vercel es excelente para:
✅ Páginas estáticas y contenido cacheable
✅ APIs ligeras y rápidas
✅ Preview deployments y CI/CD
Vercel no es bueno para:
❌ WebSockets persistentes
❌ Jobs de larga duración
❌ Backends stateful con conexiones de base de datos mantenidas
Arquitectura híbrida recomendada:
Frontend en Vercel (Next.js, páginas estáticas, ISR)
Backend en Fly.io o Railway (WebSockets, workers, APIs stateful)
Base de datos externa (Supabase, Neon, o tu propia instancia PostgreSQL)
```typescript
// ✅ Patrón híbrido: Frontend en Vercel, WebSocket fuera
// app/api/chat/route.ts (en Vercel)
export async function POST(request: Request) {
const { message, userId } = await request.json();
// Forward al backend real de WebSocket
const response = await fetch('https://chat-api.example.com/send', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ message, userId })
});
return Response.json(await response.json());
}
```
---
Vercel No es tu Enemigo. El Desconocimiento de su Modelo Sí.
Vercel es una plataforma extraordinaria para el 80% de los casos de uso: landing pages, e-commerce, blogs, documentación, dashboards ligeros.
*El problema no es Vercel. Es tratarlo como una solución universal. *
Cuando entiendes el contrato de runtime que firmas — Edge vs Node.js, timeouts de 60s, ISR con estacionalidad, WebSocket en beta — puedes tomar decisiones informadas.
Las vercel deployment best practices no son sobre cómo deployar más rápido. Son sobre cómo deployar sin perder el control de tu arquitectura.
La próxima vez que hagas clic en "Deploy", pregúntate: ¿esta app me pertenece a mí o le pertenece a Vercel?
*La respuesta define si estás construyendo un producto o alquilando una jaula. *
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