Vercel abre el backend: Python GA, contenedores y Daemons

Vercel quiere quedarse con tu backend, no solo con tu frontend

150.000 equipos ya ejecutan backends en Python sobre Vercel, según la propia compañía. La cifra la dio a conocer en Vercel Ship, su evento en San Francisco, donde anunció tres movimientos que apuntan al mismo objetivo: que dejes de mantener dos plataformas separadas para tu producto.

Python pasa a disponibilidad general, los contenedores permiten desplegar aplicaciones en cualquier lenguaje con sus librerías de sistema, y llegan los Vercel Daemons en beta pública para workers que corren de forma continua en segundo plano.

Para un equipo pequeño, la pregunta ya no es si Vercel sirve para el frontend. Es si tiene sentido seguir pagando y operando un backend aparte.

Qué anunció Vercel en su evento Ship

Los tres anuncios se complementan entre sí y conviene leerlos como un solo paquete:

• Python en disponibilidad general. Ya puedes construir tu backend en Python con la misma experiencia de desarrollo que usas en el frontend: desarrollo local, previews y despliegues a producción.
• Contenedores en Vercel Functions. Permiten runtimes personalizados y librerías de sistema que antes no entraban en el modelo de funciones.
• Vercel Daemons en beta pública. Contenedores que funcionan como workers de fondo, con capacidad mantenida por Vercel y trabajo de tipo pull.

El patrón es claro: Vercel deja de ser una plataforma de despliegue de frontend y se posiciona como una plataforma de aplicación completa.

Python deja de ser beta: qué cambia para tu equipo

El soporte cubre frameworks como FastAPI, Flask y Django sobre CPython estándar con tus dependencias de PyPI. Vercel se encarga de la detección del framework, los builds y el escalado, así que no tienes que escribir configuración de infraestructura para arrancar.

Además de ejecutar el backend, hay SDKs de Python para usar los productos de la plataforma desde tu propia aplicación: Vercel Blob para archivos, Vercel Queues para trabajos en segundo plano, Vercel Workflows para pasos durables, Vercel Sandbox para ejecutar código no confiable y el AI SDK para Python para streaming de respuestas de modelos y manejo de tool calls.

El caso que la compañía usa como ejemplo es Delphi, que construye "mentes digitales" de IA a partir de libros y charlas. El equipo migró su backend en Python desde AWS ECS a Vercel. Con diez ingenieros y sin un rol dedicado a infraestructura, despliegan a producción más de 100 veces al día y usan Queues para manejar trabajos en segundo plano.

"Con Vercel, apenas pensamos en la infraestructura", resume Spencer Schoeben, founding engineer de Delphi.

Ese es el argumento real del anuncio: no es que Vercel sea más barato que AWS, es que elimina la necesidad de tener a alguien dedicado a operar la infraestructura.

Contenedores: cualquier lenguaje, con las librerías del sistema que necesites

El runtime de contenedores permite desplegar aplicaciones escritas en cualquier lenguaje, empaquetadas con las librerías y ejecutables del sistema operativo que necesiten. Desde que el soporte entró en beta pública, 5.000 equipos han desplegado 150.000 contenedores en Vercel, según la compañía.

Los contenedores se despliegan como Vercel Functions sobre Fluid compute, escalan con el tráfico y usan el modelo de Active CPU pricing, que no cobra por el tiempo de inactividad mientras esperas respuestas de APIs, consultas a bases de datos o inferencia de LLMs. Ese detalle importa mucho si tu producto está construido alrededor de modelos de IA, donde la mayor parte del tiempo de ejecución es espera.

El resto del stack se mantiene: Vercel Services para desarrollar y desplegar backend y frontend juntos, el CDN para servir tráfico en tus dominios, el WAF para protegerlo, logs para investigar problemas y rollbacks para volver a un despliegue anterior.

El ejemplo que da la compañía es una app de video que usa un contenedor para procesamiento en segundo plano: preparar una copia de reproducción y una miniatura por cada clip subido. El Dockerfile empaqueta el procesador en Python, sus dependencias y ffmpeg en una sola imagen.

Conviene tener presente un matiz: según la guía de Vercel sobre conceptos de Docker Compose publicada en agosto de 2026, tanto Vercel Services como las imágenes de contenedor siguen en beta, aunque están disponibles en todos los planes.

Vercel Daemons: workers que no se apagan entre trabajos

