Vercel ya puede ejecutar cualquier Dockerfile en su plataforma Fluid compute

Vercel ha añadido a su plataforma soporte para contenedores arbitrarios. Los desarrolladores ya pueden desplegar cualquier servicio con un Dockerfile, desde un servicio en Go hasta una aplicación en Rails o Spring Boot. Solo tienen que añadir un archivo Dockerfile.vercel en la raíz del proyecto: la plataforma construye la imagen y la despliega en la infraestructura de Fluid compute.

Cómo funciona

El mecanismo es mínimo: con el propio servidor y el archivo Dockerfile.vercel, el proyecto está listo para desplegarse. Vercel muestra un ejemplo en Go: un servidor HTTP que escucha en el puerto de la variable $PORT (80 por defecto) y se construye con un Dockerfile de dos etapas. Primero, la imagen golang:1.24-alpine compila el binario; después, este se copia en la imagen mínima alpine:3.20, que es la que se ejecuta en producción.

El comando `vercel deploy` de la CLI construye la imagen, la guarda en el registro del proyecto y la despliega en Fluid compute, y devuelve una URL de producción. Cada git push reconstruye la imagen automáticamente y crea un despliegue de preview independiente con una URL inmutable, que se puede abrir, compartir con compañeros o usar para volver a una versión anterior.

• El único requisito para el servidor es escuchar en el puerto HTTP indicado en la variable $PORT
• El ejemplo del blog combina golang:1.24-alpine y alpine:3.20 en una construcción de dos etapas
• El despliegue se lanza con un solo comando, `vercel deploy`, desde la CLI, o automáticamente con cada git push
• Se admiten Rails, Spring Boot, Express, Laravel, ASP.NET, FastAPI y servicios detrás de nginx

Qué lenguajes y frameworks se admiten

Vercel subraya que el stack concreto da igual: funciona cualquier servicio capaz de hablar HTTP y escuchar en un puerto. La lista incluye explícitamente Rails, Spring Boot, Express, Laravel, ASP.NET, FastAPI y servidores web detrás de nginx, además de Java y PHP, plataformas que hasta ahora se asociaban más al hosting de servidores clásico que a la infraestructura serverless de Vercel.

Qué obtienen los desarrolladores

El contenedor pasa a ser un ciudadano de pleno derecho en Vercel: se ejecuta en la misma infraestructura que el frontend y el resto de servicios del proyecto. Cada commit recibe su propio despliegue de preview con una URL independiente, y el escalado es automático en ambos sentidos. Cuando crece el tráfico, la plataforma añade instancias; cuando baja, las reduce. Así, el equipo no tiene que calcular a mano el tamaño de la flota ni el límite de concurrencia.

La tarificación se basa en el modelo Active CPU: Fluid compute solo factura el tiempo en que el código del servicio se está ejecutando realmente, no toda la vida de la instancia. En la práctica, un servidor inactivo, bloqueado en una consulta lenta a la base de datos, no le cuesta al equipo más que uno que trabaja a pleno rendimiento.

Qué significa

La función Dockerfile.vercel difumina la frontera entre plataformas serverless como Vercel y las nubes de contenedores clásicas. Ahora cualquier servicio en Java, PHP o Ruby puede desplegarse sin configurar un registro de imágenes propio, un daemon ni un clúster, y con autoescalado y despliegues de preview por defecto.

Preguntas frecuentes

¿Qué requisitos debe cumplir el servidor para el despliegue?

La única condición es que el servidor escuche HTTP en el puerto definido en la variable de entorno $PORT (80 por defecto). Si el servicio responde a peticiones HTTP, se puede empaquetar en un Dockerfile.vercel y desplegar.

¿Qué ocurre con cada commit?

Cada git push reconstruye la imagen y crea una URL de preview independiente, que se puede abrir, compartir o usar para volver a una versión anterior del proyecto.

¿Con qué frameworks funciona?

Rails, Spring Boot, Express, Laravel, ASP.NET, FastAPI y servicios detrás de nginx. El ejemplo del blog de Vercel combina golang:1.24-alpine y alpine:3.20 en una construcción de dos etapas.