Un cliente me llamó a principios de enero, absolutamente entusiasmado. "Gautam, acabo de leer que Vercel ahora hace Docker. ¿Podemos apagar nuestros droplets de DigitalOcean, verdad?" Estaba ejecutando tres droplets, dos de ellos a $24/mes cada uno, uno a $48. Tenía una hoja de cálculo lista. Quería ahorrar dinero y quería hacerlo inmediatamente.
Le dije que esperara dos semanas mientras lo probaba realmente. Fue bueno que me hiciera caso.
Aquí está el punto: el soporte de contenedores de Vercel es genuinamente impresionante. Y un VPS aún no está muerto. Ambas oraciones son verdaderas al mismo tiempo, y el matiz entre ellas vale la pena entender antes de que empieces a hacer docker push de todo a la infraestructura de Vercel y te preguntes por qué tus conexiones WebSocket siguen cayéndose.
Lo que Vercel realmente anunció
El soporte de Docker de Vercel, lanzado a través de su Build Output API y luego formalizado para uso general, te permite enviar un Dockerfile y que Vercel maneje el runtime del contenedor. Sin más restricciones a convenciones de Next.js o estructuras de archivos de funciones serverless. Escribes tu Dockerfile, Vercel lo construye, lo ejecuta.
Ese es un cambio genuino. Antes de esto, si tenías un backend con FastAPI o un servidor Node personalizado haciendo algo exótico, estabas contorsionándote para encajarlo en la forma de una función sin servidor o mantenías una VPS corriendo junto a tu frontend de Vercel. Lo último es lo que la mayoría hicimos. Era molesto pero funcionaba.
Cómo se ve realmente el Runtime
El runtime de contenedores de Vercel no es Docker bare-metal. Es más parecido a lo que obtendrías en un servicio de contenedores administrado. Tu contenedor recibe una solicitud, Vercel la enruta, el contenedor la maneja. Los procesos persistentes funcionan. Puedes ejecutar algo como un servidor Python WSGI o un binario HTTP de Go. Las tareas de larga duración dentro de un ciclo de vida de una sola solicitud están bien.
Pero las limitaciones importan. Los contenedores pueden escalar a cero. Existen cold starts. Y crucialmente: no tienes almacenamiento de disco persistente. Si tu app escribe en el sistema de archivos local y espera que esos archivos estén allí en la siguiente solicitud, vas a pasarlo mal.
Dónde Vercel Containers realmente brilla
He estado ejecutando una API REST de Django en contenedores de Vercel desde marzo. Es un servicio relativamente simple y pesado en lecturas para un cliente de medios, principalmente solicitudes GET, consultando una base de datos Neon Postgres. Sin escrituras de archivos. Sin trabajos en background. Sin WebSockets.
Ha sido excelente. Los deploy previews funcionan. La integración con GitHub significa que cada PR obtiene su propio entorno. La latencia del cold start en este contenedor en particular ronda los 800ms a 1.2 segundos en el primer hit después de estar inactivo, lo que suena mal pero es aceptable cuando el tráfico del cliente es irregular y predecible.
¿El costo de ese servicio? Alrededor de $20/mes con el plan Pro de Vercel incluido. El equivalente en DigitalOcean App Platform sería similar. Un droplet raw sería más barato, pero tendríamos que administrarlo nosotros mismos.
El escenario donde esto es claramente una victoria
Piensa en el proyecto típico de una agencia. Un sitio de marketing con un CMS headless, una API ligera para un formulario de contacto o alguna lógica personalizada, y la necesidad de deploys rápidos. Antes tendrías Vercel para el frontend y un droplet de $6 para la pequeña API. Ahora puedes poner todo en Vercel, usar un solo dashboard, tener deploy previews para la API también. Menos cosas que mantener. Menos cosas para olvidar actualizar.
Para freelancers que manejan entre cinco y quince sitios de clientes, esa simplicidad operativa vale dinero real aunque el costo de procesamiento sea un poco más alto.
Dónde un VPS sigue ganando. Claramente.
Bien. Aquí necesito ser directo, porque el entusiasmo alrededor de los contenedores de Vercel ha llevado a algunos desarrolladores a cometer errores costosos.
Operaciones persistentes del sistema de archivos. Si tu aplicación genera PDFs y los almacena localmente antes de enviarlos a S3, está bien, esa operación específica funciona. Pero si ejecutas algo como una instancia de Meilisearch auto-hospedada que escribe su índice en disco, necesitas almacenamiento persistente. Vercel no te proporciona un volumen montado. Tendrías que agregar algo como un servicio Meilisearch administrado o ejecutarlo en un VPS. Fin de la historia.
WebSockets y conexiones de larga duración. Los entornos serverless y de contenedores de Vercel tienen límites de tiempo de solicitud. Me encontré con esto en un proyecto de Seahawk a fines de 2024, antes de que incluso llegara el soporte de Docker. Estábamos construyendo una herramienta colaborativa en tiempo real para un pequeño cliente SaaS. Intentamos de todo para hacerlo funcionar en infraestructura serverless. Eventualmente movimos el servidor de WebSocket a un VPS de Hetzner de $12/mes. Problema resuelto. El VPS ha estado ejecutándose sin interrupciones desde entonces.
Trabajadores en segundo plano y cron a escala. Sí, Vercel tiene trabajos cron. Están bien para tareas programadas simples. Pero si ejecutas algo como trabajadores de Celery que procesan una cola de trabajos continuamente, quieres un proceso que simplemente... se ejecute. Un VPS lo hace trivialmente. En contenedores de Vercel, estás trabajando contracorriente.
Costo a volumen. Este es el que sorprende a la gente. Con tráfico bajo a medio, los contenedores de Vercel son competitivos. Pero con volúmenes de solicitud genuinamente altos, el precio por solicitud comienza a componer. Un servidor dedicado Hetzner de $48/mes maneja tráfico que costaría cientos de dólares en Vercel en horas pico. Mi cliente que quería apagar sus droplets, ¿uno de ellos ejecutaba un panel de control interno de alto tráfico. Hice las cuentas. Mantener el droplet era £18/mes más barato incluso después de contabilizar el tiempo de mantenimiento ocasional.
Las cargas de trabajo específicas que nunca movería a Vercel
Permíteme ser concreto. Estas son cosas que activamente dirijo a un VPS independientemente de lo que Vercel lance:
- Bases de datos auto-hospedadas. Incluso una pequeña réplica de Postgres para desempeño de lectura. Vercel no es un anfitrión de bases de datos. Úsalo con Neon, Supabase o PlanetScale, pero no intentes ejecutar Postgres en sí mismo allí.
- Procesamiento de medios. Trabajos con FFmpeg, colas de redimensionamiento de imágenes, cualquier cosa con uso intensivo de CPU y tiempos de ejecución impredecibles. Un VPS de Hetzner de $20 con 2 vCPUs lo maneja mejor y más barato.
- Herramientas internas que corren 24/7. Agentes de monitoreo, agregadores de logs, servidores proxy personalizados. Estos simplemente deben estar corriendo. Siempre. El escalado a cero es el enemigo aquí.
- Cualquier cosa que toque una GPU. Es obvio, pero vale la pena mencionarlo.
Y al revés, aquí está lo que confiaría en contenedores de Vercel hoy:
- APIs REST ligeras (FastAPI, Express, Gin) sin estado persistente
- Aplicaciones Next.js o Remix containerizadas con configuración de servidor personalizada
- APIs internas que reciben tráfico solo durante horario laboral (el escalado a cero es realmente excelente aquí)
- Cualquier servicio donde genuinamente quieras deploy previews por PR
El Costo Oculto del Que Nadie Habla: Complejidad Operacional
He construido más de 12,000 sitios a lo largo de los años en Seahawk. Lo número uno que muerde a agencias y freelancers no es el costo de cómputo. Es la sobrecarga operacional.
Un VPS suena barato a $6/mes. Y es barato. Pero entonces estás parchando, monitoreando, configurando Nginx, configurando fail2ban, ocasionalmente conectándote por SSH a las 11pm porque algo se comporta de manera extraña. Eso no es gratis. Eso es tiempo, y el tiempo es caro.
Vercel elimina todo eso. Lo mismo hacen Railway, Render y Fly.io. La competencia real aquí no es "Vercel vs un VPS en el vacío". Es "el costo de plataforma administrada vs el costo de tiempo en operaciones". Para operadores individuales y agencias pequeñas, el costo de plataforma administrada suele ser la mejor opción.
Allá por 2019 un cliente me pasó un brief que incluía administrar su servidor Ubuntu. Cotizé en consecuencia. Seis meses después todavía recibía alertas sobre espacio en disco en un servidor que técnicamente "administraba" pero había deprioritizado completamente. Desde entonces he sido mucho más deliberado acerca de qué infraestructura asumo como responsabilidad propia versus qué le pago a una plataforma que asuma.
El Framework que Realmente Uso para Decidir
No es un diagrama mágico. Solo un conjunto de preguntas que me hago en cada proyecto nuevo:
- ¿Este servicio escribe en disco y espera que esas escrituras persistan? Si es sí, necesita un VPS o almacenamiento administrado.
- ¿Este servicio mantiene conexiones de larga duración (WebSockets, SSE, gRPC streams)? Si es sí, VPS o una plataforma que lo soporte explícitamente como Fly.io.
- ¿Este servicio está limitado por CPU durante períodos extendidos? Los contenedores de Vercel tienen un techo de CPU. VPS gana.
- ¿El equipo necesita deploy previews y GitOps sin pensar? Vercel gana.
- ¿El tráfico será consistente y de alto volumen? Haz las cuentas. Un VPS suele ser más barato por encima de cierto umbral.
- ¿Es un proyecto de una sola persona o una pequeña agencia que no quiere pensar en servidores? Vercel vale la prima.
Si las preguntas 1, 2 o 3 son sí, me voy por Hetzner o DigitalOcean. Todo lo demás es una conversación.
Cómo se ve realmente 2026 para infraestructura
Las plataformas están mejorando en almacenamiento persistente. Fly.io tiene Fly Volumes. Render tiene discos persistentes. Vercel probablemente agregará algo similar eventualmente, dado cuán frecuentemente se solicita. La brecha entre "plataforma administrada" y "VPS con control total" se está cerrando.
Pero cerrar la brecha no es lo mismo que cerrarla completamente. Y la economía del procesamiento bruto no ha cambiado fundamentalmente. Una instancia Hetzner CAX11 ARM a €3,79/mes sigue siendo absurdamente buena en relación precio-valor para la carga de trabajo correcta. Nadie lo está ganando en una plataforma administrada con procesamiento equivalente.
El estado honesto del mundo en 2026 es este: el VPS no está muerto. El VPS es cada vez más opcional. Esas son cosas diferentes.
La mayoría de los proyectos nuevos que inicio en Seahawk ahora usan por defecto Vercel o Railway a menos que algo en esa lista de preguntas de arriba dispare una respuesta diferente. Probablemente hemos reducido el número de instancias VPS activas que administramos en aproximadamente 40% durante los últimos dieciocho meses. Pero las que quedan están ahí por buenas razones, y no van a desaparecer.
FAQ
¿Pueden los contenedores de Vercel reemplazar Docker Compose para paridad local a producción?
Más o menos, pero no realmente. Docker Compose se trata de orquestar múltiples servicios juntos localmente. Vercel ejecuta un único contenedor por despliegue. Si tu stack tiene un servidor web, un worker y Redis todos definidos en un archivo Compose, Vercel puede manejar la parte del servidor web. Aún necesitarías apuntar a Redis administrado (Upstash es la opción común) y manejar el worker por separado. La paridad local es mejor que antes, pero pasar de Compose a Vercel no es una traducción directa.
¿Qué sucede con los contenedores de Vercel cuando se escalan a cero?
El proceso del contenedor se detiene. Cuando llega una nueva solicitud, Vercel lo reinicia. Ese tiempo de reinicio es tu latencia de arranque en frío. Para binarios compilados (Go, Rust) esto suele ser menos de 500ms. Para runtimes más grandes como aplicaciones basadas en JVM, puede ser de 2 a 4 segundos. Vale la pena probar esto en staging antes de hacer commit, porque algunos clientes definitivamente notarán una carga inicial de 3 segundos.
¿El soporte de contenedores de Vercel está disponible en el plan gratuito Hobby?
A partir de principios de 2026, no. Los despliegues de contenedores requieren al menos el plan Pro. El tier Hobby aún soporta funciones serverless y sitios estáticos. Vale la pena revisar directamente la página de precios de Vercel ya que esto ha cambiado antes y probablemente volverá a cambiar.
¿Cuándo debería usar Fly.io en lugar de Vercel o un VPS crudo?
Fly es mi opción predeterminada cuando necesito procesos persistentes, distribución global cercana a los usuarios y no quiero gestionar la configuración del servidor. Ocupa un espacio intermedio interesante. Despliegas contenedores, pero tienes más control sobre regiones, tamaños de máquina y volúmenes persistentes de lo que Vercel ofrece. Lo uso para APIs de larga duración y cualquier cosa con requisitos de WebSocket que necesite estar en múltiples regiones. El tradeoff es que la DX es un poco más compleja que la integración de GitHub de Vercel.
---
El VPS no es algo a lo que debas recurrir por hábito. Pero tampoco es algo que debas abandonar por entusiasmo. Conoce tu workload. Haz los cálculos. Y quizás espera dos semanas antes de apagar nada.
Lecturas relacionadas: Investigación de palabras clave con IA en 2026: qué es, por qué es importante, SEO técnico y búsqueda con IA.