Cloudflare OS

Cloudflare OS is not a conventional operating system and not a simple chatbot with enterprise connectors. It is an open-source AI productivity environment originally built for Cloudflare’s own workforce, combining an agent chat surface, isolated AI-built applications called Gadgets and a capability-based integration/security layer called Gatekeepers.¹² Cloudflare’s stated intent is that organizations copy and customize the project into their own “company OS” rather than subscribe to one centrally hosted Cloudflare-controlled workspace.¹

The Gadget model is the most distinctive product idea. When a user asks the agent to build something such as slides, a whiteboard, a dashboard or another workflow app, Cloudflare OS creates a separate application instance for that user rather than calling a centralized SaaS instance shared by everyone.¹ Gadgets can be edited through AI, shared with collaborators and derived from reusable Blueprints. Because each instance has its own code and state boundary, the product is closer to an AI-generated internal-app platform embedded in an office workspace than to a fixed collection of documents and spreadsheets.

Every Gadget is backed by Cloudflare runtime primitives and exposes an agent-friendly API through Cap’n Web RPC. The agent can therefore continue interacting with an app after creating it instead of treating code generation as the end of the workflow.¹ This matters operationally: an agent can build a ticket dashboard or proposal tool and then use the same app’s methods later, allowing deterministic software to take over work that would otherwise burn model tokens every time it runs.

Cloudflare’s own internal story makes that deterministic-software shift explicit. The company says its first version leaned heavily on repeated inference sessions and skill files; v2 moves more work into code generated once and run repeatedly, with AI inserted only where judgment or generation is needed.³ One internal example turns help-desk reporting into a secure app that queries the source system through a Gatekeeper, renders routine metrics without inference and invokes AI only for tasks such as drafting responses.³ This is a stronger productivity architecture than sending the same deterministic workflow back through an LLM every morning.

Gatekeepers are the second major differentiator. They sit between agents/Gadgets and outside systems such as GitHub, Google, Cloudflare, Supabase, Notion, Confluence, Slack, Home Assistant and other supported services.¹ A Gatekeeper wraps the external API, handles authorization, scopes the resource that can be accessed, logs actions and mediates side effects. The default access philosophy is capability-based: agents and Gadgets begin with no ambient access and must be explicitly introduced to the resource they need.¹

The human-approval design is unusual. Instead of forcing an agent to stop synchronously whenever an external side effect needs permission, a Gatekeeper can simulate the result, let the agent continue planning on that provisional state and queue the real actions for later approval or rejection.¹ This addresses the common failure mode in which users enable dangerous blanket auto-approval simply because synchronous confirmation makes long tasks unusable. It introduces a different trade-off: downstream reasoning can depend on simulated actions that the human later rejects. An outside technical review specifically highlighted that as an innovative but genuine risk-model choice rather than an obviously superior default.⁴

The security boundary around Gadget code is also ambitious. Server-side Gadget code runs in a Dynamic Worker with normal internet access disabled; it can reach designated resources only through bindings. Client code runs in a sandboxed iframe with network access constrained through browser sandbox/CSP mechanisms and communicates with its server through a parent-provided RPC channel.¹ This means AI-generated application code is not intended to inherit the broad network and credential privileges of the host workspace.

The current v2 release also supports a general-purpose Code Mode agent that can perform tasks directly without creating a Gadget, multiple model providers/self-hosted models, real-time multiplayer collaboration and Blueprints for distributing reusable app code.¹ The product therefore spans three overlapping roles: company-context agent workspace, governed no-code/internal-app builder and runtime for agent-created software.

The deployment starter makes enterprise customization much more concrete than the bare repository. Organizations can pin an upstream Cloudflare OS version, configure their own hostname and Cloudflare Access identity boundary, choose administrators, control connector availability, attach existing storage, customize Gatekeepers, configure observability and decide when to upgrade.⁵ AI is disabled by default in the starter until the deployer chooses Workers AI, AI Gateway or another model path, which is a good infrastructure default because installing the workspace does not automatically activate an uncontrolled model relationship.⁵

The product is nevertheless explicitly unfinished. Cloudflare labels the August 2026 repository “early access,” describes v2 as a complete rewrite of v1 and says it still has many rough edges.¹ The local `pnpm run-local` route is for evaluation rather than production, and while the code can run on the open-source `workerd` runtime, turnkey own-server production deployment documentation is still marked as coming soon.¹ Today, the cleanest production path is therefore a deployment into the organization’s own Cloudflare account using the hosted flow or starter wrapper.

Cloudflare OS itself is open-source under the Apache-2.0 license.¹ There is no per-seat Cloudflare OS software subscription in the current open-source release. Calling it “free,” however, is incomplete because a production deployment consumes Cloudflare infrastructure and AI inference, and the organization owns those bills.

The starter repository states that a production deployment requires Cloudflare Workers, KV, R2, Browser Rendering and Dynamic Worker Loaders; AI products are optional until the deployer enables a model path.⁵ Dynamic Workers are currently available only on the Workers Paid plan.⁶ The Workers Paid plan has a minimum account charge of $5 per month.⁷ That $5 is therefore a reasonable infrastructure floor for the standard Cloudflare production route, not an estimate of the total cost of actually operating an active company workspace.

