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.
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. *
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.
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é.
¿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".
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
Dockerfilefuncional 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)
---
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. *
Artículos relacionados
- Vercel Deployment Best Practices: Lo Que Nadie Te Cuenta Sobre Observabilidad y Rollbacks
- Vercel en Producción: La Guía Definitiva de Deployment que Nadie Escribe
- Vercel No es un Hosting Barato: Es un Propietario con Cargo de Traslado
- Optimización de Serverless Functions en Vercel: El Patrón que Reduce Cold Starts un 70%
- El Precio Oculto del Zero-Config en Vercel: 50ms de Cold Start Que Te Van a Costar Clientes
---
¿Quieres recibir contenido como este cada semana? Suscríbete a mi newsletter
