Run Claude Managed Agents on Cloudflare: Everything You Need to Know

Anthropic and Cloudflare have partnered to allow you to run your Claude managed agents code in Cloudflare. With that, you get incredible scale and fast boot speed, as well as security controls, built-in tools, and more. Let's take a look. One quick thing before we dive in, Cloudflare ships this whole integration as an open-source repo with a deploy to Cloudflare button. This works out of the box, but you can customize as much as you want to. You click the button, Cloudflare provisions the worker, the storage, and the bindings. Then over in the Claude console, you create a self-managed environment, point the Claude environment webhook at your worker's URL, and you're done. From there, every Claude agent you spin up against that environment runs on your Cloudflare account. With that out of the way, let's get into what makes it different. When you run your agent code in the cloud, typically you get a full Linux container. Cloudflare gives you exactly that in the micro VM sandbox, and you can customize the size of the container and the image. But what happens when you scale this up? Imagine a 100,000 users, each with five agents running in the background, summarizing inboxes, monitoring dashboards, drafting replies, etc. That's half a million Linux containers, most of them idle waiting for the model to respond, and that cost adds up fast. So, Cloudflare added a second option, the isolate sandbox powered by dynamic workers. Instead of a full container, your agent runs inside of a V8 isolate, the same primitive workers have been built on for a decade. You get a sandbox JavaScript runtime, a virtual file system, and the ability to execute JavaScript that the agent writes on the fly. More importantly, cold starts only take about 5 milliseconds, so environments can spin up and down extremely quickly. With Cloudflare, you get to choose between a micro VM when you need a full container and dynamic workers when you want to focus on cost, scale, and speed. Those benefits aside though, another factor you should consider is security. Cloudflare's environments ship with an egress layer that gives you full control over your outgoing traffic. You can inject credentials, determine dynamic per user policies, and modify requests in any way. Here's an example. Agents typically need to call APIs. Stripe for payments, Slack for communication, and GitHub for code. And all of those need API keys. The standard pattern is to just dump those keys into the sandbox as environment variables. The problem is once the secret lives inside the sandbox, the agent can potentially read it. And anything the agent can read, it can be tricked into sending somewhere it shouldn't. A user or a malicious email or a website your agent visits could convince the agent to help debug by printing out its environment variables. If the agent obliges, now your Stripe key is in a chat log. Or worse, posted to a public URL that the attacker owns. Cloudflare flips this around. Every outbound request from the sandbox passes through an egress layer at the worker boundary before it ever hits the network. One useful rule type here is header injection. Let's say the agent calls API.stripe.com. The egress worker matches the host, pulls the secret key from KV, injects the authorization header on the way out. The agent never sees the value, it just sees that the call worked. The agent only gets a name to reference, so even if a clever prompt convinces the agent to print every variable it has access to, none of them are the real keys. The flip side of egress is reaching for things within your control. Your internal database or private analytics service, and Cloudflare mesh solves for that. It's one private network that spans your laptops, servers, and workers, all routed through Cloudflare's edge. Pair it with workers VPC bindings, and your agent gets a CF call service tool with a closed list of exactly which services on your mesh it's allowed to call. So that covers scale and security. The third item is where I get most excited. On most platforms, give your agent a new capability means provisioning a new service, building an API, securing it, and hoping the agent figures out how to call it. On Cloudflare, though, you just check a box. Browser tools to fetch URLs and take screenshots, image generation through Workers AI, the ability to call a private service, all wired up out of the box. And here's the one that surprised me the most. Every agent literally gets its own email address. You point Cloudflare email routing at the integration's email handler with a catch-all rule on your domain, and when the handler sees an email come in, it parses out the agent ID and delivers the message to that specific agent. So, a customer emails an agent, the agent reads, drafts, sends a reply, or you kick off an agent by emailing it yourself. And when you do need something more custom, the docs walk you through that as well. Here's an idea. A tool that takes a screenshot of any URL, uploads it to R2 object storage, and gives the agent back a public link to share. Now your agent can take a screenshot of a competitor's pricing page, post it in Slack, and link to it. A Zod's schema for the input, a function that does the work, a binding declaration, and done. And because the whole thing runs on Cloudflare, every other Cloudflare product is one binding away as well. R2 for storage, D1 for SQL, Workers AI for inference, Vectorize for search. You don't need to leave the platform to give your agent more reach, and you don't have to actively manage infrastructure. Don't worry about scaling, containers, connectivity, just write a function and you're done. So, Anthropic provides you the brain, and Cloudflare gives you the hands to do the work with a runtime fast enough and cheap enough to scale to millions of concurrent agents with dynamic workers. Read the announcement blog post for more details, or use the deploy to Cloudflare button in the repository to get started. Both are linked in the description below.