Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/cloudflare/cloudflare-os/llms.txt

Use this file to discover all available pages before exploring further.

Cloudflare OS revolves around a fundamentally different model of software delivery: instead of everyone connecting to one shared SaaS application, every user runs their own private instance of each app. That private instance is called a Gadget. A Gadget is a small, AI-generated personal application — complete with its own server code, client UI, SQLite database, and bindings to external services — running in a dedicated sandbox that belongs entirely to you.

​
Every user runs their own copy

Traditional cloud software runs on one server that every user shares. If that server has a security bug, all users are exposed. If you need a feature the vendor has not built, you file a ticket and wait. Gadgets flip this model on its head. When you ask the Cloudflare OS agent to “make a slide deck for my Q3 planning meeting,” the system does not hand you a login to some shared slide-deck service. It creates a private instance of slide-deck software specifically for your data, just for you. The analogy to traditional office software is intentional — just as you own your own copy of a Word document, you own your own copy of the Gadget. This has two immediate consequences:
  1. Isolation by default. There is no mechanism by which a bug in your Gadget could expose another user’s data, because no other user’s data is in the same sandbox.
  2. Freedom to modify. Because you own the code, you can ask the agent to add any feature you want. No feature requests, no waiting.

​
Sandbox architecture

Gadgets run in a two-layer sandbox that isolates both the server-side and client-side code. Server layer — Dynamic Worker Facet The Gadget’s server code runs inside a Dynamic Worker Facet — a lightweight, per-Gadget Workers instance. The Facet has its internet access disabled by default. It can only communicate with resources you have explicitly authorized via Workers Bindings. This means a Gadget cannot exfiltrate your data to an arbitrary server even if the agent wrote malicious code. Client layer — sandboxed iframe The Gadget’s UI runs inside a sandboxed <iframe>. The iframe communicates with its server exclusively through a Cap’n Web RPC session delivered over postMessage() from the parent Workshop frame. No other network access is permitted from the iframe — Content-Security-Policy headers and iframe sandbox attributes block it at the browser level. 
User browser
  └── Workshop frame (authenticated)
        └── Gadget iframe (sandboxed)
              └── postMessage ──► Cap'n Web RPC ──► Gadget Durable Object (no internet)

​
What a Gadget contains

Each Gadget is a self-contained workspace backed by a Durable Object:
ComponentDetails
Source codeStored as a Yjs collaborative document — a map of filenames to Y.Text instances
SQLite storagePrivate to this Gadget; not shared with other users or Gadgets
BindingsNamed connections to Gatekeepers (external services), AI models, and agent spawners
Chat historyAll agent conversations that created or modified this Gadget
A Gadget’s source code is stored as a Yjs document, not flat files. This means the code is collaborative by default — multiple editors and the AI agent can apply changes concurrently. Each file is a Y.Text entry inside the workspace’s shared Yjs doc. When you create a Blueprint from a Gadget, a point-in-time snapshot of this document is captured and stripped of its edit history.

​
Multiplayer and real-time collaboration

Because every Gadget is backed by a Durable Object, real-time multiplayer is built in — the coding agent simply implements it by default, without being asked. When collaborators open the same Gadget, they see each other’s presence and edits live. Sharing follows a capability-based model: each collaborator must have their own connected account for every external service the Gadget accesses. Gatekeepers verify this access before granting the collaborator an observer role, ensuring that sharing a Gadget never leaks data the collaborator could not access directly. See Sharing and Collaboration for the full flow.

​
Creating Gadgets

Gadgets are created in two ways:
1

Chat with the agent

Open a new workspace and describe what you want. The agent writes the server and client code, tests it, and debugs any errors. The Gadget remains provisional until you accept the agent’s proposed changes.
2

Instantiate a Blueprint

Open a Blueprint link (e.g. https://<host>/blueprint/<id>) and click Create Gadget. You assign any required bindings (external accounts, AI models, spawners) and a fresh Gadget instance is created from the Blueprint’s code snapshot — with its own empty SQLite storage and chat history.

​
Learn more

Blueprints

Capture a Gadget’s code as a reusable template anyone can instantiate.

Gatekeepers

The security layer that controls how Gadgets access external services.

Build docs developers (and LLMs) love

Get started for freeTalk to us