Cursor Cloud Agents ya puede ejecutar herramientas en infraestructura controlada por el cliente usando Cloudflare, Self-Hosted Machines y una plantilla oficial de Workers.
Esa frase necesita una precisión importante: esto no significa que Cursor se haya vuelto completamente self-hosted.
Significa algo más interesante para equipos enterprise.
Cursor sigue ejecutando el loop del agente, la inferencia, la planificación, la orquestación y la experiencia del producto. Cloudflare ejecuta la parte que normalmente incomoda a plataforma y seguridad: comandos, ediciones de archivos, operaciones sobre repositorios, builds, acciones de navegador y herramientas locales dentro de infraestructura controlada por el cliente.
Esa es la noticia real.
Durante el último año, buena parte de la conversación sobre agentes de código se quedó atrapada en modelos, integraciones con IDEs, benchmarks y si los agentes ya son “suficientemente buenos” para confiar en ellos. La pregunta enterprise más duradera es otra:
¿Dónde se ejecuta realmente el agente?
El changelog de Cloudflare del 2 de septiembre de 2026 le da una arquitectura concreta a esa pregunta.
¿Qué publicó Cloudflare para Cursor Cloud Agents?
Cloudflare publicó una ruta oficial para ejecutar Cursor Cloud Agents mediante Cursor Self-Hosted Machines sobre Cloudflare Containers.
El tutorial de Cloudflare Sandbox describe una plantilla desplegable basada en Workers, Durable Objects, Cloudflare Containers, R2 y un cron trigger. La plantilla pública vive en anysphere/cloudflare-workers, y eso importa porque no estamos ante un anuncio de partnership sin artefacto ni una promesa de roadmap.
El despliegue documentado crea:
- Un Cloudflare Worker como controlador.
- Un namespace de Durable Objects.
- Una aplicación de Cloudflare Containers.
- Un binding de R2 para snapshots opcionales de repositorios.
- Un cron trigger que revisa sesiones pendientes de Cursor.
Cada sesión asignada de Cursor corre en su propio Cloudflare Container aislado. Cursor sigue siendo responsable de la sesión de Cloud Agent y de la orquestación. El contenedor abre una conexión saliente hacia Cursor y ejecuta las tool calls que Cursor envía por esa conexión.
Ese modelo solo saliente es importante. El worker no necesita un puerto entrante ni una IP pública para que Cursor entre al entorno del cliente.
¿Cómo funciona Cursor Cloud Agents en Cloudflare?
El patrón separa orquestación de ejecución.
Un usuario inicia un Cursor Cloud Agent y selecciona un team pool self-hosted. Cursor registra una solicitud pendiente para ese pool. El Worker de Cloudflare actúa como controlador: en cada ejecución programada, lista solicitudes pendientes para el pool configurado, mantiene abierto un stream de eventos server-sent durante la ventana del controlador, reclama sesiones y arranca un contenedor por cada solicitud reclamada.
Para agentes ligados a un repositorio, la solicitud incluye la URL del repositorio. El contenedor restaura o clona ese repositorio en $HOME/workspaces/repo-0 y después inicia el worker de Cursor desde ese directorio.
La documentación de Cloudflare muestra este comando:
agent worker --worker-dir "$HOME/workspaces/repo-0" --pool "$CURSOR_POOL" start --verbose
Para agentes any-repository, la sesión se enruta por nombre de team pool. El contenedor arranca con un directorio de trabajo vacío y sin remoto de Git. El agente, o un hook del proyecto, puede clonar lo que necesite durante la sesión.
R2 funciona como caché opcional, no como el centro del sistema. Los snapshots de repositorios pueden acelerar sesiones repo-bound, pero un cache miss cae a un git clone normal y no impide que el agente arranque.
Este es un patrón práctico de runtime: Cursor decide qué intenta hacer el agente; Cloudflare le da un lugar controlado para hacerlo.
¿Qué se queda en Cursor y qué se mueve al cliente?
Cursor conserva el loop del agente, la inferencia, la planificación, el acceso al modelo, el dashboard de Cloud Agents y la orquestación visible para el usuario.
El worker controlado por el cliente ejecuta las tool calls.
Eso incluye comandos de terminal, ediciones de archivos, acciones de navegador, operaciones sobre repositorios, hooks, herramientas MCP locales cuando estén disponibles, acceso a sistemas de build, acceso a package registries y acceso a servicios internos que el worker pueda alcanzar.
Esta distinción importa porque “self-hosted” es una palabra demasiado cargada.
Si tu política exige que todas las partes del agente, incluyendo planificación e inferencia, corran dentro de tu propio perímetro, este patrón no cumple ese requisito. Cursor sigue en el loop.
Si tu política exige que los checkouts de código fuente, la ejecución de comandos, los artefactos de build, los logs de herramientas y el acceso a red interna permanezcan dentro de infraestructura controlada por la empresa, entonces este patrón sí es relevante.
No es una nube privada de Cursor.
Es una arquitectura híbrida de ejecución.
Y aun así, esa línea es muy significativa.
¿Por qué esto importa para CTOs y CIOs?
Porque adoptar agentes en organizaciones serias de ingeniería ya no es solo una pregunta sobre calidad de código.
Es una pregunta sobre modelo operativo.
Un agente que solo sugiere autocompletado representa un tipo de riesgo. Un agente cloud que clona repositorios privados, instala dependencias, corre tests, toca servicios internos, edita archivos, produce artefactos y comenta PRs representa otro.
Las preguntas de gobierno aparecen rápido:
- ¿Dónde vive el checkout del repositorio?
- ¿Dónde viven los outputs de build y las cachés?
- ¿Qué servicios internos puede alcanzar el worker?
- ¿Qué secretos están disponibles para el runtime del agente?
- ¿Quién controla la imagen del worker?
- ¿Quién escala la capacidad?
- ¿Qué pasa cuando un rollout de contenedor interrumpe una sesión activa?
- ¿Dónde se retienen los logs del worker?
- ¿Qué artefactos salen del entorno y aparecen en dashboards de Cursor o en PRs?
La plantilla de Cloudflare no responde todo por ti. La propia documentación de Cursor es clara: las arquitecturas de referencia no son plataformas administradas de producción. El cliente es dueño de la imagen del worker, la infraestructura, los secretos, la política de escalado y la validación productiva.
Pero la plantilla convierte esas preguntas en decisiones operables, no en debate abstracto.
Eso ya es avance.
¿Por qué Cloudflare encaja como runtime para agentes?
Cloudflare no es el único lugar donde puedes ejecutar Cursor Self-Hosted Machines. La documentación de Cursor menciona máquinas personales, hosts persistentes, contenedores, infraestructura dinámica, Kubernetes, Cloud Run y plantillas de partners como AWS Lambda, Cloudflare, Namespace, Modal, Daytona, E2B, Vercel y Coder.
La ruta de Cloudflare es interesante porque el controlador también es un Worker.
No necesitas mantener un servicio tradicional de larga duración solo para mirar si hay sesiones pendientes. El cron trigger corre cada cinco minutos. Durante una ejecución del controlador, el Worker lista solicitudes pendientes, mantiene abierto el stream de eventos de Cursor hasta la siguiente ejecución programada, reclama sesiones y arranca contenedores aislados mediante un Durable Object.
El resultado es un controlador de pool con sabor serverless para ejecución agéntica.
Eso no elimina la complejidad. La mueve a lugares que los equipos de plataforma pueden razonar: wrangler.jsonc, secretos de Workers, Durable Objects, límites de contenedores, snapshots en R2, rollouts de imágenes, logs y política de red saliente.
Para equipos que ya usan Cloudflare como parte de su borde, seguridad o plataforma de desarrollo, ese plano de control resulta familiar.
También conecta bien con una línea que yoDEV ya viene siguiendo: Cloudflare no solo está exponiendo servicios de infraestructura, también está convirtiendo piezas como Browser Run en bloques programables para workflows de desarrollo. Esa lectura aparece en nuestro análisis de Cloudflare Browser Run.
¿Qué requisitos tiene Cursor Cloud Agents en Cloudflare?
Al momento de publicar esta nota, el 3 de septiembre de 2026, esto no es una receta casual para usuarios individuales.
El tutorial de Cloudflare requiere:
- Un plan Cursor Enterprise con Self-Hosted Machines habilitado.
- Una API key de cuenta de servicio de Cursor con scope de agente.
- Una cuenta Cloudflare Workers Paid con acceso a Containers y R2.
- Node.js 20 o posterior.
- Un daemon de Docker activo para despliegue y desarrollo local.
El setup también espera Wrangler, un team pool de Cursor, un CURSOR_POOL configurado y secretos de Worker como CURSOR_API_KEY. Si los agentes necesitan repositorios privados, la documentación de Cloudflare muestra GIT_USERNAME y GIT_TOKEN como secretos de Worker; para GitHub, GIT_USERNAME debe ser x-access-token.
La concurrencia también es explícita. El despliegue usa containers[].max_instances, y Cloudflare indica que debe ajustarse al máximo de solicitudes concurrentes que el despliegue necesita soportar.
Eso es una decisión de capacidad, no un checkbox.
Hay otro detalle operativo: Cloudflare advierte que un rollout de nueva imagen de contenedor detiene contenedores en ejecución. Si los agentes están trabajando en tareas largas, los despliegues necesitan la misma disciplina de cambio que aplicarías a workers de CI o automatización productiva.
¿Qué debería mirar un equipo de seguridad?
El punto de seguridad más importante es casi aburrido, que suele ser señal de que es real.
Ejecutar el worker dentro de tu infraestructura no vuelve seguro al agente por defecto.
Vuelve más clara la frontera.
El worker puede quedar más cerca de repositorios privados, package registries, APIs de staging, secretos de build, bases de datos de prueba, dashboards internos o sistemas heredados. Esa es exactamente la razón por la que esta arquitectura es útil. También es la razón por la que el modelo de permisos importa.
Una prueba seria debería decidir:
- Qué repositorios puede clonar el worker.
- Qué tokens recibe.
- A qué package registries puede acceder.
- Qué hosts internos puede alcanzar.
- Qué hooks corren antes o durante el trabajo del agente.
- Qué artefactos pueden subirse de vuelta a Cursor.
- Qué logs permanecen en Cloudflare.
- Qué pools corresponden a qué niveles de riesgo, equipos, repositorios o entornos.
Los Team Pools de Cursor ayudan en este punto porque funcionan como targets de enrutamiento. Un pool puede representar un equipo, un grupo de repositorios, una clase de hardware, un entorno de staging o un nivel de riesgo. La documentación de Cursor describe labels para enrutar trabajo, y los administradores pueden permitir que usuarios opten por ejecuciones self-hosted o exigir que las ejecuciones de Cloud Agent vayan a workers self-hosted.
Ahí esto deja de ser plomería de despliegue y se vuelve arquitectura de gobierno.
¿Qué debería probar una empresa antes de adoptarlo?
Una prueba útil no debería empezar con una app de juguete.
Debería empezar con un workflow pequeño, real y dentro de un entorno limitado.
Por ejemplo:
- Un repositorio privado con bajo radio de impacto.
- Un team pool dedicado de Cursor.
- Un despliegue de Cloudflare con
max_instancesconservador. - Una service-account key con alcance para autenticar pool workers.
- Credenciales de Git mínimas para el repositorio de prueba.
- Una imagen de contenedor con solo las herramientas necesarias para el workflow.
- Un camino de build o test que toque una dependencia interna.
- Logs revisados por plataforma y seguridad.
- Un rollout de imagen planificado después de que terminen las sesiones activas.
La condición de éxito no es “el agente hizo un cambio”.
La condición de éxito es que el equipo entienda qué pasa cuando algo falla: falta de capacidad, credenciales de Git incorrectas, secretos ausentes, clones fríos, cache miss en R2, instalación rota de herramientas, rollouts interrumpidos y conectividad saliente fallida.
La infraestructura de agentes es infraestructura. Merece pruebas de falla.
¿Cuál es la señal más grande?
La señal más grande es que los agentes de código se están convirtiendo en arquitectura de runtime.
Para desarrolladores individuales, la pregunta suele sentirse como “qué IDE tiene el mejor agente”. Si necesitas ese marco más básico, yoDEV ya tiene una introducción a qué es Cursor y por qué importa, además de una comparación práctica de Cursor vs VS Code.
Para equipos enterprise, la pregunta se está volviendo otra: dónde se ejecuta el trabajo del agente y bajo qué controles.
Cloudflare y Cursor muestran una respuesta plausible: mantener la experiencia comercial del agente, pero mover la superficie de ejecución a infraestructura controlada por el cliente.
No es independencia local-first. No es un reemplazo open source de Cursor. No es una solución universal de compliance.
Es una capa intermedia pragmática.
Y la adopción enterprise de software suele ocurrir precisamente en ese tipo de capa intermedia: no cloud puro, no self-hosted puro, sino una frontera que permite a plataforma, seguridad e ingeniería decir que sí sin fingir que el riesgo desapareció.
¿Por qué importa ahora?
La próxima fase de los agentes de código no se va a decidir solo por calidad de modelo.
Se va a decidir por fronteras de ejecución.
Los equipos que adopten agentes en profundidad necesitarán respuestas sobre ubicación del código fuente, ejecución de comandos, alcance de red, secretos, logs, artefactos, imágenes de workers y auditoría. La plantilla de Cloudflare para Cursor es uno de los ejemplos públicos más claros de esa arquitectura volviéndose real.
La pregunta ya no es solo si un agente puede escribir código útil.
La pregunta es qué parte del agente estás dispuesto a ejecutar dónde.