---
title: "Cloudflare OS: el sistema operativo que no es un sistema operativo"
excerpt: "Cloudflare liberó Cloudflare OS con licencia Apache 2.0. No es una distro: es un espacio de trabajo para agentes construido sobre Workers. Lo interesante está en cómo resuelve el problema de los permisos, que es donde todos acabamos escribiendo --dangerously-skip-permissions."
date: "2026-08-05T11:00:00.000Z"
category: "Inteligencia Artificial"
tech_article: true
author:
  name: "angel cruz"
  picture: "https://angelcruzdevcdn.nyc3.cdn.digitaloceanspaces.com/images/me/angel-cruz.png"
ogImage:
  url: "/images/open-graph/cloudflare-monetization-gateway.png"
seo_title: "Qué es Cloudflare OS: gadgets, gatekeepers y agentes con permisos"
seo_description: "Qué es Cloudflare OS, la plataforma de agentes que Cloudflare liberó con Apache 2.0: gadgets en sandbox, gatekeepers con aprobación diferida y seguridad por capacidades. Cómo probarlo en local."
---

Todos hemos escrito `--dangerously-skip-permissions`. No porque seamos temerarios, sino porque la alternativa es dejarle una tarea al agente, ir por un café y volver a los veinte minutos para encontrártelo parado en el primer paso esperando que le digas que sí.

Cloudflare acaba de liberar algo que ataca exactamente ese problema, y de una forma que no había visto antes. El envoltorio, eso sí, tiene el peor nombre posible.

## No, no es una distro de Linux

