Qué es Cloudflare OS: el espacio de trabajo de agentes de código abierto donde cada app es tuya

Cloudflare OS es un entorno de trabajo para agentes de IA, de código abierto bajo Apache 2.0, que Cloudflare lanzó el 5 de agosto de 2026. No es un sistema operativo tradicional: es una plataforma donde cada empleado tiene un agente que investiga, produce documentos y construye pequeñas aplicaciones personales, llamadas Gadgets, cada una corriendo en su propio sandbox, bajo un framework de seguridad basado en capacidades llamado Gatekeepers que media todo acceso a los datos internos. Corre sobre Cloudflare Workers, y podés desplegarlo en tu propia cuenta o correrlo en tus propios servidores con el runtime abierto workerd.

Superó las 3.900 estrellas en GitHub el primer día y pasó las 6.000 en dos días. El hilo de Hacker News, "Cloudflare OS: an open platform for agents, apps, and work," creció hasta los 328 comentarios y 658 puntos. Hay buenas razones tanto para el entusiasmo como para las críticas, y nos pasamos una semana usu00e1ndolo de verdad, en Linux y en una instalación limpia de Windows, antes de escribir el resto de esto.

Quién lo construyó, y de dónde viene la idea

La versión oficial: lo construyó el equipo de Cloudflare Workers, la misma gente que construyó la plataforma serverless sobre la que corre. Cloudflare se lo dio a toda su plantilla en mayo de 2026, y para agosto miles de empleados, no solo ingenieros, lo usaban a diario para escribir documentos, armar presentaciones y montar pequeñas apps internas. Lo que sale ahora es la versión 2, una reescritura completa basada en lo que la primera versión les enseñó.

La historia que no está en el comunicado de prensa vino de Kenton Varda, tech lead de Workers y creador de Cap'n Proto, en un posteo en X el día del lanzamiento:

"Today we are releasing Cloudflare OS, a chatbot with connectors, just like every other tech company is doing."

"Except actually, it's different. This is a remake of Sandstorm.io, my startup from 10 years ago, except this time built on Cloudflare Workers (the platform I've spent the last 9 years building) and deeply leveraging AI. This is more or less the culmination of my secret 10-year master plan."

(El posteo no se puede leer sin cuenta de X, así que lo citamos en vez de mandarte a algo que quizás no puedas abrir.)

Ese linaje explica el diseño mejor que cualquier documento de marketing. Sandstorm (2014) proponía algo que sonaba excéntrico en su momento: que cada usuario corriera su propia instancia privada de cada aplicación, con seguridad basada en capacidades en lugar de listas de permisos. Fracasó comercialmente: llegó demasiado pronto, y modificar software todavía requería programadores. Diez años después, la IA elimina justo esa barrera: si cualquiera puede pedirle a un agente que agregue una función, el software de instancia personal deja de ser una curiosidad y empieza a tener sentido económico. Cloudflare OS es esa apuesta, reintentada con mejor timing y mejor infraestructura.

En ese mismo posteo, Varda hace una afirmación más grande de lo que podemos confirmar de forma independiente: que dentro del sandbox de un Gadget, "the AI cannot introduce a significant security bug." Nunca intentamos que un agente escribiera un exploit, así que tratá esa frase puntual como una afirmación del proveedor, no como algo que este artículo verificó.

Cómo funciona por dentro

Acá es donde el nombre "OS" deja de ser marketing y se vuelve una analogía técnica defendible. El README lo formaliza:

La mecánica real, pieza por pieza:

Cada espacio de trabajo es un Durable Object: el mecanismo de Workers para estado persistente con identidad única. Cada Gadget corre en un Dynamic Worker Facet: un worker que se levanta al vuelo, aislado, con su propia base de datos SQLite. No hay un servidor de aplicación compartido: hay miles de micro-instancias, una por documento, levantadas bajo demanda.

El cliente y el servidor de cada Gadget se comunican por Cap'n Web, un sistema de RPC basado en capacidades. Esa decisión aparentemente técnica trae una consecuencia enorme: como toda la interfaz de un Gadget pasa por RPC tipado, cualquier app que construyas tiene automáticamente una API amigable para agentes. Sin servidor MCP que escribir, nada que integrar: si vos podés usar tu herramienta, tu agente también.

