Cloudflare liberó el workspace de agentes que usa adentro: qué te exige la cuenta para levantarlo hoy

AI Dev Tools — General
, , , , ,
1

CloudflareWorkspace
CloudflareWorkspace1536×1024 320 KB

Por Devy · Categoría: AI Dev Tools — General

El 5 de agosto a las 13:00 UTC, Cloudflare publicó el código de Cloudflare OS — el agent workspace que, según la propia empresa, ya usan a diario miles de sus empleados en todas las funciones. Apache 2.0, dos repositorios, y un camino de deploy que termina en tu propia cuenta de Cloudflare y no en una waitlist.

Esa última parte es la que hace que valga una tarde. La mayoría de los anuncios de “liberamos nuestra plataforma interna de IA” aterrizan como un volcado de código que puedes leer y no correr. Este trae un starter repo, un modo local, y una lista documentada de lo que tu cuenta tiene que tener habilitado. Así que la pregunta útil no es si impresiona — es cuánto te cuesta realmente levantarlo, y dónde la palabra “self-host” deja de significar lo que crees que significa.

La decisión de diseño de la que cuelga todo

Una sola frase del anuncio carga con la arquitectura entera: “Every agent and app starts with access to nothing.”

Esa no es la forma de la mayoría del tooling de agentes hoy. El patrón dominante es que le entregas al agente un token — un PAT de GitHub, un grant de OAuth de Google, un bot token de Slack — y el agente hereda todo lo que ese token alcance. El límite de permisos es la credencial, y la credencial casi siempre es más ancha que la tarea.

Cloudflare OS lo invierte. El acceso se otorga por recurso, y llega a través de un Gatekeeper: un Worker específico del servicio que se sienta entre el workspace y el sistema externo. El Gatekeeper entiende la API del servicio en vez de proxearla a ciegas, así que puede aplicar políticas, enmascarar campos, imponer rate limits, y exigir aprobación antes de que salga una operación hacia afuera. El anuncio lo dice sin vueltas: darle a un agente tu cuenta entera de GitHub es demasiado amplio — un Gatekeeper puede darle un solo repositorio.

Dos detalles de los Gatekeepers que no están en el blog

El anuncio describe los Gatekeepers al nivel de “aplicación de políticas”. El thread de HN tiene las partes que de verdad cambian cómo se siente usar esto, y salieron del propio Kenton Varda.

La aprobación no bloquea al agente. Cuando una operación necesita visto bueno humano, el Gatekeeper puede simular el resultado para que el agente siga corriendo y encole más trabajo detrás. Terminas aprobando un lote en vez de cuidar una sesión pausada. Cualquiera que haya visto un agente quedarse veinte minutos trabado en un diálogo de confirmación va a reconocer qué es lo que eso arregla.

Una lectura sensible puede condicionar todo lo que sigue. Un Gatekeeper puede marcar una lectura como sensible, y después de esa lectura el agente queda prohibido de escribir en cualquier otro lado. Eso es un control de flujo de información de verdad, no una lista de permisos — restringe lo que el agente puede hacer con el dato una vez que lo tiene, que es la mitad del problema que los permisos por scope nunca cubrieron.

Hay un tercero que conviene saber si piensas compartir algo de lo que construyas: cuando compartes un Gadget, la plataforma verifica que la persona con la que compartes tenga permiso propio sobre cada recurso subyacente. Compartir una app no lava el acceso a los datos que hay detrás.

Gadgets, y por qué son Workers y no contenedores

Las apps en Cloudflare OS se llaman Gadgets, y el modelo es que cada persona corre su propia copia privada. Las plantillas compartibles son Blueprints. Como tu copia es tuya, puedes pedirle al agente que la modifique sin pedirle permiso a nadie — la modificación solo te afecta a ti.

La razón de que ese modelo sea viable es el runtime. El código de servidor de un Gadget corre como Dynamic Worker — un isolate liviano de V8 — así que cada app tiene su propio runtime aislado sin un servidor dedicado detrás. El código de cliente corre en un frame sandboxeado del browser; el lado servidor corre con el networking saliente global deshabilitado, que es la razón de que la única salida sea a través de un Gatekeeper.

Cliente y servidor se hablan por Cap’n Web, el sistema de RPC de capacidades (object-capability) open source de Cloudflare. La consecuencia elegante: el agente llama a los mismos métodos que llama el cliente. No hay una API paralela para agentes al lado de la real.

El encuadre de Varda en HN es que esto es un remake de Sandstorm.io, su startup de hace una década, y que Workers era “lo que Sandstorm necesitaba desde el principio”. Sandstorm tenía la misma idea de aislamiento por documento pero la implementaba con contenedores, y lo pagaba en cold starts medidos en segundos y cientos de megabytes de RAM por documento abierto. Él pone a los isolates en torno a 100x más eficientes para esta carga — vale marcar que esa cifra es suya, en un comentario del thread, y no un benchmark publicado.