Lees "Cloudflare OS" y piensas en un kernel, un init y un gestor de paquetes. No hay nada de eso. **Cloudflare OS es un espacio de trabajo para agentes de IA construido sobre Cloudflare Workers**, liberado con licencia **Apache 2.0** en [cloudflare/cloudflare-os](https://github.com/cloudflare/cloudflare-os).

Lo curioso es que el propio equipo se adelanta a la queja. En el README hay una tabla que mapea la analogía, y se sostiene mejor de lo que esperaba:

| Sistema operativo normal | Cloudflare OS |
| --- | --- |
| kernel | `packages/workshop-backend` |
| drivers | `packages/gatekeeper-*` |
| shell | `packages/workshop-frontend` |
| procesos | gadgets |
| ejecutables | blueprints |
| usuarios | usuarios |
| ACLs | permisos compartidos |
| ??? | agentes |

Esa última fila con interrogantes es la tesis del proyecto: los sistemas operativos de siempre no tienen dónde meter a un agente. No es un usuario, porque tiene que responder ante una persona. No es un proceso, porque decide por su cuenta qué hacer. Y como escribe código y lo ejecuta al vuelo, el modelo de seguridad que le sirve no son las listas de control de acceso, sino las capacidades.

No lo estrenaron con el anuncio: Cloudflare lo dio a todos sus empleados en mayo, y lo que ahora publican es una versión reconstruida para que cualquiera la despliegue.

## Gatekeepers: la idea que vale el artículo

Un **Gatekeeper** es lo que conecta a un agente con un servicio externo. GitHub, Google, la propia API de Cloudflare. Cada uno es un Worker aparte, y su documentación los describe como "MCP servers supercargados": envuelven la API del servicio, aíslan las credenciales y registran cada acción para que la revises.

Hasta ahí, suena a lo que ya hace un [servidor MCP](/post/introduccion-a-mcp-model-context-protocol). Lo distinto es cómo tratan la aprobación.

El planteamiento habitual es **síncrono**: el agente quiere hacer algo, se detiene, y no sigue hasta que apruebas. Es lo que hace que la gente termine en el auto-aprobar. Un Gatekeeper hace otra cosa:

1. El agente pide una acción que requiere permiso.
2. El Gatekeeper **simula el resultado en local** y le dice al agente que salió bien.
3. Si el agente intenta leer el resultado, recibe el simulado.
4. El agente sigue trabajando y encolando acciones.
5. Tú apruebas o rechazas después, en bloque o una por una, cuando te venga bien.

O sea: el agente no se bloquea y tú no pierdes el control. La revisión deja de ser un semáforo y pasa a ser una cola. Es la primera respuesta seria que veo al dilema de los permisos, que hoy se resuelve casi siempre desactivándolos.

Tiene un límite honesto, y conviene decirlo: simular el resultado funciona bien cuando la acción es un efecto que puedes describir, y peor cuando el agente necesita el dato real para decidir el paso siguiente. Si escribe un fichero y luego quiere leerlo, la simulación aguanta. Si consulta un saldo para ramificar según el número, no.

## Los agentes empiezan sin nada

El otro golpe va contra cómo configuramos los agentes hoy. Cuando conectas servidores MCP a Claude Code o a Cursor, los declaras **por adelantado** y quedan disponibles en todas las sesiones. El agente tiene acceso ambiental a todo, todo el tiempo, use lo que use.

Cloudflare OS invierte eso: cada agente y cada gadget **empieza sin acceso a nada**, aunque el espacio de trabajo tenga cuentas externas configuradas. Tienes que *presentarle* cada recurso, pegando un enlace al repo o eligiéndolo en la interfaz. El agente también puede pedirte que le presentes algo que cree necesitar, y tú concedes o niegas.

Es seguridad basada en capacidades aplicada a lo que ya haces todos los días. Y explica por qué el proyecto se apoya en [Cap'n Web](https://github.com/cloudflare/capnweb), el sistema RPC que Cloudflare publicó bajo MIT: es un modelo de capacidades por objeto, donde solo puedes llamar a lo que alguien te entregó explícitamente. Pesa menos de 10 kB comprimido, no tiene esquemas, serializa a JSON legible y permite llamadas en las dos direcciones.

## Gadgets: cada documento es su propia aplicación

Aquí está el otro cambio de mentalidad. Cuando creas una presentación en Cloudflare OS, no estás usando un SaaS alojado en algún sitio. El sistema crea una **instancia privada** de ese software solo para ti, en su propio sandbox. A eso lo llaman **gadget**.

La consecuencia de seguridad es fuerte: la aplicación de presentaciones no puede tener un fallo que filtre tus diapositivas a un atacante, porque no hay una aplicación compartida donde meter el fallo. Cada instancia está aislada.

El sandbox es de verdad, y en dos capas:

- El servidor corre en un **Dynamic Worker con la salida a internet desactivada**. Solo habla con los recursos que designaste, vía Workers Bindings.
- El cliente corre en un **iframe con sandbox**, que solo se comunica con su servidor por una sesión Cap'n Web sobre `postMessage()`, y por lo demás está bloqueado con `Content-Security-Policy`.

Los **blueprints** son las plantillas, pero a diferencia de una plantilla de ofimática no comparten contenido: comparten **el código de una aplicación entera**. Cada persona corre su propia copia. Se parece más a instalar una app de escritorio que a entrar a una web alojada por otro.

El código lo escribe el agente. Puedes hacerlo a mano, pero el planteamiento es que le pidas el gadget y él lo construya, lo pruebe y depure los errores. El agente funciona en **Code Mode**: en vez de llamar herramientas una a una, escribe fragmentos de código y los ejecuta al momento.

## Construido sobre Workers, y por el equipo de Workers

Esta parte me parece la más interesante para quien ya vive en el ecosistema. Cada espacio de trabajo es un **Durable Object**, cada gadget corre en un **Dynamic Worker Facet**, y los gatekeepers instalan facets dentro del espacio de trabajo para gestionar el acceso remoto.

Y el detalle que lo explica todo: **Dynamic Workers y Facets se añadieron al runtime específicamente para que esto existiera**. No es una aplicación que usa Workers, es una aplicación que empujó a Workers a crecer. Por eso el propio README sugiere leer el código fuente para entender cómo el equipo del runtime cree que hay que usar Workers.

Contra lo que uno esperaría de un producto de Cloudflare, **no estás atado a Cloudflare**. `workerd`, el runtime de Workers, [también es open source](https://github.com/cloudflare/workerd), y Cloudflare OS puede correr encima de él en tus propios servidores.

## Cómo probarlo

En local solo necesitas [pnpm](https://pnpm.io/):

```bash
git clone https://github.com/cloudflare/cloudflare-os.git
cd cloudflare-os
pnpm run-local
```

Y abres `http://localhost:8787`. Por debajo esto usa `wrangler`, y tus datos quedan en un subdirectorio `.wrangler`. Para desarrollo, `pnpm dev-server` y `pnpm dev-client` te dejan el front en `http://localhost:3000`.

Si lo quieres en tu cuenta de Cloudflare hay un flujo guiado en `os.cloudflare.app/deploy`, y para algo más serio, con tus propios gatekeepers, está el repo [cloudflare-os-starter](https://github.com/cloudflare/cloudflare-os-starter).

## Lo que todavía no está

Tres cosas que el proyecto reconoce, y que conviene saber antes de emocionarse:

- **Autohospedar sobre `workerd` dice "COMING SOON".** La promesa de no depender de Cloudflare es real a nivel de licencia y de runtime, pero la documentación y el tooling para desplegarlo así todavía no existen. Te remiten a la configuración de bajo nivel de `workerd` y a que te las arregles.
- **El modelo de distribución de los gatekeepers está sin resolver.** La idea es que algún día se desplieguen y mantengan de forma independiente de cada instancia, pero, textualmente, los detalles están por definir. Hoy despliegas los que trae el repo junto con tu instancia.
- **Configurar los servicios externos duele.** Cada gatekeeper necesita credenciales OAuth propias, y el propio README admite que muchos proveedores lo ponen difícil a propósito porque su público objetivo son desarrolladores.

## Un detalle que me hizo gracia

El repo trae un directorio `.agents/skills/write-gatekeeper`. O sea: Cloudflare distribuye una [Agent Skill](/tools/cursor-rules) dentro del propio proyecto para que tu agente aprenda a escribir gatekeepers. Es exactamente el patrón del que hablé al explicar cómo [instalar skills desde cualquier repo](/post/npx-skills), aplicado por una empresa a su propia base de código.

Y para quien le guste mirar el `package.json` ajeno: pnpm, oxlint y workspaces. Buen gusto.

## Conclusión

El nombre va a generar confusión durante meses, y no ayuda que la respuesta corta sea "no, no es un sistema operativo". Pero por debajo hay dos ideas que valen más que el anuncio.

La primera es la aprobación diferida de los gatekeepers. Cualquiera que use agentes a diario conoce el dilema entre parar cada dos pasos o desactivar los permisos, y simular el resultado para revisar después es la salida más elegante que he visto.

La segunda es empezar en cero y presentar recursos de uno en uno, en lugar de dejar todos los MCP colgados y disponibles siempre. Eso no requiere Cloudflare OS para copiarse: es una forma de pensar los permisos que puedes aplicar hoy a tu propio setup.

Que además sea Apache 2.0 y pueda correr sobre `workerd` hace que valga la pena leer el código aunque nunca lo despliegues.

## Preguntas frecuentes

### ¿Qué es Cloudflare OS?

Es una plataforma open source para agentes de IA que Cloudflare liberó bajo licencia Apache 2.0. Da a cada persona un espacio de trabajo donde un agente puede crear documentos, construir pequeñas aplicaciones y ejecutar tareas con el contexto y los sistemas internos de la empresa. Está construida sobre Cloudflare Workers.

### ¿Cloudflare OS es un sistema operativo de verdad?

No en el sentido habitual: no hay kernel, ni distro, ni gestor de paquetes. El nombre viene de una analogía que el propio proyecto documenta, donde el backend hace de kernel, los gatekeepers de drivers, los gadgets de procesos y los blueprints de ejecutables.

### ¿Qué es un Gatekeeper en Cloudflare OS?

Un Worker que hace de intermediario entre un agente y un servicio externo. Envuelve la API del servicio con una interfaz Cap'n Web, aísla las credenciales, aplica políticas y registra cada acción. Su rasgo distintivo es que puede simular el resultado de una acción pendiente de aprobación para que el agente no se quede bloqueado.

### ¿Qué diferencia hay entre un Gatekeeper y un servidor MCP?

Un servidor MCP se configura por adelantado y queda disponible para el agente en todas las sesiones. Un Gatekeeper parte de acceso cero: tienes que presentarle el recurso concreto al agente que lo necesita. Además añade la aprobación diferida, que MCP no contempla.

### ¿Necesito una cuenta de Cloudflare para usarlo?

Para probarlo en local no: con `pnpm run-local` corre en tu máquina sobre `workerd`. Para desplegarlo en producción hoy la vía practicable es una cuenta de Cloudflare; autohospedarlo sobre `workerd` está anunciado pero sin documentación ni tooling todavía.

### ¿Qué licencia tiene Cloudflare OS?

Apache 2.0. Cap'n Web, el sistema RPC que usa por debajo, se publica bajo MIT.

## Fuentes

- [Cloudflare OS: an open platform for agents, apps, and work](https://blog.cloudflare.com/cloudflare-os/), el anuncio oficial.
- [cloudflare/cloudflare-os](https://github.com/cloudflare/cloudflare-os), el repositorio y su README.
- [cloudflare/capnweb](https://github.com/cloudflare/capnweb), el sistema RPC de capacidades.
- [cloudflare/workerd](https://github.com/cloudflare/workerd), el runtime de Workers.

---

## Sitemap

Índice completo del sitio: [/sitemap.md](https://www.angelcruz.dev/sitemap.md)

Canónico HTML: [https://www.angelcruz.dev/post/que-es-cloudflare-os](https://www.angelcruz.dev/post/que-es-cloudflare-os)