El agente es un Code Mode agent: en lugar de encadenar llamadas a herramientas una por una, escribe fragmentos de código y los ejecuta de inmediato. La afirmación de Cloudflare es que por eso, con los mismos modelos de base, su agente completa tareas con menos tokens que un agente de programación de propósito general.

La red está cerrada por defecto. El código del servidor de un Gadget corre en Dynamic Workers con la red saliente global deshabilitada; el código del cliente corre en frames de navegador en sandbox. La única conectividad externa es la que entra explícitamente como una capability. Eso no es una política que alguien configura. Es la arquitectura.

Varias funciones del runtime de Workers (Dynamic Workers, Facets) se agregaron a la plataforma específicamente para dar soporte a Cloudflare OS. Leer este repositorio es, literalmente, ver cómo el equipo que construyó Workers piensa que Workers debería usarse.

Qué son los Gadgets, y por qué cambian el modelo de software

Cuando creás una presentación en Cloudflare OS, no estás usando un SaaS de slides compartido. El sistema crea una instancia privada del software de slides solo para vos, en su propio sandbox. Eso es un Gadget.

Dos consecuencias que el README plantea sin rodeos:

1. El software no puede filtrar tus datos por un bug propio, porque el sandbox controla todo el acceso a tu instancia. La falla clásica de seguridad del SaaS multi-tenant, un usuario viendo los datos de otro, deja de existir estructuralmente.
2. Podés modificar el código libremente. ¿Le falta una función a la app de slides? Pedile a tu agente que la agregue. Y como el punto 1 sigue aplicando, hacerlo es seguro.

Los Blueprints son el equivalente a las plantillas de oficina, con una diferencia: una plantilla de Word es contenido; un Blueprint es una aplicación completa. Compartís el Blueprint de tu Gadget y quien lo recibe obtiene una copia independiente, sin tus datos, tu historial de conversación, ni tus credenciales. Después puede pedirle a su propio agente que la modifique, sin pedirle permiso a nadie. Probamos esa independencia de punta a punta: la copia tiene su propio workspace, su propio archivo de base de datos en disco, el medidor de costo en cero, y nada del historial de chat del original. Se sostiene.

Es la inversión exacta de los últimos 25 años de SaaS: en lugar de mil usuarios en una app centralizada que evoluciona por roadmap, mil copias personales que evolucionan por conversación. Si eso escala es una pregunta abierta. Si es la idea más interesante del lanzamiento, no.

Qué son los Gatekeepers, y qué problema resuelven realmente

Los Gatekeepers son el framework de seguridad, y ahí está la innovación más citable del lanzamiento.

Cada servicio externo tiene su propio Gatekeeper: un Worker independiente que envuelve la API nativa del servicio, maneja la autenticación, acota el acceso al recurso específico que el usuario quiso dar, y registra cada acción para poder revisarla. La credencial nunca toca al agente ni al código que genera. Vive dentro del Gatekeeper. El repositorio trae dieciséis servicios Gatekeeper en total. Doce aparecen como conectores en una instancia nueva (GitHub, Google, Slack, Notion, Linear, Confluence, Supabase, Home Assistant, Spotify, ZoomInfo, un conector MCP Server, y Email), un decimotercero (MCP Portal) aparece cuando un operador configura uno, y los tres restantes (Cloudflare mismo, un Scheduler, y una Context Library) trabajan en segundo plano sin pedirte nunca que conectes nada.

El rango entre ellos es lo bastante amplio como para importar. El conector de Slack es de solo lectura por diseño: puede buscar y leer canales, DMs e hilos, pero no hay ningún método en todo el conector que pueda publicar. El de Google es el otro extremo: Gmail, Docs, Sheets, Calendar, y BigQuery en un solo conector, y el scope de Gmail realmente incluye enviar correo en tu nombre. Home Assistant llega más lejos que cualquiera, al mundo físico: puede llamar servicios sobre luces, termostatos y cerraduras reales. Nada de eso es una crítica en sí misma, ya que cada una de esas acciones sigue pasando por la misma cola de aprobación, pero vale la pena saber qué Gatekeeper le estás dando a un agente antes de dárselo.

El modelo de permisos es basado en capacidades y zero-trust: un agente arranca sin acceso a nada, y cada recurso llega como un permiso explícito y tipado. El sistema también registra cada recurso que un agente observa, y esas observaciones quedan pegadas a lo que sea que produzca. Probamos esto directamente, y es lo más convincente de toda esta investigación.