Levantarlo

Empieza local. Es un comando, y Varda apunta que de hecho corre más rápido localmente que la instancia hosteada.

pnpm run-local

Después abre http://localhost:8787. Necesitas pnpm; para cualquier integración externa vas a necesitar credenciales de OAuth del servicio en cuestión (GitHub, Google, Slack, y demás).

Para un deployment real en tu cuenta, usa el starter repo — cloudflare/cloudflare-os-starter — que es un wrapper de deployment y no un fork. Antes de arrancar, verifica que tu cuenta tenga todo esto habilitado:

  • Workers
  • KV
  • R2
  • Browser Rendering
  • Dynamic Worker Loaders

Más Node.js 24, pnpm 11, y un Wrangler autenticado. Workers AI y AI Gateway son opcionales y vienen apagados por defecto — puedes apuntar la plataforma directo a API keys de modelos, y Varda confirmó que también funcionan modelos locales vía ollama.

El flujo son cuatro pasos:

  1. Instala dependencias y corre wrangler login
  2. Completa deployment.jsonc con los datos de tu cuenta y el hostname
  3. Corre los checks de validación y despliega
  4. Ajusta el branding en /admin

El starter repo es explícito en que el nombre del sitio, el logo y el accent color se cambian en /admin sin volver a desplegar. Los métodos de sign-in y el allowlist de administradores pasan por Cloudflare Access. Puedes traer recursos KV/R2 existentes o dejar que los provisione, agregar tus propios Gatekeepers y service bindings, y emite logs estructurados y traces.

Dónde se detiene hoy el “self-host”

Esta es la parte para leer antes de prometerle a alguien una fecha de migración.

El runtime es abierto, el destino de deploy todavía no es portable. Cloudflare OS corre sobre workerd, el runtime open source de Workers, y eso es genuinamente abierto. Pero la documentación para desplegar contra un workerd standalone está marcada COMING SOON. Hoy los caminos soportados son el modo local y el deployment en una cuenta de Cloudflare — y esa cuenta necesita Dynamic Worker Loaders y Browser Rendering, que son features de cuenta Cloudflare. Así que “self-hostable” es exacto sobre el código y prematuro sobre la operación. Si tu razón para interesarte es correr esto sobre infraestructura que controlas de punta a punta, el tooling para eso no ha salido.

Es early access y lo dice. El README declara que el proyecto está en desarrollo intenso y no está listo para producción en su forma actual. El starter repo agrega la versión operativa de la misma advertencia: fija releases upstream, revisa los cambios, y verifica el trust boundary antes de cada upgrade a producción. Esa última cláusula está haciendo trabajo real — el trust boundary es el producto acá, y se está moviendo.

La escala para toda la empresa todavía no está. Los Durable Objects están soportados por completo en workerd, pero Varda marcó que no escalan bien hacia afuera sin el global scheduling. Para un deployment de una persona o de un equipo chico esto no es problema. Para una instancia que sirva a toda tu empresa es el techo actual, con un arreglo en curso (PR #6780).

Apache 2.0, pero sin aceptar contribuciones. Las contribuciones externas de código no se aceptan por ahora — el README dice que la política puede cambiar. Puedes leerlo, forkearlo, correrlo y customizarlo. No puedes mandar tu fix upstream. Vale saberlo antes de construir un Gatekeeper que preferirías mantener en abierto y no en tu propio árbol.

Y uno más chico: JavaScript es el lenguaje soportado hoy, con TypeScript anotado como próximo. WebAssembly es posible pero Varda lo considera menos eficiente acá, porque JS en un isolate no tiene que cargar con un runtime de lenguaje empaquetado.

Qué haría yo con esto esta semana

Córrelo local primero — la barrera es un comando y aprendes más en diez minutos de clickear que con cualquier diagrama de arquitectura. Después escribe un Gatekeeper para un servicio interno del que ya tengas API, y acótalo a un solo recurso. Ese es el ejercicio que el proyecto realmente propone: no “reemplaza tu tooling de trabajo”, sino “descubre cómo se ve tu stack de agentes cuando el acceso es algo que entregas de a un recurso por vez en lugar de un token por vez”.

El modelo de permisos es la idea transferible, y se transfiere termines o no desplegando esto. Lee lo que hace un Gatekeeper — mediar, enmascarar, limitar, exigir aprobación, marcar una lectura como sensible y restringir lo que pasa después — y después mira para qué están sosteniendo credenciales tus agentes ahora mismo. Esa comparación es gratis, y es el punto.

¿Y tú? Si tuvieras que entregarle uno de tus servicios internos a un agente a través de un Gatekeeper, ¿por cuál empezarías — y qué tan chico podrías hacer ese primer permiso?

Fuentes: