Cloudflare's 60-Minute Disposable Workers: The Zero-Signup Deploy Target AI Agents Actually Need

On June 19, 2026, Cloudflare shipped a feature that lets an AI agent run one CLI command and get a live, publicly reachable Worker — no signup, no account, no API token — that quietly deletes itself 60 minutes later if nobody claims it. It's a small feature with an unusually direct thesis behind it: Cloudflare's own announcement puts it bluntly, agents need "cheap, throwaway deployment targets, so they can curl their own output and decide whether they got it right." That's not a sandbox-execution pitch. It's a deploy pitch — and it's aimed squarely at the gap between "run some code" and "get a URL," which is exactly the gap a self-hosted PaaS lives in.

What wrangler deploy --temporary Actually Does​

The mechanism is almost aggressively simple. From a logged-out Wrangler CLI (4.102.0+), an agent runs wrangler deploy --temporary and Cloudflare provisions a temporary preview account on the spot, deploys the Worker to a workers.dev URL, and prints a claim link. No OAuth browser flow, no dashboard click-through, no MFA prompt — the deploy exists before anyone has decided whether it should be permanent.

The clock is explicit and consistent across Cloudflare's blog post, changelog, and docs: 60 minutes. Two things can happen before it runs out:

• Claim it. Opening the printed claim URL and signing in converts the temporary account into a real one — the Worker, its KV namespace, its D1 database, all become permanently owned, no redeploy needed.
• Do nothing. At 60 minutes, Cloudflare deletes the account and everything in it — automatically, no cleanup job to write.

The temporary account isn't a stripped-down sandbox — it's a real, if resource-capped, Workers account: one Worker with Static Assets (up to 1,000 files, 5 MiB each), Workers KV, a single 100MB D1 database, Durable Objects, Hyperdrive (2 configs), up to 10 Queues, and its own TLS cert. That's enough surface for an agent to deploy something that actually works, not just a "hello world" stub. What it explicitly won't do is take a custom domain or double as a CI target — Cloudflare frames this as a dev-loop primitive, not a production one.

The one control Cloudflare does publish is a proof-of-work check the CLI runs automatically before an account gets created, plus a stated (but unnumbered) rate limit on how fast temporary accounts can be spun up. No per-IP or per-minute figure is published, which is worth flagging as the one real unknown in an otherwise well-documented mechanism.

The Sandbox Vendors Already Sell This — Just Not This​

The obvious comparison is the crop of vendors already selling "give an agent a place to run code": E2B, Daytona, Fly.io, and Modal. Lay Cloudflare's temp accounts next to them and the differences are stark:

Every one of them requires an account and an API key before an agent can touch compute — the exact step Cloudflare's temp accounts remove. And every one of them is priced and marketed around running untrusted code safely — Modal's own pitch leans on customers executing millions of LLM-generated snippets a day; E2B and Daytona both ship MCP servers so an agent can drive sandbox lifecycle through tool calls. But look closely at what those MCP servers actually wrap: an already-authenticated API. The MCP layer removes friction from calling the sandbox, not from provisioning credentials to use it in the first place. Zero-signup is a gap none of the four have closed.

Execution Sandbox vs. Deploy Target — a Distinction That Actually Matters​

It would be easy to read "Cloudflare launched a disposable compute product" and file it next to E2B and Daytona as a fifth sandbox vendor. That undersells what's different. E2B, Daytona, Fly Sprites, and Modal Sandboxes all sell the same underlying product: an isolated place to execute code an agent wrote, so a human (or another agent) can inspect stdout, a file, or a return value. None of them, by default, hand back a stable, publicly reachable HTTPS URL a browser can hit — that's not the job they're doing.

Cloudflare's temp accounts sell something narrower and, for this specific use case, more useful: a deploy target. The output isn't a log of what a sandbox printed — it's a live service at a URL, reachable by anyone, that the agent itself can curl to verify its own work closed the loop. That's the write → deploy → verify cycle Cloudflare's announcement describes, and it's a materially different product shape than "run this snippet and tell me what happened." An agent building a small API, a webhook receiver, or a preview of a UI change needs the second thing, not the first — and until June 19, nobody was selling it without an account first.

Can a Cluster-API PaaS Build the Same Thing — Without Renting a Sandbox Vendor?​

Here's the part worth sitting with if you're running a PaaS on Cluster API rather than Cloudflare's edge: the namespace-per-PR preview pattern most CAPI-based platforms already have is structurally most of the way there. Provisioning a dedicated namespace on PR opened, wiring ingress and a TLS cert to it, and tearing it down declaratively on PR closed (or on a TTL) is mature, well-trodden ground — ArgoCD's PullRequest ApplicationSet generator, Flux, and tools like Signadot and Bunnyshell have been doing versions of it for years. What none of that prior art does is remove the identity step in front of provisioning. Every one of those systems assumes a known repo, a known PR, a known authenticated CI pipeline kicking off the deploy.

Cloudflare's contribution isn't the ephemeral-namespace idea — it's decoupling "get a running URL" from "prove who you are first." Translating that onto Cluster API concretely would mean:

1. An anonymous-but-rate-limited entry point. A machine-provisioning endpoint gated by the same kind of proof-of-work challenge Cloudflare uses instead of an API key — cheap enough for a legitimate agent to solve in milliseconds, expensive enough to blunt abuse at scale.
2. A namespace with a hard TTL baked into its object, not a cron job. Kubernetes TTLAfterFinished-style controllers already exist for Jobs; the same pattern applied to a namespace (or a CAPI-provisioned Machine) makes expiry a property of the resource, not an external sweep that can silently fail to run.
3. A claim path that re-parents the namespace, swapping an anonymous owner label for a real tenant/account reference — mechanically similar to Cloudflare converting a temp account into a permanent one, just expressed as a Kubernetes ownership change instead of an account migration.

It's worth being straightforward about where this stands: no one has shipped this combination yet. CNCF's 2026 platform-engineering commentary on agentic workloads is mostly about scoping already-authenticated agent identity — short-lived OIDC tokens, SPIFFE/SVID certs with tight TTLs — not about removing the authentication step for a first deploy. That's a real gap, not a solved problem with an obvious reference implementation to copy. For a Cluster-API-based PaaS, it's also a genuine opening: the infrastructure primitive (ephemeral namespace, declarative teardown) already exists in the pattern most of these platforms run today. What's missing is the front door Cloudflare just proved developers — and agents — want.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with an MCP interface an agent can call directly. If your agent-driven preview environments still start with "first, create an account," star the repo on GitHub and see what a zero-friction deploy loop looks like on infrastructure you control.

Sources:

• Cloudflare Blog: Temporary Cloudflare accounts for AI agents
• Cloudflare Changelog: Temporary accounts for AI agent deployments
• Cloudflare Docs: Claim deployments
• Cloudflare Blog: Building the agentic cloud — Agents Week 2026 recap
• Simon Willison: Temporary Cloudflare accounts for AI agents
• E2B Pricing
• E2B MCP docs
• Daytona MCP Server docs
• Fly.io Agent Sandboxes
• Fly.io Pricing
• Modal Sandboxes
• AI Agent Sandbox Infrastructure in 2026: E2B, Modal, Daytona, and Fly Machines
• Signadot: Comprehensive Guide to Preview Environments
• CNCF: Evolving platform engineering for AI-native workloads
• CNCF: Cloud native agentic standards