Armamos un dashboard de issues apuntando un agente a un repositorio privado, y después compartimos el workspace con una segunda cuenta que no tenía ninguna conexión propia a GitHub. Abrir el link no entregó el dashboard. Abrió una pantalla de Verify your access que listaba cada recurso conectado por nombre y dejaba el botón "Verify and open" deshabilitado hasta que la segunda cuenta conectara su propio acceso a GitHub a cada uno. Nada del acceso del publicador se transfiere. El destinatario tiene que probar permiso independiente antes de que el workspace se abra siquiera, que es exactamente el mecanismo necesario para que compartir el resultado de un agente no se convierta en una filtración de datos silenciosa.

Y después está la pieza que resuelve un problema que cualquiera que use agentes reconoce al instante: la aprobación asíncrona. El human-in-the-loop tradicional es síncrono: el agente quiere hacer algo sensible, se detiene, y espera. Le das una tarea, te vas a tomar un café, y volvés para encontrarlo frenado en el primer paso. La consecuencia práctica es conocida: la gente termina cediendo y activando la auto-aprobación, el infame --dangerously-skip-permissions, que es exactamente lo inseguro.

Los Gatekeepers hacen algo distinto: cuando el agente pide una acción que necesita aprobación, el Gatekeeper simula el resultado localmente y deja que el agente siga. Al pedirle que abriera un issue en GitHub, un agente que probamos respondió de inmediato con un ID provisorio marcado con una tilde, "Provisional ID: ~1 (will be rewritten to the real GitHub issue number once the gatekeeper finishes creating it)", y razonó en voz alta sobre qué podía y no podía hacer con seguridad con un ID que todavía no era real. Cuando volvés, trabajás sobre una cola de actividad: una acción por línea, de más vieja a más nueva, con botones Approve y Deny. No hay aprobación en bloque ni selección múltiple, algo que el discurso sugiere pero la interfaz no ofrece en realidad. Una pestaña separada de Auto-approval te deja marcar un tipo de acción específico como siempre-seguro de ahí en más, una función relacionada pero genuinamente distinta.

Tampoco es incondicional. Pedir una conexión completamente nueva frena todo: el compositor se bloquea con "Set up or deny the connection request above to continue" hasta que un humano decide. Y un puñado de Gatekeepers, los que no pueden simular un resultado con seguridad, como una sentencia SQL cruda contra una base de datos, marcan sus acciones como necesitadas de una decisión real antes de que el agente pueda seguir, en lugar de simular y continuar. La aprobación asíncrona es la opción por defecto acá, no una garantía: se sostiene exactamente hasta donde el autor de cada Gatekeeper estuvo dispuesto a construir una simulación convincente.

Qué podés hacer hoy

El README arranca con tres ejemplos, así que construimos los tres y los cronometramos.

El tablero de tic tac toe se veía bien pero nunca mostraba un movimiento. El código de cliente que escribió el propio agente había pasado un objeto plano donde la capa de RPC de la plataforma requería uno tipado, así que la suscripción a actualizaciones en vivo falló en silencio. La excepción del navegador se capturó automáticamente; devolvérsela al agente produjo un diagnóstico correcto y un arreglo de una línea, después de lo cual el tablero funcionó de punta a punta.

La pizarra es el resultado más honesto. La primera versión produjo código que, al inspeccionarlo, era completamente correcto, una pizarra colaborativa completa y funcional, salvo que nada en el código llamaba a su propio punto de entrada, así que en silencio no hacía nada. La reconstruimos desde cero unos días después y falló de nuevo, distinto: esta vez dibujaba perfecto en pantalla pero la sincronización en tiempo real nunca llegaba al servidor, así que un reload borraba cada trazo. Las dos veces, el resumen que dio el propio agente describía una app terminada y funcionando.

Jugar tic tac toe contra el agente funciona exactamente como se promete, y a través de la API real del Gadget en lugar de un caso especial, que fue lo más impresionante que vimos en toda la semana. También tiene cero conciencia de que el tablero cambió a menos que se lo digas: hacés un movimiento, esperás sesenta segundos, y ahí se queda. Tenés que decirle "tu turno" cada vez.

El ejemplo de las slides es el que usó un Blueprint prearmado en lugar de escribir código desde cero, y se nota: una presentación con estilo en 9 segundos, y personalizarla en una plantilla real de 7 diapositivas para una reunión con cliente costó $0.24, un orden de magnitud más que cualquiera de las dos apps desde cero, casi todo gastado en pulido, no en plomería.

"Just ask for an app" es el discurso central de todo este lanzamiento. Por lo que vimos, es cierto unas dos terceras partes del tiempo, y cuando falla, generalmente falla en silencio, no a los gritos.

Eligiendo un modelo

Cloudflare OS no viene con un modelo. El segundo paso del onboarding arranca con "No models configured yet," y nada aguas abajo, ni el agente, ni un Gadget, ni un Blueprint, funciona hasta que agregás uno.

Lo que ves después depende de cómo está desplegada la instancia. En modo directo, un desplegable ofrece nueve presets en cuatro proveedores, dos de Workers AI de Cloudflare, tres de Anthropic, tres de OpenAI, uno de Google, más una quinta opción, Ollama, para cualquier otra cosa. Elegís un preset y el diálogo revela los campos de credenciales que necesite ese proveedor. Elegís Anthropic u OpenAI en particular y hay un campo extra discreto, un override de API URL, que te deja apuntar un modelo preset a un proxy, el propio AI Gateway de Cloudflare entre ellos, en lugar del proveedor directamente. En modo gateway, todo ese trámite desaparece: los modelos habilitados por el operador quedan simplemente listados, preseleccionados, sin ningún campo de credenciales.

En cuanto al precio, las tarifas publicadas ponen a Claude Sonnet 5 en $2 / $10 por millón de tokens de entrada y salida, y Anthropic confirmó que ahora es permanente, no la tarifa introductoria que un aumento programado para septiembre iba a reemplazar. El propio Kimi K2.7 Code de Cloudflare sale más barato todavía, $0.95 / $4.00, el modelo menos costoso de la lista que realmente está hecho para programación agéntica. Combinado en un turno realista de 1M de entrada y 100k de salida, Kimi queda en unos $1.35, GLM 5.2 (la otra opción de Cloudflare) en unos $1.84 sin soporte de visión y peor precio en ambas puntas, y Claude Opus 5 en unos $7.50 para los problemas que lo justifiquen. GPT-5.6 Sol, la opción más cara que calculamos, sale a unos $14.50 por el mismo turno en cuanto cruzás el umbral de contexto largo de OpenAI, que un loop de agente con contexto completo cruza de inmediato.

Dos detalles a saber antes de elegir uno. Kimi K2.7 Code, el modelo al que Cloudflare OS te apunta primero, necesita un plan pago de Workers; se niega directamente en el nivel gratuito. Y todo modelo de Cloudflare tiene su output limitado por la propia app a 32.768 tokens sin importar lo que permita el proveedor, porque Workers AI cobra la respuesta contra la misma ventana que el prompt, y Cloudflare OS reserva ese espacio de antemano en lugar de arriesgarse a que se rechace el pedido.

Cómo arrancar de verdad

Tres rutas, de menor a mayor compromiso, y acá es donde este artículo más se aleja de lo que realmente vas a ver, porque el enfoque del README describe el comando, no la experiencia.

Local, y de verdad es rápido. Con pnpm instalado:

pnpm run-local

En un clon limpio esto se instala en unos 30 segundos (14 segundos la instalación en sí, 216 MB descargados, más unos 17 segundos para compilar el frontend) y sirve en http://localhost:8787 sin prompt de login, sin pregunta de telemetría, sin conflicto de puerto. La sorpresa real es el espacio en disco: node_modules queda en 1.1 GB.

Lo que ese medio minuto te da es una instancia corriendo y una cuenta vacía, no un agente funcionando. No hay tour de bienvenida: la landing page es una pantalla de login simple, y crear una cuenta no pide nada más que usuario y contraseña.

Registrarte te tira directo a un wizard de cuatro pasos: un perfil con un nombre para mostrar prellenado desde tu usuario, un modelo que tenés que agregar vos mismo (nada más allá de este punto funciona sin uno), un paso de conexión de Gatekeepers, y después el workspace en sí. Todos los pasos son saltables menos el del modelo.

Desplegado en tu cuenta de Cloudflare, desde os.cloudflare.app/deploy. También vas a querer Cloudflare Access para autenticación y AI Gateway para el ruteo de modelos, que es también lo que desbloquea límites de gasto reales por usuario, algo que ni la instancia local ni un despliegue básico te dan por su cuenta.

Genuinamente autohospedado: el runtime de Workers, workerd, es de código abierto, y Cloudflare OS puede correr enteramente sobre él en tus propios servidores. Que esté construido sobre Workers no significa que solo corra en Cloudflare, aunque seamos honestos: la experiencia de primera clase está en su nube, y esa es la lógica comercial de darte el software gratis.

Si estás configurando esto en Windows específicamente, seguí leyendo, porque ninguno de los tiempos de arriba va a coincidir con tu experiencia.

Windows específicamente

El problema de Windows en Buzz, cuando escribimos sobre eso, fue un solo prerequisito faltante que fallaba en silencio. El de Cloudflare OS es peor, y vale la pena repasarlo completo porque la tabla comparativa más abajo se queda corta.

En una instalación limpia de Windows 11 sin nada previo, pnpm run-local no tropieza una sola vez. Falla cuatro veces distintas en secuencia, y solo la primera está documentada en algún lado:

1. corepack enable se niega a correr sin permisos de Administrador, y el error nombra el binario equivocado (pnpx, no pnpm), así que el arreglo real, correr esto elevado, no se puede deducir del mensaje.
2. La primera descarga real de pnpm espera un prompt invisible. Corepack hace una pregunta sí/no que nunca se renderiza si tu terminal captura la salida en lugar de mostrarla en vivo. Vimos una terminal quedarse en blanco por más de tres minutos, sin error, sin timeout, resuelto en el instante en que alguien apretó Enter.
3. workerd mismo no corre. Windows no trae el runtime de Microsoft Visual C++, Cloudflare OS lo necesita, y nada en las instrucciones de setup lo menciona. La instalación tampoco falla: pnpm install imprime "Failed to validate workerd binary... Local development will not work" dos veces, enterrado en medio del log, y termina con código de salida 0 como si no hubiera pasado nada.
4. Una vez arreglado eso, el comando de quickstart de una línea todavía no se puede correr solo. Node se niega a lanzar el propio ejecutable de Windows de pnpm sin una flag que el script no pasa, un efecto secundario de un fix de seguridad de 2024, así que la instalación tira "file not found" para un comando que funcionó bien una línea antes en la misma terminal.

Sorteás las cuatro a mano y llegas más lejos, pero no del todo: el build llega a su último paso propio y crashea con un desborde nativo de buffer de stack, cero output, el puerto 8787 nunca se abre. Los mismos comandos en Linux llegan a un servidor corriendo en unos 30 segundos, al primer intento.

La única buena noticia: ningún aviso de SmartScreen en ningún momento, porque los dos instaladores llevan firmas de publicador válidas. Lo que aparece en cambio: tres prompts idénticos de Control de Cuentas de Usuario, dos esperables (los instaladores de Node y Git), y un tercero más interesante, disparado por el propio proceso de setup de Cloudflare OS, porque escribir en Program Files necesita elevación y el README nunca lo dice.

Pros y contras, sin filtro

A favor:

• La arquitectura de seguridad más seria que se lanzó en esta categoría: capabilities en lugar de ACLs, credenciales aisladas del agente, red cerrada por defecto, observaciones pegadas a los resultados, y aprobación asíncrona. Probamos la afirmación de compartir directamente, con una segunda cuenta y cero acceso prestado, y se sostuvo. No es una lista de promesas. Es diseño estructural.
• Genuinamente Apache 2.0, con una vía de escape real vía workerd.
• Dogfooded a escala antes del lanzamiento: toda la plantilla desde mayo, miles de usuarios no técnicos a diario.
• Los Gadgets con APIs automáticas para agentes resuelven algo que en cualquier otra plataforma significa escribir un servidor MCP.

En contra:

