Vercel añade workers permanentes y Python estable en su plataforma

Vercel ha aprovechado su conferencia Ship en San Francisco para ampliar el terreno donde quiere competir: el backend. La compañía ha presentado Daemons, un servicio para ejecutar workers de fondo de forma continua, ha declarado disponible de forma general su soporte de Python y ha hecho lo mismo con Drives, su almacenamiento persistente pensado para agentes de IA. Para una pyme que ya tiene parte de su stack en la plataforma, la noticia no es menor: deja de ser solo un sitio donde alojar el frontend y empieza a cubrir más piezas del sistema.

Qué son los Daemons y por qué importan

Daemons, en beta pública, permite desplegar un contenedor e indicar cuántas instancias deben ejecutarse en cada región. Vercel se encarga de mantener esos procesos vivos y de reiniciarlos si terminan o fallan. En su primera versión soporta cargas de trabajo basadas en pull: el worker consulta una cola o base de datos, recoge el trabajo y lo procesa según llega.

El CTO de la compañía, Malte Ubl, explica que la plataforma ya cubría tareas disparadas por peticiones con sus colas, sus durable workflows y su función Services, que permite desplegar frontend y backend juntos. Lo que faltaba era el trabajo que no encaja en ese patrón: procesamiento pesado sobre una cola. El propio pipeline de despliegues de Vercel es el ejemplo que pone Ubl: cuando se llama a su API para hacer un despliegue, ese despliegue no se ejecuta en el proceso que atiende la petición, porque no se pueden lanzar infinitos despliegues concurrentes. Los límites de GitHub son una razón para moderar el ritmo, y las primitivas de cómputo anteriores no daban buen control sobre la concurrencia de ese tipo de worker.

El caso de uso que ilustra la compañía combina un frontend en Next.js con una API en Python y un procesador de vídeo en contenedor. Ese contenedor empaqueta dependencias de Python y FFmpeg, y va recogiendo trabajos de Vercel Queues para generar ficheros de reproducción y miniaturas. Es transcodificación, una carga intensiva en CPU donde lo que se necesita es una máquina que esté siempre al 100%. Los Daemons quedan así en el extremo opuesto a los sandboxes de Vercel: no son efímeros ni los invoca una petición desde internet, sino que salen a buscar trabajo.

Runtime gestionado o contenedor: el debate de fondo

La llegada de Daemons obliga a plantearse cómo se empaqueta el código. Vercel afirma que 5.000 equipos han hecho 150.000 despliegues de contenedores desde que el soporte entró en beta pública. Los contenedores permiten llevar la aplicación con su propio runtime y sus librerías de sistema, lo que amplía el catálogo de software desplegable. El precio es quién mantiene la imagen al día.

Con un runtime gestionado para Node, Bun o Python, Vercel aplica los parches de seguridad sin que el cliente tenga que redesplegar, según Ubl. Con un contenedor, hay que volver a desplegar y la responsabilidad es del cliente: desde el punto de vista de la plataforma, son solo bytes. Es un matiz que en una pyme con equipo de IT pequeño marca la diferencia entre una carga operativa asumible y una que se acumula.

En paralelo, el soporte de Python ya es estable para frameworks como FastAPI, Flask y Django. Las aplicaciones corren sobre CPython estándar con dependencias de PyPI, y Vercel se encarga de la detección del framework, la compilación y el escalado. La compañía asegura que 150.000 equipos ya ejecutan backends en Python en su plataforma.

Drives: almacenamiento para agentes que sobrevive al sandbox

Vercel Drives separa los ficheros de un agente del sandbox que ejecuta su código. El agente puede montar el drive en un sandbox nuevo, cambiar de runtime y seguir trabajando con los ficheros que ya había creado. Ubl lo describe como un híbrido entre un disco de red tipo EBS y el almacenamiento de objetos: las escrituras caen en disco NVMe local y se envían de forma asíncrona al almacenamiento de objetos, mientras que las lecturas salen del disco local si el dato ya está ahí o se traen por bloques.

La comparación con los snapshots es deliberada. Ubl sostiene que los snapshots crecen mucho porque acaban capturando cosas que son iguales en cada ejecución, mientras que los drives, al ser ficheros en S3, resultan baratos de operar en grandes cantidades. Es una discusión que seguirá abierta, pero apunta a una tendencia clara: los agentes están cambiando los requisitos del almacenamiento de backend.

Qué significa para una pyme y qué recomendamos

Para un equipo de IT con recursos limitados, la lectura práctica es que Vercel amplía su catálogo hacia cargas que antes obligaban a montar infraestructura aparte. Eso puede simplificar la operación, pero también concentra más dependencia en un proveedor. Antes de lanzarse, conviene revisar estos puntos:

• Clasifica tus cargas. Separa lo que responde a peticiones de lo que procesa colas: generación de informes, transcodificación, sincronizaciones. Solo lo segundo encaja en Daemons.
• Decide runtime gestionado o contenedor. Si eliges contenedor, asume el coste de redesplegar ante parches de seguridad. Si no tienes quién lo vigile, el runtime gestionado suele ser mejor opción.
• Prueba en beta con cargas no críticas. Daemons está en beta pública; no es el sitio para el proceso que factura cada noche.
• Mide la concurrencia. La ventaja de los workers de tipo pull es controlar cuántas instancias corren; aprovéchala para no pagar cómputo ocioso.
• Revisa el almacenamiento de agentes. Si estás montando flujos con IA, evalúa si Drives encaja mejor que los snapshots para los ficheros que deben persistir.

La noticia encaja con una tendencia que ya venimos viendo: los proveedores cloud quieren cubrir más capas del stack para que el cliente no salga de su plataforma. En el blog hemos analizado movimientos parecidos en el terreno de la IA y la seguridad, como el modelo agéntico de Nvidia para portátiles o el control de aplicaciones de vibe-coding con Cloudflare Void. La diferencia aquí es que Vercel no vende IA, sino el sustrato donde ejecutarla y donde correr el backend de siempre. Para una pyme, la pregunta útil no es si la plataforma es más potente, sino si el equipo puede asumir la operación que esa potencia implica. Nuestra recomendación: pilota Daemons con una carga real pero secundaria, documenta quién mantiene las imágenes si optas por contenedores y revisa el coste de salida antes de mover procesos críticos.

Fuente: The New Stack. Análisis y adaptación: ForgeNEX.