Los Daemons son la pieza que faltaba. Permiten desplegar contenedores como workers de fondo que corren de forma continua sobre Fluid compute. Tú eliges cuántas instancias quieres en cada región y Vercel mantiene esa capacidad reiniciando los procesos cuando terminan o se caen.

El lanzamiento arranca con soporte para cargas de trabajo de tipo pull: tu código pide trabajo a otro sistema y lo procesa a medida que aparece. Eso puede significar consumir mensajes de una cola o buscar trabajos pendientes en una base de datos.

En el ejemplo de la app de video, el Daemon ejecuta el procesador de forma continua mientras extrae trabajos de Vercel Queues. La configuración se declara en vercel.toml: defines el frontend de Next.js, enrutas las peticiones hacia él y agregas el procesador usando un Dockerfile, con una instancia fija en la región iad1.

Vale la pena entender cómo se reparte el trabajo de fondo en la plataforma. Según la guía de Vercel sobre Docker Compose, un worker monolítico se descompone por tipo de tarea: Vercel Queues para trabajos procesados fuera de la ruta de la petición, Vercel Workflow para procesos durables de varios pasos que sobreviven a suspensiones, y Cron Jobs para trabajo programado. En el plan Hobby, los cron jobs están limitados a ejecuciones diarias.

Por qué Vercel puede hacer esto: Fluid compute

Todo lo anterior se apoya en Fluid, el modelo de cómputo que Vercel presentó en 2025. Según InfoQ, Fluid es un modelo de cómputo elástico que permite que un solo worker atienda múltiples peticiones, como un servidor tradicional, pero conservando la elasticidad del serverless. La clave es que escala funciones antes de crear instancias nuevas, aprovechando el cómputo ya caliente.

Malte Ubl, CTO de Vercel, explicó la diferencia de fondo: Lambda reserva la máquina virtual completa para atender una petición de principio a fin, mientras que Fluid puede usar una VM para múltiples peticiones concurrentes. Como la mayoría de las cargas pasan mucho tiempo inactivas esperando I/O, el resultado es más eficiente. El cobro se hace por GB-hora, según la memoria asignada y la duración de la ejecución.

Esa arquitectura es la que hace posible cobrar por CPU activa y no por tiempo de espera, y es también la que permite que un Daemon se mantenga vivo sin que pagues por un servidor ocioso.

Qué significa esto para tu startup

Si tu equipo tiene frontend en Vercel y backend en otro proveedor, el costo de esa separación ya no es solo dinero: es tiempo de ingeniería, dos pipelines, dos sistemas de logs y dos lugares donde buscar cuando algo se rompe. El anuncio de Delphi es el escenario típico de una startup hispanohablante: equipo chico, sin SRE dedicado, que necesita velocidad de despliegue por encima de control fino de infraestructura.

Tres acciones concretas para evaluar esto en tu producto:

• Audita dónde vive tu backend hoy. Si tienes un servicio en Python corriendo en contenedores gestionados por tu equipo, calcula cuántas horas de ingeniería al mes se van en operarlo. Ese número es el que compites contra la propuesta de Vercel, no la factura de cómputo.
• Separa tus trabajos de fondo por tipo. Antes de migrar un worker monolítico, clasifica cada tarea: si es un trabajo puntual fuera de la ruta de la petición, va a Queues; si es un proceso de varios pasos que debe sobrevivir a interrupciones, va a Workflow; si es periódico, va a Cron. Los Daemons son para cargas de tipo pull que necesitan estar corriendo de forma continua.
• Revisa los límites antes de comprometerte. Según la guía de Vercel, no puedes correr contenedores con estado propio como Postgres o Redis con disco local, no hay soporte para contenedores privilegiados ni para montajes del sistema de archivos del host, y no existe orden de arranque entre servicios: cada servicio debe tolerar cualquier orden de inicio. El almacenamiento durable asociado a contenedores está anunciado pero todavía no se ha lanzado.

La lectura estratégica es que la frontera entre "plataforma de frontend" y "proveedor de nube" se está diluyendo. Para founders con equipos pequeños, eso reduce la cantidad de decisiones de infraestructura que hay que tomar antes de lanzar. Para equipos con cargas muy específicas, sigue siendo una plataforma con límites claros que conviene mapear antes de mover producción.

Fuentes

• Backends on Vercel: Python, containers, and Daemons
• Vercel Fluid: a New Compute Model and an Alternative to Serverless?
• How Docker Compose concepts map to Vercel