What Is Cloudflare OS? Components, Security, Pricing and Setup

What Cloudflare OS is

Despite the name, Cloudflare OS is not an operating system in the sense of Windows or Linux. It is a platform for running AI agents inside a company: a workspace employees log into, plus the machinery that lets those agents reach company systems safely.

Cloudflare has said that several thousand of its own employees already use it internally. It is also an Early Access product that was only published recently, which matters for how you should adopt it. See Rolling it out below.

Why it exists: three walls that stop general-purpose AI tools

Companies adopt a general-purpose AI tool and find that day-to-day work does not get much faster. Three obstacles come up again and again.

1. The AI does not know how your company works. A general-purpose model has never seen your internal vocabulary, your procedures or the quirks of your systems. As long as every session starts by explaining all of that again, the time saved stays small.
2. It cannot reach your internal systems. Real value needs access to the CRM, the databases and the documents. Handing API keys directly to employees or to agents is dangerous, and it makes auditing who did what nearly impossible.
3. The permission boundary blurs. Controlling which tools an AI may use is not enough. Unless you can also trace which data it read, sharing its output internally becomes a route for unintended disclosure.

Cloudflare OS is designed around the idea that these are platform problems, not user-literacy problems, so the countermeasures belong in the platform itself.

The five components

Cloudflare OS is made up of five main parts. Understanding what each one does is usually enough to decide whether the platform fits your organisation.

In use, an employee is authenticated through Cloudflare Access before reaching the workspace. Whenever an agent touches an internal system it goes through Gatekeeper, and every model call goes through AI Gateway, so the organisation can see and control which models are used and how much.

None of this guarantees a no-code experience. Custom integrations still require development work. The official repository is the authoritative reference.

The security model: starting from zero permissions

Cloudflare OS is not designed around allowing everything and then narrowing it down. It starts from a state where nothing is permitted and opens only what is needed.

• Nothing is visible at first. Every agent and app starts with no access. Access to a resource is requested, and an administrator decides whether to allow or deny it.
• Gatekeeper mediates each operation. Fine-grained controls such as read-only access, masking specific fields, or requiring human approval before execution are applied per operation.
• Policy follows what was seen. Resources an agent referenced are recorded and tied to the output. Whether a viewer holds permission on the original data can be verified, and actions such as sending data outward after reading confidential material can be restricted.

These mechanisms do not reduce risk to zero. Prompt injection and mistakes in permission design remain real, which is why a limited, read-mostly deployment is the sensible way to begin.

Gatekeeper in depth: connecting internal data safely

Connecting GitHub, Google Workspace, Notion, your CRM and your internal databases all at once, on the theory that more data makes the AI smarter, is exactly how the line between "may look at this" and "may change this" disappears. Cloudflare OS answers that by never handing an API key to the AI, and putting Gatekeeper between the agent and the system instead.

Gatekeeper is a receptionist for the AI

The official README describes Gatekeeper as close to a hardened MCP server. Its job is broader than exposing an API. It handles five things:

• Connects to the external service as the individual employee, typically over OAuth.
• Converts the API into a shape an agent can work with.
• Narrows permission to the scope you specify, such as one repository or one document.
• Records what was read and which operations were performed.
• Holds back any change that affects the outside world until a person approves it.

Gatekeeper is therefore both the place where the AI is handed a tool and the place where the limits of that tool are set.

You hand over targets, not accounts

A typical AI integration configures an MCP server or API key once, then reuses broad permission for the rest of the conversation. Cloudflare OS inverts this. Agents and Gadgets start with no access to any external service, and the person introduces the specific targets the job needs, one at a time.

The model is not "we connected GitHub, so every repository is now reachable". It is "for this job, use this repository". Cloudflare describes this as capability-based access control: rather than listing users in a permission matrix, you hand over the object the work actually needs.

OAuth scope and what the AI can use are two different things

This is easy to miss. An external service's OAuth screen often shows fairly broad permissions because they are technically required. The published GitHub integration, for example, requests the repo scope at connection time. Gatekeeper then narrows actual use down to the specific repository, issue or pull request that was introduced.

You cannot judge safety from the OAuth screen alone. Two layers matter: what the external service granted the OAuth token, and what Gatekeeper actually exposes to agents and Gadgets. The OAuth token stays on the Gatekeeper side and is never handed to the agent. In a production rollout, do not stop at "OAuth is configured": review Gatekeeper's target scope and its operation APIs.

Reads and writes are not treated the same

Gatekeeper splits interactions with external systems into two kinds.

• Observation (reads) such as reading a document, searching issues or running a SELECT. These do not change external state. The published implementation passes results through authorizeObservation() and records what was read.
• Action (writes) such as creating an issue, editing a document, moving a meeting or writing to a database. These go to submitAction() and are not applied until a person approves and applyAction() is called.

Reads are logged, writes are approved. Separating just those two makes operational rules far clearer.

Approving afterwards, without stalling the AI

Conventional approval flows have a practical weakness. If the AI stops for approval on every change, a long task halts at the first operation. If you relax that into auto-approval, safety drops.

Gatekeeper runs unapproved operations speculatively and locally instead. If the AI renames an issue title and then drafts a follow-up comment based on it, Gatekeeper returns a state that looks as though the change happened. The AI keeps working, while the real issue on GitHub is untouched. When the work is done, a person approves the operations individually or in a batch.

Three integrations to start with

1. GitHub, organising issues in a single repository.
2. Google Docs or Sheets, reading one document.
3. Supabase, read-only analysis on one project.

All three are small in blast radius, easy to explain to a reviewer, and enough to prove the permission model works before anything important is connected.

What people actually use it for

Inside the workspace, a conversation turns into documents, apps and workflows. These are representative patterns rather than a promise of results.

• Sales: research before a meeting, first drafts of proposals, roll-up reports from the CRM.
• Customer support: searching across tickets and knowledge, drafting replies and FAQ entries, trend analysis.
• Management and planning: dashboards built from cross-department data, summaries for management meetings.
• HR: a question-answering bot for internal policy, recruitment scheduling, onboarding material.
• IT: designing Gatekeeper and MCP integrations, running access policy, monitoring logs.
• Back office: checking expense roll-ups, contract and document handling.

How Cloudflare uses it internally

Cloudflare OS was in use inside Cloudflare before it was published. According to the company's CIO, several thousand employees use it every week, and more than 4,000 apps and tools were created in a recent 30-day period. Sales alone is estimated by the company to have saved over 10,000 hours of manual work.

The rollout was staged, and the order is the interesting part

Cloudflare did not begin by telling everyone to build AI apps. When non-engineers were given coding AI, the company says the result was a lot of "apps looking for a problem to solve". So they reversed the approach and went through five stages:

1. 1

   An email address for work nobody wants to do

   Employees emailed their tedious tasks to it. It looked like writing to an AI, but a small team was handling the work by hand, with AI assistance, behind the scenes.

2. 2

   Humans sorted hundreds to thousands of requests

   Looking for work that recurred, and capturing the internal vocabulary, the actual procedure, the data that had to be reached and the output format expected.

3. 3

   Recurring work became Skills

   Email handling continued until enough common patterns had accumulated, then the collected context and Skills were made runnable in one click.

4. 4

   The AI was asked to build reusable apps

   An employee describes the job in plain language and the AI writes the code that does it. The resulting app can be run on demand, on a schedule, or triggered by an event.

5. 5

   Champions in each team spread it sideways

   No large dedicated AI department was created. Early adopters in each region and function, such as a sales lead in London or a solutions engineer in Texas, drove adoption locally.

What Cloudflare rolled out was not 4,000 finished apps. It was an intake point for tedious work, Skills that generalised it, a platform safe enough to build and share on, and people on the ground to carry it.

Three principles that came out of it

• Company context matters more than the model. A frontier model that does not know your vocabulary, your correct procedure, your decision criteria or where the data lives still has to be told everything each time. The difference between AI programmes comes less from which model was licensed than from whether the work was organised into a form the AI can execute.
• AI is not a tool, it is something that makes tools. An early version ran inference every time a skill executed. Aggregating the same table every morning does not need to burn tokens on every run. The newer approach has the AI build the app or workflow first, run the fixed parts as code, and call the AI only where judgement is needed.
• Push settled work back into software. In the IT helpdesk example, once the dashboard existed, opening it required no inference at all and consumed zero tokens. Because inference is billed by usage, that difference compounds the longer a workflow lives.

Compared with ChatGPT Enterprise and Microsoft 365 Copilot

These three are less competitors than products with different purposes. ChatGPT Enterprise is SaaS for giving an organisation a general-purpose assistant. Microsoft 365 Copilot is SaaS for putting AI into Microsoft 365 work. Cloudflare OS is an open-source platform for building and running your own AI infrastructure in your own account.

This is a difference of purpose, not a ranking. Connector coverage and admin capabilities in SaaS products change quickly, so always confirm against your own requirements.

How to choose

• You want a general-purpose assistant for everyone right now. A finished SaaS product is the shorter path.
• Your work sits in Microsoft 365. Microsoft 365 Copilot is the natural option.
• You want internal integration, permission control and auditing designed to your own specification. Cloudflare OS is worth evaluating, particularly if you do not want to hand API keys to agents and you need to govern what the AI has seen.

