cloudflare/claude-managed-agents

cloudflare/claude-managed-agents

Language: TypeScript

License: MIT

Stars: 214

Forks: 30

Open issues: 9

Created: 2026-05-14T23:32:51Z

Pushed: 2026-06-04T22:23:44Z

Default branch: main

Fork: no

Archived: no

README:

Claude Managed Agents on Cloudflare

Run Claude Managed Agents (CMA) on Cloudflare.

This repo provides a customizable control plane that allows you to:

• Run CMA sandboxes on both full containers and light-weight isolates
• Customize the container size and image your agents use
• Get better observability into agent sandboxes
• Apply custom egress controls for zero-trust credential injection and connectivity to private services over Workers VPC
• Extend your Agents with Browser Run, Email, and any other custom tools using the Cloudflare Developer Platform

your needs.

Follow the [Onboarding Guide](#onboarding-guide) to get started. Two deployment styles are supported: a one-click Deploy to Cloudflare button (git-based, runs in Workers Builds) and a terminal-based npm run deploy flow from your laptop.

> [!IMPORTANT] > You need a Paid or Enterprise Cloudflare account to run Managed Agents. > Cloudflare Containers > (used by the MicroVM sandbox) and Worker Loader bindings (used by the > Isolate sandbox's code-execution and egress proxy tools) are Workers > Paid plan and above.

Overview

This repository deploys a Workers-based control plane for running Claude Managed Agents on Cloudflare.

Claude Managed Agents will send a webhook to your Worker when an agent session begin or ends. The control plane spins up a sandbox for each session, syncs state across session sleeps, and shuts down the sandbox when the session ends.

Sandboxes can be Cloudflare Containers or Isolate sandboxes using the AgentsSDK. This allows you to get either the full functionality of a Linux VM or a lightweight isolate that can hit massive scales without the resource overhead or cost of a microVM.

You can configure policies to restrict agent access to specific domains, inject credentials into outgoing requests without the agent ever accessing secrets, or write arbitrary proxy code to modify, reroute, or log egress traffic.

Additionally, you can connect Workers VPC and Mesh resources to your sandboxes. This allows you to easily access private resources, on any cloud or on-prem, without them ever being exposed to the public internet.

Lastly, this codebase can be easily extended to add custom tools to your agent's sandbox. Tools are picked up automatically by both backends and run with direct access to Worker bindings so they can take advantage of the whole Cloudflare Developer Platform.

The repo provides built-in tools for:

• Email Sending
• Private Service Access
• Browser Automation
• Image Generation

All of this is accessible via a UI and API that gets deployed to your Cloudflare account.

With the repository you should be able to get a Cloudflare-based self-managed environment up and running quickly. Then you can fork it, customize it to suit your needs, and redeploy. This repository is meant as a starting point.

> [!IMPORTANT] > You should consider this repository alpha software. It is not yet stable and may contain bugs.

Onboarding guide

Order matters — work through the steps top to bottom.

> [!IMPORTANT] > Step 8 is vital to securing your workload in production. Until you add auth, > anybody with access to your Workers URL can start sessions via the Claude Platform.

Pick a deployment style

There are two ways to deploy. Pick one and stick with it for the whole onboarding:

• Git-based. Click the [Deploy to Cloudflare](#step-1-initial-deploy) button.

Cloudflare forks this repo into your GitHub account, deploys your control plane and then future pushes to this GitHub repo will deploy updates automatically.

• Terminal-based. Run npm run deploy from your laptop. Requires

Docker (for the container image build) and a wrangler login session.

Steps 1 and 3 differ between the two tracks — each has separate sub-sections below. Steps 2 and 4 through 9 are identical regardless of how you deployed.

---

Step 1. Initial deploy

Git-based

The Deploy to Cloudflare button forks this repo into your GitHub account, provisions the D1 database, KV namespaces, R2 bucket, and Durable Objects automatically, prompts you for the required secrets (see Step 2), and deploys the Worker via Workers Builds.

After the deploy finishes you'll have a https://.workers.dev URL you'll need in step 2.


> ⚠️ You must rename one of the two KV namespaces in the deploy > form. The "Configure resources" step pre-fills both SECRETS > and EGRESS_POLICIES with the same default name, and the deploy > will fail with Cannot provision a KV Namespace ... because it > already exists if you don't change one. Suggested names: > -secrets and -egress-policies.

The worker won't function until you finish the remaining steps.

Terminal-based

npm run deploy

npm run deploy builds your base sandbox container image (Docker required), deploys the Worker, and applies D1 migrations via the postdeploy hook. The committed wrangler.jsonc deliberately leaves KV id fields and the D1 database_id empty — scripts/ensure-kv.mjs and scripts/ensure-d1.mjs run on prebuild and patch the real IDs in (adopting any namespaces / databases that already exist by name, creating fresh ones otherwise). R2 buckets are bound by name (no ID lookup needed) and are auto-created by wrangler.

If you're on a Cloudflare login that has access to more than one account, set CLOUDFLARE_ACCOUNT_ID before running so the ensure scripts know which account to talk to:

export CLOUDFLARE_ACCOUNT_ID=
npm run deploy

The worker won't…