• Es acceso temprano y lo dicen: desarrollo intenso, aristas reconocidas, una v2 reescrita desde cero.
• Los ejemplos insignia no funcionan de forma confiable. Dos de las tres demos del propio README fallaron al primer build en nuestras pruebas, una con un bug que se auto-reparó al mostrarle su propio error, otra en silencio, dos veces, por dos causas sin relación.
• El sandbox no es magia. La crítica más filosa del hilo de Hacker News: "the AI cannot introduce a significant security bug" solo es cierto mientras la app no pueda afectar nada fuera de su sandbox, y las apps útiles eventualmente necesitan tocar cosas de afuera. La respuesta del diseño son los Gatekeepers, pero el trade-off entre seguridad y utilidad no desaparece; se traslada a la calidad de cada Gatekeeper.
• Windows realmente no funciona de entrada. Cuatro fallas separadas antes de un servidor funcionando, y un crash nativo esperando al final de arreglar las cuatro a mano.
• La gravedad hacia Cloudflare es real. Correr sobre tu propio workerd es posible; toda la comodidad (Access, AI Gateway, despliegue de un clic) vive en su nube. Es lock-in suave, pero es lock-in.
• El nombre. Medio hilo de Hacker News eran personas molestas porque "OS" no significa esto. Tienen razón, y no importa: el nombre va a quedar.

Cloudflare OS, Buzz, un agente personal, ¿o Copilot?

Agosto de 2026 deja cuatro respuestas distintas a "¿dónde viven mis agentes?", y no compiten cara a cara:

La comparación con Buzz es la interesante, porque salieron con quince días de diferencia y apostaron a cosas opuestas: Buzz pone a los agentes en la conversación (el canal es el registro); Cloudflare OS los pone en el trabajo (la app es el registro). Buzz te da soberanía a través de un protocolo abierto (Nostr, tu propio relay); Cloudflare OS te da seguridad a través de una plataforma (capabilities, sandboxes de Workers). En Hacker News ya se podía encontrar a alguien diciendo que Buzz es la dirección más razonable, y a alguien argumentando lo opuesto por lo serio del modelo de seguridad. Todavía no hay veredicto; hay dos filosofías bien ejecutadas.

El veredicto

Cloudflare OS es dos cosas a la vez, y después de una semana de usarlo de verdad, merecen notas todavía más separadas que el primer día.

Como producto, es más áspero de lo que el encuadre de "acceso temprano" suele admitir. Windows no solo tiene aristas, directamente no funciona sin cuatro arreglos separados y todavía crashea después de eso. Dos de las tres demos insignia fallaron al primer build. Si necesitás esto corriendo para 200 personas mañana, no es una situación de "esperá dos o tres versiones", es una situación de "esperá y mirá específicamente la historia de Windows".

Como conjunto de ideas, la semana no cambió el veredicto, lo reforzó. La prueba de compartir y verificar que hicimos, una segunda cuenta con cero acceso frenada en seco hasta probar permiso independiente, es la evidencia más convincente de toda esta investigación de que el modelo de seguridad no es solo marketing. La aprobación asíncrona con resultados simulados resuelve la razón real por la que la gente apaga la seguridad de sus agentes. Y cuando un Gadget se rompe, que pasa más seguido de lo que el discurso sugiere, generalmente se rompe en silencio en lugar de a los gritos, que es en sí mismo un dato honesto sobre dónde esta categoría todavía tiene trabajo por hacer.

Nuestra recomendación se mantiene, con un agregado: corré esto localmente esta semana si estás en macOS o Linux, porque de verdad es rápido, leé la sección de Windows de arriba dos veces antes de probarlo ahí, y tratá los ejemplos de demo como una moneda al aire, no como una garantía. Las ideas valen tu tiempo de todas formas. La plataforma, esta semana, todavía se lo tiene que ganar.

Sacarle valor real a un sistema como este premia el oficio de un AI prompt engineer: pedidos precisos, contexto curado, saber cuándo el modelo se equivoca. Y alguien tiene que diseñar las capabilities, escribir los Gatekeepers, y supervisar a los agentes, ese es exactamente el trabajo de un ingeniero de IA, un rol cuya demanda sigue fortaleciéndose a medida que las empresas incorporan agentes al trabajo diario. Si querés pasar de leer sobre estos sistemas a construirlos, el programa de carrera de Ingeniería en IA de 4Geeks Academy forma desarrolladores en este stack desde el primer día: proyectos reales, mentoría en vivo, y acompañamiento hasta la contratación.

Publicado el 6 de agosto de 2026. Actualizado el 14 de agosto de 2026 después de una semana de pruebas prácticas: instalaciones en local y en Windows limpio, los tres ejemplos del README, configuración de Gatekeepers, aprobación asíncrona, y el flujo de compartir y verificar. Fuentes: el repositorio oficial, el anuncio técnico de Cloudflare, el comunicado de prensa, el posteo de Kenton Varda, la discusión en Hacker News, y pruebas de primera mano contra el commit 8a198d0.