Cloudflare OS: el sistema operativo de IA para tu empresa

Cuando lanzas un agente con --dangerously-skip-permissions sabes perfectamente lo que estás haciendo.

Lo haces igual.

Lo haces porque la alternativa es peor: dejas la tarea corriendo, te vas a por un café y vuelves a los quince minutos para descubrir que el agente lleva catorce minutos y medio parado esperando a que le des al botón de “sí, puedes escribir ese fichero”. Así que aceptas el trato, cruzas los dedos y sigues.

Cloudflare acaba de abrir el código de un sistema que resuelve justo ese dilema con una idea que no había visto en ningún otro sitio: el agente no espera tu aprobación, la simula.

El 5 de agosto de 2026, dentro de su Agents Week, Cloudflare publicó cloudflare/cloudflare-os bajo licencia Apache-2.0. No es una demo ni un side project de un ingeniero aburrido: es la plataforma que, según el propio README, “una gran parte de la plantilla de Cloudflare — de ingeniería a ventas y todo lo que hay en medio — usa cada día para hacer su trabajo”. Y está construida por el equipo que construyó Workers.

En este post vas a ver:

• Por qué llaman “sistema operativo” a algo que no arranca ningún ordenador (y por qué la analogía se sostiene)
• Qué es un “gadget” y por qué es una enmienda a la totalidad al modelo SaaS
• Cómo funcionan los Gatekeepers y en qué se diferencian de un servidor MCP
• El truco de la aprobación asíncrona simulada, que es el hallazgo técnico más interesante del repo
• Qué puedes ejecutar hoy en tu máquina con dos comandos
• Lo que el README no te cuenta con letras grandes: contribuciones cerradas, OAuth doloroso y bordes sin pulir

¿Qué es Cloudflare OS y por qué lo llaman sistema operativo? ¶

Cloudflare OS es un espacio de trabajo con agentes de IA, autoalojable y open source, que le da a cada persona de una empresa un chat con contexto corporativo, un entorno para que la IA le construya aplicaciones pequeñas en un sandbox, y una capa de seguridad que evita que todo eso acabe en un incidente.

No arranca ninguna máquina. El nombre es deliberado y el README lo justifica en dos sentidos: es un sistema operativo para que la empresa sea productiva con IA de forma segura, y es un sistema operativo para cargas de trabajo de IA, igual que un sistema operativo tradicional gestiona cargas de trabajo de cómputo.

La analogía no es solo marketing. El propio repositorio la desglosa así:

Fíjate en la última fila. Ese ??? es la tesis del proyecto entero: los sistemas operativos tradicionales no tienen una abstracción para los agentes de IA, y el equipo de Cloudflare cree que deberían tenerla. Su argumento es que un agente no es un usuario más — tiene que rendir cuentas ante una persona a la vez que opera con sus propios permisos restringidos — y que el modelo de seguridad adecuado para eso no son las listas de control de acceso, sino la seguridad basada en capacidades.

Guárdate esa palabra, “capacidades”. Volvemos a ella más abajo y es donde está la chicha.

🔑 La idea de fondo: la propuesta no es que tu empresa use Cloudflare OS. Es que copies el repo y lo conviertas en el sistema operativo de tu empresa. Textual del README: “the idea is not that your company uses Cloudflare OS, but rather that you make it Your Company OS”.

¿Qué es un gadget y por qué rompe con 25 años de SaaS? ¶

Un gadget es una aplicación pequeña que corre en un sandbox aislado y de la que cada usuario tiene su propia copia privada, código incluido.

Suena inocente hasta que te paras a pensar en la implicación. Cuando creas una presentación en Cloudflare OS no estás llamando a un SaaS de presentaciones que vive en la nube y sirve a millones de personas. El sistema crea una instancia privada del software de presentaciones solo para ti, en su propio sandbox.

De ahí salen dos consecuencias que el README enumera sin rodeos:

1. Es imposible que la app de presentaciones tenga un bug de seguridad que filtre tus slides a un atacante, porque el sandbox controla todo el acceso a tu instancia privada.
2. Si le falta una funcionalidad que necesitas, se la pides a tu agente y la añade. Y como se cumple el punto 1, hacerlo es seguro.

El repo lo llama, con toda la intención, “una ruptura con los últimos 25 años de arquitectura cloud y del Software as a Service”. Su tesis es que la IA ha cambiado la ecuación: cuando cualquier usuario puede pedirle a un agente las funcionalidades que necesita, el modelo centralizado del software deja de tener sentido.

Es una afirmación gorda. Y discutible. Pero viniendo de la gente que ha construido una de las plataformas de cómputo distribuido más usadas del planeta, merece que la escuches antes de descartarla.

La forma más rápida de entenderlo es pensarlo como una suite ofimática online, tipo Google Docs, con un giro: en vez de un conjunto fijo de tipos de fichero (documento, hoja de cálculo, presentación), cada fichero es potencialmente su propia aplicación a medida, escrita por IA para hacer exactamente lo que tú necesitas. Privada por defecto, compartible cuando quieras, y con la posibilidad de tener miles porque se crean por capricho.

Guía interactiva gratis

Los permisos por capas, antes de que te los ponga un Gatekeeper

El curso tiene una parada sobre soltar al modelo con permisos por capas y otra sobre MCP: las dos ideas que Cloudflare lleva al extremo en este repo. Son 17 paradas y eliges tú el camino.

Entra en el curso gratis →

¿En qué se diferencian los Gatekeepers de un servidor MCP? ¶

Un Gatekeeper es la pieza que media entre un gadget (o un agente) y un servicio externo: envuelve su API, gestiona la autorización, restringe el acceso al recurso concreto que autorizaste, registra cada acción y te da la oportunidad de aprobar o denegar todo lo que tenga efectos secundarios.

El README los define como “servidores MCP supervitaminados”, y la comparación es útil pero se queda corta. Si el Model Context Protocol te suena a chino, tengo un repaso completo de los protocolos que conectan agentes de IA con tus herramientas donde MCP ocupa el papel principal.

La diferencia práctica está en cuatro puntos que un servidor MCP típico no cubre:

• Autorización real, con OAuth por servicio, no un token en una variable de entorno.
• Acceso estrecho: solo el recurso concreto que el usuario quiso dar, no “todo lo que alcance este token”.
• Log completo de cada acción que ejecuta el gadget o el agente, para que lo revises.
• Humano en el bucle para cualquier acción con efectos secundarios.

Cada Gatekeeper es un Worker independiente. En el repo vienen con documentación de configuración los de GitHub, Google, Cloudflare, Supabase, Notion, Confluence, Email Workers, Home Assistant, Slack, Spotify y ZoomInfo — once integraciones. Pero si te asomas al directorio packages/ verás bastantes más paquetes gatekeeper-*: hay uno de Linear, uno de scheduler, uno de contexto y hasta un gatekeeper-mcp con su portal, lo que sugiere que puedes enchufar servidores MCP existentes por debajo de la capa de Gatekeepers.

Que exista gatekeeper-mcp es la señal más honesta de todas: no vienen a matar a MCP, vienen a ponerle un portero en la puerta.

⚠️ Ojo con la letra pequeña de las integraciones. El propio README admite que configurar los Gatekeepers es tedioso porque muchos proveedores no ponen fácil obtener credenciales OAuth, ya que su público objetivo son desarrolladores. Traducido: la parte aburrida sigue siendo aburrida.

¿Por qué la aprobación asíncrona es el hallazgo más importante del repo? ¶

Porque resuelve el problema que te hace escribir --dangerously-skip-permissions sin dejarte sin red de seguridad.

Vamos con el planteamiento. En un esquema clásico de humano en el bucle, la aprobación es síncrona: el agente quiere hacer algo, se detiene, y espera a que tú digas que sí. El README describe el fallo con una precisión quirúrgica: le das una tarea al agente, te vas a por un café, y vuelves para encontrarte que se atascó en una aprobación del primer paso y no ha avanzado nada. El resultado es que la gente acaba poniendo el auto-aprobado o saltándose los permisos, que es, dicho por ellos mismos, “obviamente inseguro”.

La solución de los Gatekeepers es más lista que el hambre:

1. El agente ejecuta una acción que requiere aprobación.
2. El Gatekeeper simula el resultado en local y le dice al agente que la acción se completó.
3. El agente sigue trabajando y encolando más acciones. Si intenta leer los resultados, el Gatekeeper le devuelve resultados simulados.
4. Cuando el agente termina, tú apruebas o rechazas las acciones en bloque o una a una. Cuando te venga bien.

