Cloudflare Temporary Accounts: How AI Agents Deploy Workers Without Signup (2026)
Cloudflare launched Temporary Accounts on June 19, 2026. Agents run wrangler deploy --temporary to ship Workers instantly — no OAuth, no API token, 60-minute claim window. Full flow, limits, and how it fits auth.md and agent harnesses.
The problem is familiar: an agent writes code, runs wrangler deploy, and stalls at browser OAuth, MFA prompts, API token copy-paste, or dashboard clicks. For an interactive copilot, that's friction. For a background agent with no human in the loop, it's a hard stop.
The fix is one flag: wrangler deploy --temporary. Cloudflare provisions a temporary preview account, deploys your Worker to a workers.dev URL, and prints a claim link. You have 60 minutes to make it permanent — or it expires on its own.
This guide covers the full flow, supported products, limits, and where this fits in the broader push toward frictionless agentic deployments.
Cloudflare's announcement frames three reasons temporary accounts exist:
1. Background agents have no human in the loop
Agent sessions that run overnight, in CI sandboxes, or as sub-agents in a larger harness cannot complete browser OAuth flows. Any step requiring "click here in 60 seconds" or copy-paste from a dashboard means the agent gets stuck — and may deploy elsewhere.
This is the same class of problem our Agent Harness guide describes: the harness controls tool execution, verification, and loop termination. Deployment auth is just another tool gate — and until now, it was a gate only humans could open.
2. Trial-and-error is the agent's superpower
Agents work best in a tight write → deploy → verify loop. They need cheap, throwaway deployment targets so they can curl their own output and decide whether the result matches intent. A 60-minute ephemeral account is exactly that: a sandbox with a real public URL, not a mock.
3. Agent platforms expect deploy to "just work"
People are starting to expect that agents can ship code without signing up for services the user has never heard of. Cloudflare bet on Wrangler specifically because it's widely documented and agents already know how to use it — they just needed an unauthenticated entry point.
In Cloudflare's demo, the agent wrote the script, deployed with --temporary, curled the preview link, and verified the response — all without human intervention.
How agents discover the flag
A subtle design choice: Cloudflare did not assume agents would know about --temporary on day one.
Instead, the first unauthenticated deploy attempt returns a hint in stderr/stdout. Any agent that reads tool output and adapts — Claude Code, Pi, OpenCode, Codex — can self-correct on the second attempt.
This pattern mirrors how good agent harnesses handle tool failures: parse error output, retry with corrected parameters. Cloudflare built the retry hint into the CLI itself.
Important:--temporary is not a global flag. It is available only on commands that can use the short-lived temporary preview account token. If Wrangler is already authenticated, --temporary returns an error — use wrangler login and deploy normally instead.
Iterating within the 60-minute window
Agentic coding is rarely one deploy. A session might cycle through:
Deploy hello world
Change copy to "hello cloudflare"
Add a route handler
Redeploy and re-verify
This works. Wrangler caches the temporary preview account and reuses it while both the account and claim URL remain valid. Output shows whether the account was created or reused.
bash
# First deploy
npx wrangler deploy --temporary
# Edit src/index.ts, then redeploy — same temporary account
npx wrangler deploy --temporary
The cache clears when you run wrangler login or wrangler logout.
Example iteration prompt:
snippet
Now change hello world to "hello cloudflare" and redeploy
The agent edits source, reruns wrangler deploy --temporary, curls the updated URL, and confirms the change — still within the claim window.
Claiming the temporary account
To keep the deployment permanently:
Open the claim URL from Wrangler output within 60 minutes
Sign in to Cloudflare or create a new account
Follow dashboard prompts to claim the temporary preview account
Claiming transfers ownership of everything in that account — not just the Worker, but also D1 databases, KV namespaces, Queues, and other bindings created during the session.
After claiming:
bash
wrangler login
wrangler deploy # no --temporary needed
If you do not claim within 60 minutes, Cloudflare automatically deletes the temporary account and all resources inside it.
Security note: Claim URLs grant ownership of the temporary preview account. Treat them as sensitive — do not commit them to git or paste them in public channels.
Supported products and limits
Temporary preview accounts support a subset of Cloudflare products. From the official docs:
Product / resource
Limit on temporary account
Workers
Deployments on workers.dev
Workers Static Assets
Up to 1,000 files, 5 MiB each
Workers KV
Commands using temporary credentials
D1
One database, 100 MB per database, 100 MB total
Durable Objects
Commands using temporary credentials
Hyperdrive
Up to 2 database configs, 10 connections
Queues
Up to 10 queues
SSL/TLS certificates
Commands using temporary credentials
Cloudflare says it will add support for more products over time. Check the docs before assuming a binding works on a temporary account.
Other limits
Limit
Detail
Expiry
60 minutes if unclaimed
Creation rate
Cloudflare limits how quickly temporary accounts can be created; wait and retry if throttled
Authenticated CLI
--temporary errors if OAuth, CLOUDFLARE_API_TOKEN, or global API key is already set
Abuse prevention
Additional checks applied to temporary preview accounts
For production and CI/CD, use a permanent Cloudflare account with wrangler login or a scoped API token. Do not use --temporary in pipelines where credentials already exist.
Security and abuse prevention
Temporary accounts are designed for low-friction prototyping, not anonymous production hosting. Cloudflare applies:
Proof-of-work before account creation (automatic, no user input)
Rate limits on temporary account creation
Abuse prevention checks on temporary preview accounts
Sensitive claim URLs that transfer full account ownership
For agents running in untrusted environments, treat temporary deployments as public-by-default preview URLs. Do not deploy secrets, production data, or unauthenticated admin endpoints to a temporary account expecting privacy.
If your agent harness needs deployment in a locked-down environment, use permanent accounts with scoped API tokens and explicit permission gates — the pattern described in our Claude Code permission modes guide.
The road to frictionless agentic deployments
Temporary accounts are one piece of a larger Cloudflare push to make infrastructure agent-ready:
Cloudflare announced a partnership with Stripe and co-designed a protocol that lets agents provision Cloudflare on behalf of users — creating an account, starting a subscription, registering a domain, and getting an API token to deploy code, with no copy-pasting tokens or entering credit card details manually.
auth.md with WorkOS
Cloudflare collaborated with WorkOS on auth.md — an open standard for agents to provision new accounts using existing OAuth flows. Any platform can adopt it.
Agents SDK and MCP
Cloudflare is also expanding the Agents SDK as a runtime other agent frameworks (starting with Flue) can build on, plus MCP server support for agent tool integration. See our MCP guide for the protocol basics.
isitagentready.com
Cloudflare points developers to isitagentready.com — a checklist for making apps accessible to agents without human intervention at every step.
The through-line: signup and auth were built for humans. Agents need the same infrastructure access with programmatic entry points. Temporary accounts solve the cold-start problem; Stripe provisioning and auth.md solve the permanent-account problem.
When to use what
Scenario
Approach
Agent prototyping a new Worker
wrangler deploy --temporary
Background agent with no credentials
--temporary (agent discovers from CLI hint)
Human wants to keep the deploy
Claim within 60 minutes
Production / CI/CD
Permanent account + wrangler login or API token
Already authenticated Wrangler
Normal wrangler deploy (no --temporary)
Agent needs D1 + KV + Queues in one session
Temporary account supports all three (within limits)
Long-running production agent
Claim account, then wrangler login
Example: full agent session
Here is what a complete unauthenticated agent session looks like:
Cloudflare Temporary Accounts remove the first-deploy auth wall for AI agents. The key facts:
wrangler deploy --temporary provisions a 60-minute preview account with a live workers.dev URL — no signup required upfront.
Agents self-discover the flag from Wrangler's unauthenticated deploy hint — no need to hardcode --temporary in every prompt.
Redeploy freely within the claim window; Wrangler caches and reuses the temporary account.
Claim to keep — open the claim URL, sign in, and the Worker plus bindings become permanently yours.
Not for production — use permanent accounts with scoped tokens for CI/CD and shipped products.
For anyone building agent harnesses that include a deploy step, this is the most practical Cloudflare integration to test first. Point your agent at a Worker project, let it hit the auth wall once, and watch it self-correct.
Wrangler version requirements, product limits, and claim window duration reflect Cloudflare documentation as of June 20, 2026. Verify current limits at developers.cloudflare.com before production use.
