Introducción
En mayo de 2026, Cloudflare puso en manos de todos sus empleados una plataforma interna para crear aplicaciones, automatizar procesos y acceder a los sistemas corporativos mediante agentes de IA. Tres meses después, esa misma plataforma fue publicada como código abierto bajo el nombre Cloudflare OS. Lo que podría parecer un lanzamiento de producto más esconde, en realidad, una respuesta arquitectónica a un desafío que muchos equipos de platform engineering conocen bien: ¿cómo ofrecer un entorno de ejecución seguro y multi-tenant para aplicaciones creadas dinámicamente por usuarios sin perfil técnico?
Dos nuevos primitivos para el aislamiento
La restricción de partida era sencilla de enunciar pero difícil de resolver: si cualquier empleado puede crear una aplicación, cada aplicación debe ejecutarse en estricto aislamiento, sin compartir estado ni base de datos con las demás.
Para lograrlo, Cloudflare desarrolló dos componentes que no existían en su catálogo previo: los Dynamic Workers y las Durable Object Facets. Los primeros permiten cargar código en tiempo real sin necesidad de despliegues manuales: cada aplicación generada por un agente se convierte en un Worker autónomo, instanciado bajo demanda. Los segundos resuelven el problema del almacenamiento: cada Worker dinámico recibe su propia instancia de base de datos SQLite, completamente aislada del resto, sin configuración adicional.
El resultado es que una aplicación creada por un agente no tiene ningún mecanismo estructural para acceder a los datos de otra. El aislamiento lo garantiza el propio runtime, no la documentación interna ni la disciplina de los desarrolladores.
Seguridad codificada en Workers
El segundo desafío era el control de accesos. Un agente que actúa en nombre de un empleado no debería poder leer un repositorio completo cuando solo se le pide consultar una incidencia puntual. Cloudflare OS introduce los Gatekeepers: Workers especializados que se interponen entre el agente y cada sistema externo.
Cada Gatekeeper define reglas precisas: acceso de solo lectura a una ruta determinada, ocultamiento de campos sensibles, límites de velocidad, aprobaciones requeridas para operaciones críticas. Por defecto, los agentes arrancan sin ningún acceso. La plataforma también registra cada recurso al que accede un agente, y ese registro se convierte en un dato de seguridad activo que los Gatekeepers consultan cuando un tercero intenta acceder a un workspace.
Este enfoque es security-as-code en su forma más operativa: las reglas de acceso son Workers versionables, testeables y desplegables como cualquier otro componente de la infraestructura.
Código abierto tras la prueba en producción
Cloudflare OS no es una solución lista para usar sin más. Existen dos repositorios públicos: el núcleo de la plataforma y un ejemplo de despliegue basado en el uso interno de Cloudflare. Socios integradores acompañan la personalización de los Gatekeepers y la configuración de los controles de seguridad según los sistemas de cada organización.
Lo que merece especial atención es precisamente la secuencia de publicación. Cloudflare desplegó Cloudflare OS para miles de sus propios empleados —abarcando todas las áreas de la empresa, no solo ingeniería— antes de abrir el código. Este orden es poco habitual: la mayoría de las plataformas se publican antes de haber sido verdaderamente sometidas a escala. Aquí, los primitivos Dynamic Workers y Durable Object Facets se construyeron para cubrir una necesidad interna concreta y se refinaron durante varios meses antes de cualquier anuncio público.
Lo que los equipos de DevOps pueden extraer de aquí
Para los equipos de platform engineering, el valor de Cloudflare OS no reside en las funcionalidades orientadas al usuario final, sino en la arquitectura subyacente. La combinación de Worker aislado más base de datos SQLite por instancia resuelve un problema de multi-tenancy que muchas Internal Developer Platforms eluden en lugar de afrontar de raíz. El modelo Gatekeeper ofrece un esquema de referencia para controlar el acceso de los agentes a sistemas internos sin ampliar la superficie de ataque.
El código publicado documenta decisiones técnicas validadas por una organización al nivel de un gran proveedor cloud. Para cualquier equipo que esté construyendo o evolucionando una plataforma interna, esto es un caso de estudio concreto que va mucho más allá de la documentación de una API.