Piénsalo como el modo revisión de un documento compartido, pero para acciones con efectos en el mundo real. El agente escribe encima; tú decides después qué cambios entran.

💡 Si solo te llevas una idea de este post, que sea esta: el cuello de botella de los agentes no es la inteligencia del modelo, es la latencia de tu atención. Cualquier diseño que desacople la ejecución de la aprobación gana tiempo real, no tiempo de benchmark.

Es un patrón que puedes copiar aunque no toques Cloudflare OS en tu vida. Si estás montando un harness de agentes en casa, la pregunta que te tienes que hacer no es “¿pido permiso o no?”, sino “¿puedo hacer que el agente avance con un resultado plausible y consolidar después?”.

Tiene sus límites, claro. Simular el resultado de una llamada funciona bien cuando la acción es un POST cuyo resultado el agente no necesita para razonar de verdad. Cuando la siguiente decisión del agente depende del contenido exacto de la respuesta real, la simulación se vuelve una fuente de alucinaciones encadenadas. El repositorio no vende esto como magia infalible, y tú tampoco deberías comprarlo así.

¿Qué significa control de acceso por capacidades en la práctica? ¶

Significa que cada agente y cada gadget arranca con acceso a nada. Cero. Aunque hayas configurado el sistema con todas tus cuentas externas conectadas.

Para que un agente pueda tocar algo, tienes que presentárselo. Pegas el enlace de un repositorio de GitHub, o pulsas “añadir recurso” y lo eliges en la interfaz. También puede pasar al revés: el agente pide que le presentes un recurso que cree necesitar, y tú concedes o deniegas.

La diferencia con lo que haces ahora es más grande de lo que parece. En la mayoría de harnesses de agentes, los servidores MCP se configuran una vez y quedan disponibles de forma ambiental en todos los chats. Tu agente arranca cada conversación con acceso a Slack, a Jira, a tu Drive y a tus repos, tenga que usarlos o no. Las presentaciones basadas en capacidades mantienen a cada agente restringido a lo que necesita para la tarea que tiene delante.

Si has leído lo que escribí sobre qué no deberías compartir con agentes de IA, esto es la versión arquitectónica de esa misma preocupación: en vez de confiar en tu criterio en cada prompt, el sistema hace que el acceso por defecto sea nulo.

El sandboxing acompaña a la teoría. Cada gadget corre con la red cortada de raíz:

• El servidor vive en un Dynamic Worker con el acceso a internet deshabilitado. Solo puede hablar con los recursos externos que designaste, vía bindings de Workers.
• El cliente corre en un iframe en sandbox que solo se comunica con su servidor mediante una sesión RPC de Cap’n Web sobre postMessage(). Por lo demás, tiene el acceso a internet bloqueado hasta donde los navegadores lo permiten, con Content-Security-Policy y los ajustes de sandbox del iframe.

Es el mismo instinto de defensa en profundidad del que hablo en la seguridad de tu código en tiempos de IA, pero aplicado a la capa de ejecución en vez de a la del código fuente.

¿Qué es un Blueprint y por qué se parece más a una app de escritorio que a una web? ¶

Un Blueprint es una copia del código de un gadget que puedes compartir para que otras personas creen su propia instancia, con sus propios datos y sus propias credenciales.

La documentación del repo es concreta sobre qué captura y qué no. Un blueprint captura el código fuente (una instantánea del documento Yjs ya consolidado, sin historial de edición), la descripción de los bindings que necesita, y metadatos como título, autor y versión. No captura el contenido del almacenamiento SQLite del gadget, ni el historial de chat con la IA, ni conexiones vivas o credenciales.

Se comparten por enlace, con un identificador hexadecimal aleatorio de 128 bits generado en el servidor. Cualquiera con el enlace puede ver los metadatos sin autenticarse, pero crear un gadget a partir del blueprint requiere identificarse. Un mismo gadget puede tener varios blueprints en versiones distintas — el equivalente a un canal “stable” y uno “latest” —, y se pueden exportar a un fichero .gadget para importarlos en otra instancia.

Aquí está el cambio de modelo mental. Lo tradicional es: construyes una web app, la alojas en tu servidor y los usuarios se conectan a ella. Los blueprints funcionan como las apps móviles o las de escritorio de toda la vida: cada usuario ejecuta su propia copia.

¿Por qué importa esto ahora y no hace diez años? Por dos motivos que el README argumenta bien. Uno, la IA permite a un desarrollador individual construir mucho más de lo que podía, pero mantener un servicio online sigue siendo un marrón — y esto lo elimina. Dos, y más importante, que cada usuario ejecute su propia copia le permite cambiar el software con IA cuando no hace lo que necesita. Sin abrir una issue, sin suplicarle al mantenedor que lo priorice.

¿Cómo se comparte un gadget sin filtrar datos que el otro no debería ver? ¶

Con un mecanismo llamado observers, que es de lo más fino que hay en el repositorio y de lo que menos se habla.

Compartir un gadget es fácil. Compartirlo sin abrir un agujero, no. Imagina que Alice tiene un gadget que lee un repositorio privado a través del Gatekeeper de GitHub y lo comparte con Bob, que no tiene acceso a ese repo. Si el gadget muestra datos, Alice acaba de filtrar información sin querer.

El sistema lo evita así, según la documentación de docs/observers.md:

1. Cuando Bob abre el gadget compartido, debe indicar una cuenta conectada suya para cada Gatekeeper del gadget.
2. Cada Gatekeeper verifica que la cuenta de Bob tiene privilegios suficientes para leer por su cuenta todo lo que el gadget ha leído históricamente por ese Gatekeeper. Si no, se le deniega el acceso.
3. Si pasa la comprobación, Bob queda registrado como “observer” del gadget.
4. A partir de ahí, si el gadget intenta una lectura nueva que algún observer registrado no podría hacer por sí mismo, esa lectura se bloquea con una excepción. Alice puede resolverlo revocando el acceso de Bob.
5. Y el chequeo se repite cada vez que Bob abre el gadget.

Los roles de colaboración son dos y están ordenados: build puede editar código, usar el chat de IA y gestionar bindings; use solo puede interactuar con la interfaz ya desplegada. Un detalle que me parece de manual: cuando un colaborador con rol build usa la IA, el modelo se resuelve desde su propia cuenta, y cuando añade un binding de Gatekeeper, se conecta a través de sus propias cuentas de terceros. Así un colaborador no hereda las llaves del dueño.

🛡️ Este es el tipo de detalle que separa un proyecto pensado por un equipo de seguridad de uno pensado por un equipo de producto con prisa. La pregunta “¿y si compartir un documento filtrase por accidente lo que el documento leyó?” casi nunca se hace a tiempo.

Construye agentes con criterio

Las capas que Cloudflare pone en su kernel, aplicadas a tu propio agente

Verás los seis niveles de arquitectura de un agente — tools, guardarraíles, memoria, skills, MCP y orquestación — con código en directo. Es el mapa para diseñar lo que aquí has visto montado por otros.

Ver el método entero →

6 niveles de arquitectura, en directo · Web Reactiva Premium

¿Qué hay debajo del capó? ¶

Cloudflare Workers, y no de forma superficial. El proyecto se apoya con fuerza en tres primitivas: Durable Objects, Dynamic Workers y Facets.

El reparto es directo: cada espacio de trabajo es su propio Durable Object, cada gadget se ejecuta en un Facet de Dynamic Worker, y los Gatekeepers instalan también facets en cada espacio de trabajo para gestionar el acceso a servicios remotos. La colaboración en tiempo real sale casi gratis de ahí — el README presume de que el agente de código la implementa por defecto, sin que se lo pidas, porque el Durable Object de debajo la pone fácil.

La comunicación entre cliente y servidor de un gadget está obligada a pasar por Cap’n Web, el sistema RPC nativo de JavaScript del mismo autor que Cap’n Proto. Sin esquemas, sin apenas boilerplate, serialización legible basada en JSON, funciona sobre HTTP, WebSocket y postMessage(), y todo el paquete pesa menos de 10 kB minificado y comprimido con gzip, sin dependencias.

Esa obligación no es un capricho. Tiene un doble beneficio que explica media arquitectura:

// Servidor de un gadget: defines un método y ya está expuesto
import { RpcTarget } from "capnweb";

class MiGadget extends RpcTarget {
  // Este método lo puede llamar el cliente... y también el agente
  async listarTareas(estado) {
    return this.db.query("SELECT * FROM tasks WHERE status = ?", estado);
  }
}

Por un lado, tan poco boilerplate hace que a los agentes les resulte cómodo trabajar con ese código. Por otro, el servidor expone por narices una API fácil de entender que un agente puede llamar. Resultado: cada app construida con Cloudflare OS tiene una API apta para agentes desde el minuto uno, sin montar un servidor MCP ni un bucle de agente a medida.

El agente, además, es un agente Code Mode: hace las tareas escribiendo fragmentos de código y ejecutándolos al vuelo, en vez de llamar herramientas una a una. Y aunque es el agente de código de la plataforma, el README aclara que sirve para tareas arbitrarias, no solo para programar.

Un apunte que me parece de los más valiosos del proyecto y que no tiene nada que ver con la IA: quien construyó esto es el mismo equipo que construyó Workers, y varias funcionalidades del runtime (Dynamic Workers, Facets) se añadieron específicamente para soportar Cloudflare OS. Leer este código fuente es la forma más directa de ver cómo el equipo del runtime de Workers cree que hay que usar Workers.

¿Cómo lo ejecutas hoy en tu máquina? ¶

Con dos comandos, si tienes pnpm instalado.

# Levanta toda la pila en local sobre wrangler y workerd
pnpm run-local

Y visitas http://localhost:8787. Tus datos se guardan en un subdirectorio .wrangler. No es para producción, pero es la vía rápida para ver qué hace el producto de verdad.

Si vas a tocar código, el flujo de desarrollo son dos terminales:

# Terminal 1
pnpm dev-server

# Terminal 2
pnpm dev-client

Y ahí el puerto es http://localhost:3000.

El README propone prompts concretos para la primera toma de contacto, y son buenos porque enseñan las tres capas del sistema: “haz unas slides para mi próxima reunión con un cliente” (usa el blueprint de presentaciones incluido), “hazme una pizarra colaborativa” (crea una app desde cero), o “haz un dashboard de issues de este repo de GitHub” (requiere la integración de GitHub configurada).

Para desplegar tienes tres caminos con distinto nivel de compromiso:

El repo starter merece un vistazo aparte: fija una release concreta de Cloudflare OS y añade alrededor el control de marca, identidad (con Cloudflare Access), rutas, datos, integraciones y observabilidad, sin tocar el código de arriba. Sus propias insignias declaran Node.js 24 y pnpm 11, así que ya sabes por dónde va la barrera de entrada. Y su aviso es el mismo que el del repo principal: fija versiones, revisa los cambios y verifica la frontera de confianza antes de cada actualización en producción.

La tercera vía es la interesante a medio plazo. workerd, el runtime de Workers, es open source, y Cloudflare OS puede ejecutarse entero encima en tus servidores. Pero ojo, que el README marca esa sección como COMING SOON: las herramientas y la documentación para hacerlo con comodidad aún no están. Si te lanzas hoy, te toca leer la configuración de bajo nivel de workerd a pelo.

¿Qué no te cuenta el README con letras grandes? ¶

Cuatro cosas que conviene saber antes de proponerlo en tu empresa el lunes.

Es early access y lo dicen ellos. Este repositorio es la versión 2, una reescritura completa sobre unos cimientos nuevos con lo aprendido de la versión 1. El texto es explícito: “Cloudflare OS v2 es muy capaz, pero todavía tiene muchos bordes sin pulir. Lo sabemos, y estamos en ello”. Es una honestidad que se agradece y una bandera roja para producción a la vez.

No quieren tus pull requests. La política de contribución es de las más directas que he leído en un repo grande: “por ahora no buscamos contribución externa”. El razonamiento es interesante y probablemente lo veremos repetido: la IA ha hecho fácil escribir código, y lo difícil hoy es revisarlo, mantener la calidad y que el producto sea coherente; una contribución externa “dona” la parte fácil y genera más de la difícil. Aceptan arreglos pequeños y verificables al vuelo, pero piden que no mandes correcciones de erratas ni PRs de más de una docena de líneas — los cerrarán con un enlace a esa guía. Para ideas grandes, abres una discussion.

El adorno vale, la enchufada duele. Ya lo he dicho arriba, pero insisto porque es donde vas a perder la tarde: obtener credenciales OAuth de cada servicio de terceros es un vía crucis que ningún proyecto open source puede arreglarte.

El contexto de la empresa importa. Cloudflare cerró la primavera de 2026 con cifras récord de ingresos y un recorte de plantilla que TechCrunch cifró en 1.100 puestos, con declaraciones de su CEO sobre categorías de trabajo que la IA ha dejado obsoletas. Que la misma compañía libere el sistema interno con el que miles de sus empleados trabajan con IA a diario no es una contradicción, pero sí es un dato que cambia cómo lees la palabra “productividad” en el README. Tú decides qué haces con esa lectura.

⚠️ Antes de instalar nada en la infraestructura de tu empresa: esto no es un producto gestionado con SLA, es un repo Apache-2.0 en desarrollo intenso. Lo que ganas es control total y ninguna dependencia de proveedor. Lo que pierdes es el teléfono al que llamar cuando algo se rompa un viernes.

¿Qué le puedes robar a Cloudflare OS aunque nunca lo instales? ¶

Bastante. Estas son las cuatro ideas que me llevo y que puedes aplicar en tu propio sistema esta misma semana.

Aprobación asíncrona con simulación. Si tienes un agente que se atasca pidiendo permisos, plantéate encolar las acciones con efectos secundarios y consolidarlas en bloque al final. Ganas paralelismo sin renunciar al control.

Acceso cero por defecto, presentaciones explícitas. Deja de configurar todos tus MCP de golpe en el fichero global. Que cada sesión de agente arranque sin acceso y le vayas presentando lo que necesita. Es más incómodo el primer día y más tranquilo el resto.

API apta para agentes por construcción. Si eliges una capa RPC de bajo boilerplate para tu app, la API que expones para tu cliente es la API que puede usar un agente. Te ahorras mantener dos superficies.

Instancia por usuario en vez de multi-tenant. No para todo — hay cargas donde es un disparate —, pero para herramientas internas pequeñas, darle a cada persona su copia elimina de raíz una familia entera de bugs de aislamiento de datos.

Si estás dándole vueltas a montar tu propio entorno de IA persistente en la nube, comparé el enfoque comercial con Zo Computer, un ordenador en la nube con IA. El contraste es útil: Zo es un producto de pago que te resuelve la vida; Cloudflare OS es un repositorio que te la complica a cambio de no depender de nadie.

Cloudflare OS frente a lo que ya usas ¶

Lo que esta tabla no te dice, y es lo que de verdad decide: Cloudflare OS solo tiene sentido si el control es un requisito y no una preferencia. Si tu equipo va bien con un chat y tres MCP, montar todo esto es matar moscas a cañonazos.

TL;DR ¶

• 🚀 Cloudflare abrió el 5 de agosto de 2026 el código de la plataforma de IA que usa internamente, bajo Apache-2.0 y con la idea de que la conviertas en el sistema operativo de tu empresa
• 🧩 Los “gadgets” son apps con una instancia privada por usuario: elimina fugas de datos entre usuarios y te deja modificar el código con IA
• 🛡️ Los Gatekeepers son servidores MCP supervitaminados con OAuth, acceso estrecho, log de acciones y humano en el bucle
• ⚡ El hallazgo técnico: la aprobación asíncrona simula el resultado para que el agente no se bloquee y tú apruebes en bloque después
• ⚠️ Es early access declarado, no aceptan contribuciones externas y la documentación para autoalojar en workerd todavía no está

Preguntas frecuentes sobre Cloudflare OS ¶

¿Cloudflare OS es un sistema operativo de verdad? ¶

No. No arranca hardware ni gestiona procesos de tu máquina. Es una plataforma de productividad con IA que usa la analogía de sistema operativo porque su backend hace de kernel (conecta usuarios con programas y recursos, aplica sandboxing y control de acceso), los Gatekeepers hacen de drivers y los gadgets de procesos.

¿Cuánto cuesta usar Cloudflare OS? ¶

El software es gratuito y open source con licencia Apache-2.0. Los costes vienen de la infraestructura donde lo ejecutes (tu cuenta de Cloudflare o tus propios servidores con workerd) y de los modelos de IA que uses, ya que la plataforma admite múltiples proveedores y modelos autoalojados.

¿Puedo ejecutar Cloudflare OS sin usar Cloudflare? ¶

