Cloudflare 1

Cloudflare OS setup

How to set up Cloudflare OS from zero

Cloudflare OS is an AI workspace for agents, apps, and company context. This is my practical setup path for deploying it with Cloudflare Zero Trust controls from day zero.

What Cloudflare OS Is

Cloudflare OS is an open-source AI productivity environment originally built inside Cloudflare. It gives people an agent workspace where they can ask questions, create documents, build small apps, and run workflows around company context and systems.

The important security idea is that agents and apps should start with access to nothing. Access is introduced narrowly through Gatekeepers, Cloudflare Access, AI Gateway, and the resources a user is allowed to use. That makes Cloudflare OS a good example of Zero Trust applied to agentic work.

Setup Order

1. Understand the productCloudflare OS is not a laptop operating system. It is an AI workspace for agents, Gadgets, blueprints, and company-specific context.
2. Prepare CloudflareUse a Cloudflare account with Workers, Access, AI Gateway, and the identity model you want to enforce.
3. Deploy OSUse the hosted deployment flow or the open-source repository to deploy into your own Cloudflare account.
4. Protect accessPut the OS instance behind Cloudflare Access and restrict it to the right users and groups.
5. Add AI routingUse AI Gateway to manage model routing, observability, spend, and provider choices.
6. Add resources carefullyIntroduce GitHub, documents, data sources, MCP servers, or internal systems through Gatekeepers and narrow permissions.
7. Operate and reviewReview shared apps, resource access, approvals, model usage, and logs before broad rollout.

Step 0: Decide the Use Case

Do not start by connecting every system. Start with one clear outcome: a private AI workspace, internal document generation, app prototyping, GitHub issue dashboards, support workflows, or company knowledge Q&A. That keeps the first deployment small enough to govern.

Good first use caseInternal knowledge Q&A, repo dashboard, meeting prep, document generation, or a simple internal app.
Avoid firstBroad production write access, sensitive customer data, financial approvals, or fully autonomous workflows.
Success signalUsers can complete a useful workflow while access remains narrow, observable, and reversible.

Step 1: Prepare Zero Trust Access

Cloudflare OS should not be left as an open internal experiment. Protect the deployment with Cloudflare Access, then use your IdP groups to decide who can enter the workspace and who can administer it.

Identity providerUse Entra ID, Okta, Google Workspace, or another SAML/OIDC provider for production users.
Access groupsCreate groups for OS users, OS admins, pilot users, developers, and reviewers.
Session policyUse a practical session duration and require stronger checks for admin routes.
AuditKeep Access logs available for review before connecting high-value resources.

Step 2: Deploy Cloudflare OS

The fastest path is the deployment flow at os.cloudflare.app/deploy. For deeper customization, use the open-source Cloudflare OS repository or starter deployment. The project runs on the Cloudflare Workers platform and is designed to be deployed into your own account.

Hosted deploymentBest for quickly deploying the product to your Cloudflare account and testing the workflow.
Repository pathBest when you need code changes, custom Gatekeepers, internal branding, or deeper review.
Local testThe GitHub project supports local testing with pnpm and wrangler before production deployment.

Step 3: Configure AI Gateway

AI Gateway is the control point I would use for model routing, observability, provider choice, and spend management. It gives the OS a cleaner AI traffic layer than scattering provider keys and logs across separate tools.

Model routingDecide which model providers are allowed for pilot users and production users.
ObservabilityTrack request volume, errors, latency, and cost trends before expanding usage.
PolicyDefine whether different user groups or workflows should use different models or limits.

Step 4: Add Resources Through Gatekeepers

Gatekeepers are the key security concept. Instead of giving an agent broad ambient access to every internal system, introduce one resource at a time. The Gatekeeper mediates access, enforces policy, logs what happened, and can require human approval for actions.

GitHubStart with one repository, read-only use cases, issue dashboards, or pull request summaries.
Docs and filesIntroduce only the folder, document, or dataset needed for the current workflow.
MCP serversPlace MCP access behind Access policy and expose only the tools that the workflow requires.
Write actionsRequire human approval for changes that update systems, publish data, send messages, or modify code.

Step 5: Define Safe Pilot Workflows

Keep the first workflows low-risk but useful. The goal is to prove that users can get value while security teams can still understand and control what the agents can see and do.

AskAnswer questions from approved company context, docs, and repositories.
MakeCreate drafts, docs, slide outlines, checklists, dashboards, and internal app prototypes.
BuildLet agents create small apps or Gadgets backed by limited data and private-by-default sharing.
RunTest workflows where read actions are automatic but write actions need approval.

Step 6: Set the Zero Trust Guardrails

Cloudflare OS is interesting because the product architecture already leans toward isolation and narrow access. I would still define a written governance model before expanding to more teams.

Default denyAgents and apps should start with no access to internal systems or the Internet unless explicitly introduced.
Least privilegeConnect only the resource needed for the task, not the whole system behind it.
Human approvalRequire approval for writes, side effects, publishing, code changes, and sensitive operations.
Private sharingShared work should remain limited to people who already have access to the underlying source data.
Review logsReview Access, AI Gateway, Gatekeeper, and application logs during the pilot.

Minimum Viable Setup

If I had to build a first Cloudflare OS pilot, I would aim for this:

Day 1Deploy Cloudflare OS to the Cloudflare account and protect it with Access.
Day 2Configure AI Gateway and confirm model routing and usage visibility.
Day 3Add one low-risk resource such as a GitHub repo, docs folder, or test dataset.
Day 4Create two useful pilot workflows: one Q&A workflow and one app or document workflow.
Day 5Review logs, permissions, sharing behavior, cost, and user feedback before adding more resources.

My Take

Cloudflare OS is most compelling when it is treated as a secure agent workspace, not just another chatbot. The winning pattern is to let users build and automate work, but keep every agent, app, and resource behind clear Zero Trust controls.

Source References

This note is based on the public Cloudflare OS product site, the Cloudflare OS GitHub repository, the deployment flow, and Cloudflare One concepts such as Access applications and AI Gateway.