These are not mutually exclusive. Using SaaS for a general assistant and Cloudflare OS for work that touches internal systems is a reasonable split.

What it actually costs

The software itself is Apache 2.0 open source and the licence fee is $0. Running it still costs money, because it runs on Cloudflare services in your account. The floor is Workers Paid at $5 per month, and authentication has a free tier for up to 50 users. Inference, storage and logs are billed by usage. The accurate summary is "free to start, not $0 to run".

How far the free tier goes

• Software. Apache 2.0, so obtaining, deploying and modifying it carries no licence cost.
• Authentication. Cloudflare Access and Zero Trust are $0 on the Free plan up to 50 users, so a pilot under 50 people stays inside the free tier for authentication.
• Runtime. Workers Paid from $5 per month per account. This is effectively the minimum fixed cost.
• Inference. Usage based. Nothing if you do not use it, but real work will always generate some.

Combining the published figures, a pilot of 50 users or fewer has a fixed cost starting at $5 per month for Workers Paid, plus usage for inference, storage and logs. Beyond 51 users, Zero Trust pay-as-you-go at $7 per user per month normally joins that. This is a way of reading the published prices, not a quotation. Your total depends on usage and configuration.

Three things that move the number

1. How much inference is used. More agent use means more model calls. Because every inference request passes through AI Gateway, you can set per-model cost visibility, budget ceilings and rate limits at the organisation level. Having that available from the start is a real operational advantage.
2. Storage and logs. Keeping workspace sessions, output files and audit logs is billed by usage. The stricter your audit requirements, the more log retention needs to be designed rather than assumed.
3. User count. The cost structure of authentication changes at 50 users, from free to $7 per user per month. Plan the pace of expansion and the cost together.

Deploying it

You do not need to hand this to the whole company at once. Get it running for one person, then limit who can log in, then add the internal data and operations the AI can touch one at a time.

Three ways to start

• Run it on your own machine. Clone the official repository, install pnpm and run pnpm run-local, then open http://localhost:8787. This uses Wrangler and the local Workers runtime. Cloudflare states this is not for production, so keep it to feature evaluation before any internal data is connected.
• Use the official hosted deploy. Fast to get something running, but for internal production you want to own the entry point and the administration yourself.
• Deploy the official starter into your own account. Recommended. Base your own repository on cloudflare-os-starter.

What you need first

The official README lists this environment: a Cloudflare account, Node.js 24, pnpm 11, Wrangler, Cloudflare Workers, KV and R2, Browser Rendering and Dynamic Worker Loaders. Workers AI, AI Gateway and Artifacts are optional. Cloudflare OS can be deployed with AI disabled and models configured later, so you do not have to settle model selection before you begin. You also need an identity provider to connect to Cloudflare Access, and at least one candidate workflow. That last one is not a technical requirement, but a pilot without it cannot be evaluated.

The deployment steps

1. Get the starter and install packages. Clone the repository, then prepare the submodule containing Cloudflare OS itself along with the dependencies. The final command opens a browser so Wrangler can connect to the Cloudflare account you intend to use.
2. Protect the entrance with Cloudflare Access. Never expose Cloudflare OS to the open internet. In the starter's standard configuration, Cloudflare Access authenticates the request before it reaches Cloudflare OS. Decide a dedicated hostname such as os.example.com, create a self-hosted application in Access for it, set which email addresses or company domains may sign in, take the Application Audience Tag, and record the hostname, the tag and the administrator email in deployment.jsonc. You can use a workers.dev hostname while evaluating, but a custom domain with Access makes ownership clearer for internal production.
3. Write your settings into deployment.jsonc. The main entries are the Cloudflare account ID, the name of each Worker, the hostname Cloudflare OS is served on, the Access audience tag, administrator emails, the KV and R2 destinations, whether AI is enabled, and whether Context and custom Gatekeepers are enabled. Leaving the KV and R2 entries as null lets Wrangler create the three KV namespaces and the R2 bucket automatically. Never put passwords or API keys in the configuration file. The official starter is designed to keep secrets out of version control; register credentials as Worker secrets instead.
4. Check the configuration before deploying. Run pnpm check to catch configuration mistakes, then pnpm deploy to roll out the Workers in order.
5. Adjust to your organisation at /admin. Finish the company-specific settings there.

Rolling it out across the organisation

Technical deployment and a rollout that produces value are different problems. Because this is an Early Access product, a staged rollout beats a company-wide launch. Put an exit condition on each stage and only move on once it is met.

1. 1

   Choose the workflow

   Fix one or two target workflows and their KPIs. Exit condition: a measurable goal has been agreed.

2. 2

   Run a scoped pilot

   Five to ten people, read-mostly, testing both value and usability. Exit condition: the likely effect against the KPI is visible.

3. 3

   Put identity and AI under control

   Access and identity provider integration, plus AI Gateway configuration. Exit condition: users and inference cost are both governed.

4. 4

   Connect Gatekeeper and MCP

   One system at a time. Exit condition: allow, deny and logging behave as designed.

5. 5

   Open writes with approval

   Release some write operations with a human in the loop. Exit condition: the approval flow and the audit record work in practice.

6. 6

   Expand to more teams

   Spread sideways together with training and an operating model. Exit condition: each team uses and runs it independently.

Where adoptions usually go wrong

• Treating "deployed" as the goal. Putting the software somewhere does not change how work happens. A pilot that has not decided which workflow, whose work and what is being delegated tends to end as "we tried it and it did not stick". Decide the workflow and the KPI before you build.
• Opening write access from day one. Starting from zero permissions only helps if the design uses it. Prompt injection and permission design mistakes remain real, so begin read-mostly and open writes gradually behind human approval.
• Following upstream updates blindly. Changes keep coming during Early Access. As the official starter asks, pin releases and review changes before taking them, and set that up at the beginning.
• Leaving training until later. A working platform does not spread if employees do not know how to use it or what the internal rules are. Put administrator and user training, and internal champions per team, into the rollout plan.

When not to rush

Cloudflare OS is a poor fit right now if you need a finished product with a support contract from day one, if nobody can own the permission design, or if the first target is a workflow where an error is expensive and irreversible. In those cases either wait for the managed edition or start somewhere with a smaller blast radius.

Frequently asked questions

What is Cloudflare OS?

An open-source enterprise AI agent platform released by Cloudflare in August 2026 under Apache 2.0. You deploy it into your own Cloudflare account, and employees use AI agents from a browser-based workspace to produce documents, apps and workflows connected to internal systems.

Is Cloudflare OS free?

The software licence fee is $0 because it is Apache 2.0. Running it is not free: Workers Paid from $5 per month, Access, and usage-based AI inference all apply. Pricing for a managed edition had not been announced as of August 2026.

How is it different from ChatGPT Enterprise or Microsoft 365 Copilot?

Cloudflare OS is not a finished SaaS product. It is an open-source platform you deploy into your own account and adapt. Internal system integration and permission control can be designed at source level, which is the main difference from a managed subscription product.

Is it safe to let agents access internal data?

Agents start with zero permissions and Gatekeeper mediates every operation with allow, deny, human approval and logging. Risk is not zero: prompt injection and permission design mistakes remain, so begin with a read-mostly pilot and open access gradually.

Should we roll it out company-wide right away?

Not recommended. It is an Early Access product released in August 2026, and Cloudflare itself asks adopters to pin releases and review changes. Start with a limited set of workflows, users and read-mostly permissions.

Can we deploy it into our own Cloudflare account?

Yes. That is the intended model. Your own Access policies, AI Gateway configuration, data and integrations are used as they are, which keeps the platform settings and the data under your control. The responsibility for building and running it is yours as well.

Can it connect to our existing MCP servers?

Yes. MCP Server Portal publishes your internal MCP servers as an organisation catalogue that agents can use. Connecting a specific internal system usually still requires implementing a Gatekeeper for it.

How long does adoption take?

The technical deployment is short. A useful adoption needs workflow selection, a pilot, identity and AI governance, and Gatekeeper connections. A scoped pilot is a matter of weeks; reaching department-wide use is measured in months.

Is it realistic for a small or mid-sized company?

Yes. Zero Trust Free covers up to 50 users at $0 and Workers Paid starts at $5 per month, so a small team can start without much fixed cost. Beginning with one or two workflows in a scoped pilot is the approach we recommend at any size.

Do you offer training?

Yes. Alongside implementation support we run training for administrators and for employees, covering both day-to-day use and governance. Training on its own is also possible.

Implementation support and training

We are an independent service that helps companies adopt Cloudflare OS. We are not affiliated with Cloudflare, Inc. or its official partners. Our work covers the parts that decide whether an adoption succeeds:

• Choosing target workflows and designing the return on investment, then running a scoped pilot.
• Cloudflare Access and identity provider integration, Gatekeeper and MCP connections.
• AI Gateway, data loss prevention and audit logging.
• Training for administrators and for employees.

Our main site and detailed guides are written in Japanese. If you would like to talk to us in English, please use the contact form and write to us in English.