Vercel lanza soporte nativo para Dockerfiles en su plataforma serverless

¿Qué ha ocurrido?

El 11 de febrero de 2025, Vercel anunció en su blog oficial el soporte para Dockerfiles en su plataforma serverless, permitiendo a los desarrolladores incluir un archivo Dockerfile.vercel (o Containerfile.vercel) en sus proyectos. Vercel construye, almacena y despliega la imagen en su sistema Fluid compute, lanzado en octubre de 2024 (según el blog de Vercel). El servidor debe escuchar en el puerto $PORT (por defecto 80) y hablar HTTP. La plataforma se encarga del autoescalado, logs, despliegues de vista previa y enrutamiento, sin necesidad de gestionar un registro de contenedores, un demonio Docker local o un clúster. Este movimiento sigue a la tendencia de plataformas como Fly.io y Railway, que ya ofrecían despliegue de contenedores, pero Vercel lo integra con su ecosistema de frontend y funciones serverless.

¿Por qué es importante?

Históricamente, Vercel se centró en frontends estáticos y funciones serverless ligeras (Vercel Functions), con soporte limitado a JavaScript/TypeScript. Con Dockerfiles, Vercel compite directamente con Fly.io, Railway o Google Cloud Run, ofreciendo una experiencia unificada para aplicaciones completas (frontend + backend contenerizado). La integración con el flujo de trabajo de Vercel (previews por commit, despliegues instantáneos) reduce la fricción para equipos que ya usan la plataforma. Además, el uso de optimized boot images —instantáneas comprimidas del disco que se transmiten bajo demanda— permite arranques rápidos incluso con imágenes grandes, un problema típico en entornos serverless. Según el blog de Vercel, estas imágenes optimizadas permiten que el servidor comience a manejar solicitudes antes de que la imagen completa se haya descargado, mejorando la latencia de arranque. Esto es clave para aplicaciones como procesamiento de video con FFmpeg o navegadores headless como Chromium, que requieren librerías del sistema.

Impacto y consecuencias

Para los desarrolladores, esto significa que pueden llevar a Vercel aplicaciones existentes escritas en cualquier lenguaje (Go, Ruby, Python, Java, PHP, etc.) sin reescribirlas como funciones serverless. Empresas que usan Vercel para su frontend ahora pueden consolidar también el backend en la misma plataforma, simplificando la infraestructura. La facturación solo por CPU usada (Fluid compute) es atractiva para cargas de trabajo intermitentes, como APIs con tráfico variable. Sin embargo, hay limitaciones: los contenedores son stateless (sin estado persistente local), por lo que se necesita una base de datos externa o caché. Vercel promete almacenamiento duradero adjunto próximamente, según el blog. Además, el soporte para Dockerfiles no reemplaza la detección automática de frameworks, sino que la complementa para casos donde el framework no es reconocido o se requieren librerías del sistema. Comparado con Google Cloud Run, que ofrece un SLA del 99.95% y almacenamiento persistente (Cloud Filestore), Vercel aún carece de estas garantías, pero su integración con el ecosistema de frontend es más estrecha. Para startups, esto reduce la necesidad de DevOps especializado, ya que Vercel maneja el escalado y la infraestructura.

¿Qué deben saber los lectores?

• Requisitos técnicos: El servidor debe escuchar en $PORT y hablar HTTP. Cualquier stack que cumpla esto funciona (Rails, Spring Boot, Express, Laravel, ASP.NET, FastAPI, nginx, etc.). Según la documentación, incluso Java y PHP son compatibles.
• Proceso de despliegue: Basta con añadir un Dockerfile.vercel en la raíz del proyecto y ejecutar vercel o hacer git push. Vercel construye la imagen, la almacena en su Registro de Contenedores (Vercel Container Registry) y la despliega. Cada push genera una URL de vista previa.
• Rendimiento: Las imágenes se convierten en optimized boot images para arranques rápidos. Una vez activas, Fluid compute mantiene las instancias calientes y las escala a cero cuando están inactivas, lo que permite la facturación por uso de CPU.
• Precio: Solo se paga por el tiempo de CPU utilizado, sin coste por instancias inactivas. Es ideal para APIs con tráfico variable. No hay coste adicional por el registro de contenedores.
• Limitaciones: Sin estado persistente local; se requiere un servicio externo para datos duraderos (por ejemplo, Vercel KV, base de datos externa). El soporte para almacenamiento adjunto está en desarrollo. Además, no hay garantía de SLA explícita para contenedores.

“Un contenedor en Vercel es un ciudadano de primera clase. Se ejecuta en la misma plataforma y el mismo cómputo que tu frontend y el resto de tus servicios en Vercel.” — Vercel Blog

En resumen, Vercel democratiza el despliegue de contenedores al eliminar la complejidad operativa, manteniendo la experiencia serverless. Para startups y equipos pequeños, es una alternativa potente a soluciones más pesadas como Kubernetes, aunque concesiones en persistencia y SLA. La adopción de estándares OCI (Open Container Initiative) garantiza portabilidad, y la integración con el flujo de trabajo de Vercel (previews, despliegues instantáneos) lo convierte en una opción atractiva para equipos que ya usan la plataforma. Sin embargo, para aplicaciones con requisitos estrictos de estado o alta disponibilidad, puede ser necesario combinar Vercel con servicios externos.