Vercel Daemons: corre workers sin servidor HTTP

Vercel Daemons ya está en beta pública

Vercel abrió la beta pública de Daemons, una primitiva que permite correr procesos de larga duración que consumen trabajo de colas, bases de datos o sistemas de terceros sin necesidad de exponer un servidor HTTP. Para un founder técnico, esto resuelve un problema que hasta ahora obligaba a mantener un servicio aparte: los workers de fondo.

El anuncio llega desde el propio changelog de la compañía, que describe Daemons como contenedores que corren sobre Fluid compute y se despliegan junto a la aplicación, en el mismo proyecto. Vercel construye la imagen y mantiene la cantidad de instancias que configures en cada región, reiniciando las que salen o se caen.

¿Qué se puede correr con Vercel Daemons?

La lista de casos de uso que publica Vercel es concreta y cubre buena parte del trabajo asíncrono que hoy vive fuera del frontend:

• Consumidores de colas: modo poll de Vercel Queues, además de Celery, BullMQ, RabbitMQ y Kafka.
• Workers de orquestación: procesos de Temporal o Cadence que hacen long-polling a sus colas de tareas.
• Runners de CI autoalojados: para GitHub Actions, GitLab o CircleCI, que consultan trabajos sin requerir conexiones entrantes.

El patrón común es el mismo: procesos que viven esperando trabajo y lo ejecutan cuando aparece. Ese patrón es incómodo en un modelo puramente request-response, porque no hay una petición HTTP que dispare la ejecución.

Cómo se configura en la práctica

La puesta en marcha es deliberadamente simple. Empaquetas tu aplicación y sus dependencias en un Dockerfile o Containerfile, y agregas una entrada daemons a un archivo de configuración en la raíz del proyecto.

El ejemplo que da Vercel usa worker/Dockerfile para levantar un worker de Celery en iad1 (Washington, D.C.), con un entrypoint, un command y un número de réplicas por región. Después defines las credenciales de conexión que necesite el worker en las variables de entorno de producción y despliegas. Las instancias arrancan solas y su salida aparece en los Logs del proyecto.

Un detalle que suele pasarse por alto: las métricas de CPU y memoria no vienen incluidas de fábrica. Están disponibles con Observability Plus, el producto de observabilidad de pago de Vercel. Si tu operación depende de vigilar el consumo de los workers, ese costo entra en la ecuación.

¿Qué significa esto para tu startup?

Hasta ahora, el camino típico para un equipo que tenía el frontend en Vercel era sacar los workers a otro proveedor: un contenedor en AWS, un servicio en Railway o Fly.io, o directamente un VPS. Eso implicaba dos pipelines de deploy, dos sistemas de secretos y dos lugares donde mirar cuando algo fallaba a las 3 de la mañana.

Daemons apunta exactamente a ese dolor: un solo proyecto, un solo deploy, un solo panel de logs. Para equipos chicos —donde no hay un equipo de plataforma dedicado— reducir la superficie operativa vale más que ahorrar unos dólares de cómputo.

Dos acciones concretas que puedes tomar esta semana:

• Audita tus procesos de fondo. Haz una lista de todo lo que hoy corre fuera de tu app principal: cron jobs, consumidores de cola, workers de email, sincronizaciones. Si alguno es un poller sin servidor HTTP, es candidato directo a probar en la beta.
• Prueba con un worker no crítico. Migra primero un proceso de bajo riesgo (por ejemplo, el envío de emails transaccionales o una sincronización nocturna) y mide latencia, costo y comportamiento ante reinicios antes de mover nada que toque dinero o datos de clientes.

El contexto: Fluid compute es la base

Daemons no aparece de la nada. Corre sobre Fluid compute, el modelo de cómputo que Vercel presentó en 2025 y que InfoQ describió como una alternativa al serverless tradicional: en lugar de reservar una microVM completa por request, Fluid permite que una misma instancia atienda múltiples peticiones concurrentes, priorizando recursos ya existentes antes de crear nuevos.

Según InfoQ, ese modelo se apoya en un esquema de precios pay-as-you-go y las funciones se facturan por GB-hora, en función de la memoria asignada y la duración de la ejecución. El CTO de Vercel, Malte Ubl, explicó a InfoQ que la diferencia central con el serverless clásico está en cómo se aprovecha la microVM: como la mayoría de las cargas pasan tiempo esperando I/O, compartir la instancia entre requests concurrentes resulta más eficiente.

Esa eficiencia es justamente lo que hace viable un worker que pasa horas esperando trabajo: si pagaras por una instancia dedicada y ociosa, el costo sería difícil de justificar.

Los límites que conviene tener claros

La beta pública no es lo mismo que disponibilidad general. Antes de mover cargas críticas, conviene verificar tres cosas en la documentación de Vercel: el comportamiento exacto ante reinicios de instancias, los límites de réplicas por región y cómo se factura el tiempo de cómputo de un proceso que está esperando trabajo en lugar de ejecutándolo.

También vale preguntarse por el acoplamiento. Mover los workers a Vercel simplifica la operación, pero profundiza la dependencia de un solo proveedor. Si tu arquitectura ya vive en Vercel, el trade-off es razonable. Si no, conviene evaluarlo como una decisión de plataforma y no solo como una comodidad de deploy.

Conclusión

Vercel Daemons cierra un hueco que la plataforma arrastraba desde hace años: el trabajo asíncrono. Con la beta pública, un equipo puede correr consumidores de colas, workers de orquestación y runners de CI dentro del mismo proyecto donde vive su aplicación, sin montar un servidor HTTP solo para mantener un proceso vivo.

Para startups con equipos pequeños, la ganancia no está en el precio por GB-hora sino en la reducción de piezas móviles. Menos pipelines, menos secretos duplicados, menos lugares donde buscar cuando algo se rompe. Ese ahorro operativo es, casi siempre, el que termina importando.

Fuentes

• Vercel Daemons is now in public beta
• Vercel Fluid: a New Compute Model and an Alternative to Serverless?