Cloudflare's 60-Minute Deploy Window Changes What Your AI Agent Can Actually Ship

Cloudflare shipped Temporary Accounts for AI agents recently. If you're running AI coding agents against Cloudflare infrastructure, this feature collapses your biggest bottleneck.

Here's what changed, what still limits you, and what that 60-minute window actually unlocks in practice.

TL;DR

- Deploy a live Worker to a real URL in under 60 seconds. No human auth required - Update to the latest version of Wrangler. Run `wrangler logout` first, then `wrangler deploy --temporary` - Temp account and all its resources auto-delete after 60 minutes unless you claim it - Supported: Workers, Workers KV, D1, Durable Objects, Hyperdrive, Queues, SSL/TLS certs - Not a free tier replacement. Free tier is separate and still applies

The Problem Nobody Talked About Until Now

Before the introduction of Temporary Accounts, an AI agent trying to run `wrangler deploy` without an existing Cloudflare account hit what Cloudflare itself calls "a wall built for humans." Agent could write the code fine.

Could not complete the OAuth flow. Could not click through the dashboard. Could not copy-paste an API token.

Human had to get involved.

Every single deployment.

Temporary Accounts remove that wall entirely.

When your agent runs `wrangler deploy --temporary`, here's what actually happens: Cloudflare provisions a throwaway account behind the scenes, gives Wrangler a scoped API token for that account. And returns a claim URL alongside the live URL. Agent deploys, curls its own output to verify correctness, iterates, all without you touching the keyboard.

Cloudflare describes the 60-minute window as "long enough for an agent to write, deploy, and verify. Short enough that nobody mistakes the temp account for a real one." Honestly, that's accurate.

They're not overselling it.

The Claim URL Is the Actual Innovation

The 60-minute window is the constraint. The claim URL is the escape hatch.

Wrangler outputs the claim URL as part of the deployment log, and it contains a `claimToken` query parameter.

Open that URL and you can sign in to an existing Cloudflare account or create a new one, then claim the temporary account and make it permanent. When you claim within the window, you keep the Worker. Yes. But also the D1 database. The Durable Object. The KV namespace. Whatever else the agent spun up under that temporary account.

If you don't claim within 60 minutes, Cloudflare deletes everything.

Automatically.

Here's the workflow: agent deploys with `--temporary`, gets a preview URL and a claim URL, verifies the Worker is correct, returns both URLs to you. You decide within an hour whether to keep it. If yes, click the claim URL and the deployment graduates from ephemeral scratch space to permanent infrastructure.

If no, do nothing and it vanishes.

I keep coming back to how clean this is. `wrangler deploy --temporary` effectively becomes a promotion step rather than a commit.

Ship fast, verify fast, decide.

Side note: their docs on this feature are scattered across three different pages. Not a dealbreaker, but annoying when you're trying to get something done at 11pm.

What You Can and Cannot Deploy Right Now

Temporary preview accounts aren't a full product catalog. Cloudflare explicitly limits them to Workers, Workers KV, D1, Durable Objects, Hyperdrive, Queues, and SSL/TLS certificates. Anything outside that list isn't available in a temporary account today.

If your agent tries to provision a product outside this list under `--temporary`, it will fail or behave unexpectedly. Plan accordingly.

On pricing: the Workers free tier remains independently in place and still has its own limits. The free tier doesn't require a temporary account and isn't affected by this feature.

For production workloads beyond the free tier, you still need a real account with billing set up.

The PR Preview Use Case Nobody Is Talking About Enough

Community discussion keeps pointing to pull request previews as the most immediately practical application, and I think that's right. Agent finishes a feature branch, deploys it to a temporary account, posts the preview URL into the PR thread. Reviewer clicks a real URL, sees the actual deployed Worker, makes a call.

No manual deployment. No shared staging environment.

No "works on my machine" debates.

The 60-minute window is long enough to open the PR, review the feature, and merge or close. If the PR is still open after an hour without a claim, the temp account dies — which means stale previews auto-cleanup. That's a feature, not a bug.

For solo operators running agents against Cloudflare Workers, this is the difference between "my agent built something" and "my agent shipped something I can actually review."

What This Week Signals About Agent-Native Infrastructure

Cloudflare wasn't alone.

Microsoft shipped a serverless agents runtime for Azure Functions recently, the same day. CircleCI launched Chunk Sidecars for CI validation inside AI coding agent loops that same week. Three major infrastructure companies made agent-native deployment features live within a short period of each other.

This isn't coincidence.

The pattern is clear: platforms are racing to remove human authentication friction from agent workflows.

OAuth and dashboard-centric signup were built for browsers. Agents don't have browsers. The platforms that close that gap fastest will own the agentic coding stack.

Cloudflare got there first on the deploy side. The 60-minute claim window is a well-designed constraint — permissive enough for real work, short enough to prevent permanent clutter. If you run AI coding agents and your stack includes or could include Cloudflare Workers, update to the latest version of Wrangler, log out. And give it a test. Agent writes and deploys. You get a URL in your inbox. You decide in an hour whether to keep it.

That loop is new. It's fast. And for the first time, the human is optional.

Sources

https://blog.cloudflare.com/temporary-accounts/ https://developers.cloudflare.com/changelog/post/temporary-accounts-for-agents/