Dynamic Workers add their own usage dimensions. Current pricing includes an allowance for Dynamic Workers created plus request and CPU usage, with additional Dynamic Worker creation charged at $0.002 per Dynamic Worker per day after the included amount; requests and CPU reuse Workers Standard billing.⁶ Because every Gadget runs in a Dynamic Worker, organizations generating many personalized applications should model how application-instance churn translates into that billing dimension rather than assuming an open-source license eliminates runtime cost.

Cloudflare OS also relies heavily on Durable Objects for workspace and collaboration state. Durable Objects are available on free and paid Workers plans, but production usage beyond included allocations is metered across requests, duration and storage.⁷ For a serious deployment, the bill can therefore include Workers, Durable Objects, Dynamic Workers, storage and other enabled platform products before model tokens are counted.

Inference is a separate cost decision. The starter does not force a platform model by default.⁵ If an organization chooses Workers AI, the current service includes 10,000 Neurons per day free and charges $0.011 per 1,000 Neurons above that allocation on Workers Paid, with model-specific unit rates underneath the neuron accounting.⁸ Other providers can be routed through Cloudflare AI Gateway or configured through supported model paths.

AI Gateway’s core gateway features are currently free, but Unified Billing adds a 5% fee when credits are purchased through Cloudflare; provider inference itself is passed through at the provider rate without an additional inference markup.⁹ Teams can also use their own provider billing paths depending on configuration. The important point is that “Cloudflare OS is free” describes the code license, not the total cost of an organization generating thousands of apps and running model-backed workflows.

Cloudflare’s internal usage illustrates why cost architecture matters. The company says v2 intentionally turns recurring workflows into deterministic Gadgets so routine renders and queries do not consume model tokens every time.³ That design can materially improve economics for repeated work compared with a pure agent loop, although the company’s reported savings are not an independent cost benchmark and cannot be generalized to another organization without workload data.

There is no responsible one-number price for Cloudflare OS beyond the infrastructure floor because a small pilot and a company-wide deployment have fundamentally different storage, Dynamic Worker, browser, model and integration usage. Procurement teams should treat Cloudflare OS as deployable software with cloud-variable economics rather than a $X/user/month SaaS product.

Cloudflare OS has an unusual evidence profile: current external review coverage is still sparse, but the open-source repository, first-party operational evidence and several very recent independent technical hands-on reports provide unusually rich evidence for such a new release. No current structured enterprise-review corpus or established exact-product benchmark was located, which is unsurprising given the August 2026 release.

The source repository itself is substantial and inspectable. A current GitHub crawl shows hundreds of commits, thousands of stars, hundreds of forks, an Apache-2.0 license and explicit security-reporting information.¹¹⁰ Open source does not prove secure behavior, but it makes architecture, implementation, test coverage and change history independently examinable in a way a closed enterprise workspace is not.

Cloudflare also provides meaningful internal-use evidence. The company says thousands of Cloudflare employees use the platform each week, daily active users had grown every workday, sales users saved an estimated 10,000 hours of previously manual work in the preceding month, and users created more than 4,000 apps/tools during those 30 days.³ These figures are unusually concrete for a newly open-sourced enterprise AI workspace. They remain first-party estimates from the product’s own creator and should not be read as externally audited productivity gains.

The same internal write-up is valuable because it documents failures and iteration rather than only success. Cloudflare describes its initial mistake of giving non-engineers developer-oriented AI harnesses, which produced excessive “vibe coded” applications without enough focus on jobs-to-be-done; it then used a manually staffed AI email workflow to learn which repetitive tasks employees actually wanted automated.³ That product history increases confidence that Cloudflare OS is built from a real organizational deployment problem rather than a theoretical demo.

Independent hands-on evidence is now emerging. A late-August MrKeyoor review cloned an August 25 commit into a clean Debian sandbox, installed dependencies successfully and built the project successfully.¹¹ Its test run timed out after 900 seconds. The reviewer’s own reporting is internally ambiguous: its measurement summary says 23 tests passed with zero failed at timeout, while the last captured Vitest output reportedly included one failure among a larger set of passing tests.¹¹ Taken together, this supports the conclusion that the codebase is buildable, while test/CI confidence is not yet clean enough to call mature; the ambiguous output does not prove a specific unresolved product defect.

A separate early hands-on review from LLMnet reported running Cloudflare OS locally through Wrangler/workerd and explicitly framed the result as a first impression rather than a long-term production verdict.¹² Another independent deployment/cost review highlighted Gatekeepers as the most reusable design idea even for teams that do not adopt the full workspace, while also identifying documentation drift—for example, an integration present in the source tree but absent from the README’s documented Gatekeeper list.⁴ These findings align with Cloudflare’s own early-access warning: the architecture is ambitious, but documentation and operational polish are still moving.

Public GitHub issues provide concrete rough-edge examples. One early issue reports that reauthorizing a GitHub connection did not recover cleanly from stale credentials and that the tester could not find an obvious account-removal path in the admin UI.¹³ That report does not establish a systemic credential bug, and the author explicitly did not attribute the original credential invalidation to Cloudflare OS. It does show that connector lifecycle and recovery UX are still areas where an enterprise pilot should test failure modes rather than only the happy path.

The security model is more sophisticated than the maturity level. Capability-based default-deny access, isolated Gadget runtimes, explicit resource introductions, action logs and deferred human approval all address genuine agent-security problems.¹ The starter additionally defaults to Cloudflare Access so unauthenticated requests can be stopped before they reach the application Worker, keeps identity/admin configuration outside ordinary runtime-admin controls and advises deployments to pin upstream versions and verify trust boundaries before every production upgrade.⁵

Cloudflare routes vulnerability reports through its existing disclosure/HackerOne process and the repository currently shows no published security advisories.¹⁰ “No published advisories” should not be misread as proof that the new platform has no vulnerabilities. The stronger trust signal is that the project participates in an established public vulnerability-reporting program and exposes its code.

One subtle Gatekeeper risk deserves emphasis. Deferred approval works by simulating side-effect results so the agent can continue. If a user later rejects one of those actions, subsequent reasoning may have been based on a world-state that never becomes real.¹⁴ The design can be safer than blanket auto-approval and more usable than synchronous stop-and-wait, but organizations should test how their workflows reconcile rejected actions and downstream dependencies.

Product Hunt shows that Cloudflare OS launched as the #1 product of the day on August 6 with hundreds of launch votes/points, but the visible 5.0 rating on the Cloudflare Product Hunt page aggregates the broader Cloudflare company/product family rather than Cloudflare OS itself.¹⁴ The launch ranking is useful as awareness/traction context, but the aggregate Cloudflare rating is not valid exact-product rating evidence for Cloudflare OS.

Overall, the available evidence supports moderate confidence despite the absence of a mature structured review corpus. The open source, real internal deployment, concrete independent build tests and multiple hands-on technical reviews provide meaningful substance. The reason confidence does not rise higher is maturity: v2 is weeks old, explicitly early access, production operations are still being documented and no long-duration independent enterprise deployment study is available yet.

Cloudflare OS is best suited to organizations that want employees—not only engineers—to build AI-assisted internal tools while security teams retain explicit control over what those tools and agents can access. The workspace is particularly compelling where company context lives across multiple systems and the problem is not merely “give everyone a chatbot,” but “let people safely automate their own recurring work.”³²

Companies already standardized on Cloudflare are the easiest fit. The production starter assumes Cloudflare Workers, Access, KV, R2, Browser Rendering and Dynamic Worker capabilities and gives operators direct control over identity, routes, storage, observability, Gatekeepers and upgrade cadence.⁵ For those teams, Cloudflare OS can extend an existing platform/security relationship rather than introduce an entirely new infrastructure stack.

The product is also attractive to security-conscious AI platform teams studying permission design. Gatekeepers implement a useful alternative to broad ambient MCP access: each agent or app gets only the specific capability/resource introduced to it, and consequential actions can be logged and queued for review.¹ Even organizations that ultimately build a different workspace may find this architecture worth studying.

Business teams that repeatedly create small bespoke tools are another strong target. Cloudflare’s internal examples include sales planning/proposals and IT ticket workflows, and the company reports thousands of weekly users and thousands of custom tools created internally.³ A team whose needs sit awkwardly between spreadsheets and formal application-development queues may benefit from an agent that turns a natural-language workflow into a private, modifiable Gadget.

Cloudflare OS is less suitable for a small company that simply wants a polished ChatGPT-style enterprise workspace tomorrow. There is no vendor-managed, low-configuration office suite experience equivalent to buying seats and inviting users. Production deployment, identity, model choice, connectors, secrets, observability and upgrades are the adopter’s responsibility.⁵ The project’s own README says early access and rough edges.¹

It is also a weak fit for organizations unwilling to run a pilot before production. Connector authorization/recovery, Gatekeeper behavior, simulated approvals, model routing, Gadget isolation, sharing rules and cost controls all deserve workload-specific testing. The current independent build evidence is encouraging but not a substitute for operating the platform under the adopter’s own identity, data and failure conditions.¹¹¹³

Teams requiring turnkey on-premises deployment should wait or plan their own engineering. Cloudflare OS can run on the open-source `workerd` runtime in principle, but the repository still marks the smooth own-server production deployment path/documentation as coming soon.¹ A Cloudflare-account deployment is currently the supported practical route.

Finally, cost-sensitive teams should not select Cloudflare OS solely because the repository is free. A successful rollout can shift spend from software seats toward Workers, Dynamic Workers, Durable Objects, storage, browser workloads and model inference.⁷⁶ That can be economical, especially when deterministic Gadgets reduce repeat inference, but it is an architecture-specific cost model that must be measured.