On August 5, Cloudflare open-sourced a new version of "Cloudflare OS," the AI work environment it has deployed internally. Beyond generating documents and slides from browser-based conversations, the system can create apps that leverage internal context and systems, and run them on-demand, on schedule, or triggered by events.
The key point of this announcement isn't that it added more entry points for AI chat. Rather, it's that the app execution platform now records which resources an agent has viewed and carries that authorization forward into subsequent sharing, app operations, and writes to external services.
Despite the name, Cloudflare OS is not a traditional computer OS. It's an environment where a company's terminology, procedures, and systems become the agent's context, allowing employees—including non-engineers—to build small apps tailored to their own work.
From Internal AI Tool to a Work Platform Anyone Can Customize
In May, Cloudflare gave all employees access to the initial version of Cloudflare OS. According to the official blog, thousands of employees—including many outside engineering—now use it daily to create documents and slides, automate repetitive tasks, and build small apps that visualize data.
The initial version centered on private individual workspaces, running static apps and skills through an agent. Even for routine tasks, having the agent perform the same job every time meant burning inference tokens just to produce similar reports repeatedly. Cloudflare explains that while an MCP server shows what tools an agent can use, it doesn't show what resources the agent actually observed. Maintaining authorization for shared access requires a separate record.
V2 rebuilds this foundation. According to Cloudflare's official explanation, the system consists of three components: an agent workspace, a security and governance framework, and apps that individuals can modify. Starting from a conversation, users can progress to documents and spreadsheets connected to live data, multi-user apps, and code-centric workflows for handling fixed processes.
The results of internal use go beyond a mere demo. Cloudflare's CIO estimates that the sales department saved over 10,000 hours from manual work in the past 30 days alone, and reports that more than 4,000 apps and tools were created during that period. This is Cloudflare's own estimate and self-reported figure, not a measurement demonstrating that other companies would see the same results. Still, it illustrates why Cloudflare chose a design where each department multiplies apps at the level of individual tasks, rather than a SaaS model where users are limited to fixed features.
Authorization That Follows the Observation Record
In Cloudflare OS, neither agents nor generated apps have any access by default. Cloudflare Access controls the user's entry point, while internally, specific resources are introduced one at a time. Granted resources are passed to code as typed bindings, keeping the credentials themselves isolated from the agent and generated code.
Sitting between the system and external services is the "Gatekeeper." A per-service Worker handles OAuth and sets up narrow connections—for example, with GitHub, limiting access to specific repositories or read-only issue access. As needed, it hides fields, applies rate limits, and logs both reads and operations that cause side effects on external systems. This is a fundamentally different placement of responsibility compared to designs that hand an agent a full API key for an entire service.
The scope of authorization doesn't stop at the initial read. If an agent reads a sensitive table and generates a dashboard from it, anyone the dashboard is shared with also needs permission for the underlying data. Cloudflare OS records the resources an agent has observed, and when another user opens a workspace, agent, or output, it uses that observation record to re-verify access.
This design avoids simply passing the app creator's permissions directly to collaborators. Depending on the nature of the observed data, it can also inform decisions to block writes to other data sources, collaboration, or external requests. The technical distinction of Cloudflare OS lies in expanding the unit of authorization from "who invoked the agent" to "what the agent actually observed."
A Worker-Based Platform for Multiplying Apps
Apps built with Cloudflare OS aren't prototypes exported as files and deployed elsewhere. They're built as full-stack apps with a browser-based client, a stateful server, an API, and persistent data.
The server side loads on demand as a Dynamic Worker, with each execution unit running as a Durable Object Facet. Each app is assigned an isolated SQLite database, so state doesn't mix with other apps. The client and server connect via Cap'n Web RPC, allowing both the browser and agents to call the same API.
This architecture removes the assumption that adding an app requires standing up a dedicated server. Moreover, even when AI is used to modify an app's code, the platform itself continues to manage the boundaries of the execution environment and external access. This allows internal tools built by AI to be used within a limited scope of work before being promoted to a service maintained by a dedicated development team.
Sharing works in two ways. Sharing the app itself lets multiple people work with the same state, while sharing a Blueprint lets each person create their own copy based on just the code. Copies don't inherit SQLite data or conversation history, and credentials and connected resources are also isolated. Beyond distributing templates, this is a mechanism that lets users customize apps using their own permissions and data.
Model Selection and Budget Management via AI Gateway
Inference passes through Cloudflare AI Gateway. Cloudflare OS isn't locked to a specific model provider—organizations decide which models are available and can route different tasks to the most suitable model. This makes it an operational setting to avoid sending simple summaries or routine tasks to the most expensive models.
AI Gateway ties requests to the person, team, and workspace that made them, allowing visibility into which user's work incurred which costs. Administrators can set budgets and rate limits and decide what happens when limits are reached. Cloudflare's documentation, published the same day, also describes a configuration where Access authentication is carried into AI Gateway, attaching a user ID to each request.
Here too, the change from v1 isn't simply adding more AI. In Cloudflare's internal usage, instead of having the agent handle routine report generation every single time, the agent writes code that embeds the logic directly into an app. Fixed procedures are handled by code, and the model is only called where judgment is genuinely needed—an approach designed to reduce the cost of repeating the same task.
Open Source, But Adoption Still Starts With Operational Design
Cloudflare has published both the core Cloudflare OS repository and a starter repository for adoption, modeled on its internal configuration. The core repository's top-level LICENSE is Apache License 2.0. Company-specific screens and context—along with Gatekeeper and connection settings, model configuration, and deployment pipelines—can be layered on top without directly modifying the core.
That said, the published code isn't being marketed as a finished product. The GitHub README explicitly labels the August 2026 version as early access, noting that development is active and rough edges remain. Local execution is intended for trial use, not production.
Deploying to a Cloudflare account also requires Node.js 24 and pnpm 11, along with various Workers-related services. The starter uses KV and R2, and also requires Browser Rendering and Dynamic Worker Loaders. AI products are optional, but there's still work required to set up sign-in via Access, configure OAuth for external services, and establish Gatekeeper, logging, and data retention policies. Simply obtaining the code doesn't automatically align it with a company's permission model or internal canonical context.
Running it on your own servers requires even more caution. While Cloudflare OS is designed to run on workerd, the open-source Workers runtime, the repository currently marks the documentation and tooling for this path as "Coming Soon." At present, the only well-supported adoption paths are deploying to a Cloudflare account or running it locally for trial purposes.
Cloudflare plans to offer a fully managed version accessible from a dashboard, containers for development workflows, and integrations with chat tools like Slack going forward. The success of Cloudflare OS will ultimately depend not on the number of apps created, but on whether each organization can translate its own data boundaries into Gatekeeper configurations and observation records, and successfully operate this early-access implementation.