Sí, en teoría. workerd, el runtime de Workers, es open source y Cloudflare OS puede correr entero encima en tus propios servidores. Pero el README marca esa vía como “coming soon” en cuanto a documentación y herramientas, así que hoy implica leer la configuración de bajo nivel de workerd por tu cuenta.

¿En qué se diferencia un Gatekeeper de un servidor MCP? ¶

Un Gatekeeper añade sobre lo que hace MCP: autorización con OAuth por servicio, restricción del acceso al recurso concreto que autorizaste, registro de todas las acciones ejecutadas y aprobación humana asíncrona para acciones con efectos secundarios. El repositorio incluye además un gatekeeper-mcp, así que ambos conviven.

¿Qué es la aprobación asíncrona de los Gatekeepers? ¶

Es un mecanismo por el que el agente no se detiene a esperar tu permiso. El Gatekeeper simula el resultado de la acción, deja que el agente siga trabajando y encole más acciones, y luego tú apruebas o rechazas todo en bloque o una a una cuando te venga bien.

¿Puedo compartir un gadget con mi equipo? ¶

Sí, de dos formas. Como colaborador (con rol build para editar o use para solo interactuar con la interfaz) o publicando un blueprint para que cada persona cree su propia copia independiente. El sistema verifica con el mecanismo de observers que quien recibe acceso ya tenía privilegios para leer los datos que el gadget ha consultado.

¿Qué integraciones trae Cloudflare OS de serie? ¶

El README documenta la configuración de once: GitHub, Google, Cloudflare, Supabase, Notion, Confluence, Email Workers, Home Assistant, Slack, Spotify y ZoomInfo. En el directorio packages/ hay paquetes adicionales de Gatekeeper como Linear, scheduler, contexto y un portal MCP.

¿Puedo contribuir código a Cloudflare OS? ¶

Por ahora no, salvo arreglos muy pequeños. El equipo pide que no envíes PRs de erratas ni de más de una docena de líneas, y cierra los que no cumplen con un enlace a su guía. Para ideas grandes, el canal es abrir una discussion en el repositorio.

¿Es seguro dejar que la IA escriba apps que se ejecutan en mi empresa? ¶

Ese es justo el problema que el diseño intenta resolver. Cada gadget corre en un sandbox sin acceso a internet salvo a los recursos que designes, el cliente vive en un iframe restringido con CSP, y los agentes y gadgets no tienen acceso a nada hasta que se lo presentas. Aun así, es software early access: trátalo como tal.

¿Qué tecnologías necesito conocer para trastear con el repositorio? ¶

TypeScript y el ecosistema de Cloudflare Workers, sobre todo Durable Objects, Dynamic Workers y Facets. El monorepo usa pnpm y el repo starter declara Node.js 24 y pnpm 11. Para entender la comunicación entre cliente y servidor de los gadgets te hace falta Cap’n Web, que se aprende en una tarde.

Y ahora la pregunta que llevas leyendo todo el post sin formular: ¿de verdad quieres que cada persona de tu equipo tenga su propia copia modificable de las herramientas internas?

Porque esa, y no la de si Cloudflare OS está pulido, es la decisión difícil.

Fuentes ¶

Documentación primaria del proyecto:

• cloudflare/cloudflare-os — repositorio y README
• cloudflare/cloudflare-os-starter — despliegue personalizado con release fijada
• docs/blueprints.md — qué captura y qué no un blueprint
• docs/sharing.md — roles de colaboración build y use
• docs/observers.md — permisos de lectura por transitividad
• cloudflare/capnweb — el sistema RPC obligatorio en los gadgets
• cloudflare/workerd — el runtime open source de Workers

Anuncios y cobertura:

• The Cloudflare Blog, “Cloudflare OS: an open platform for agents, apps, and work”
• Cloudflare, nota de prensa del 5 de agosto de 2026
• Phoronix, “Cloudflare Announces Open-Source Cloudflare OS As AI Operating System”
• SiliconANGLE, “Cloudflare launches Cloudflare OS”
• TechCrunch, “Cloudflare says AI made 1,100 jobs obsolete, even as revenue hit a record high”

Conceptos relacionados:

• Cloudflare, “Code Mode”
• Cloudflare, “Dynamic Workers”
• Cloudflare Docs, “Durable Objects”

🧨 Última oportunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter