Cloudflare Temporary Accounts: deploy a Worker with no login for 60 minutes
Contents
You can now put a Cloudflare Worker on a real URL without creating an account or logging in. The catch: it lasts 60 minutes.
Announced in Temporary Cloudflare Accounts for AI agents, the feature lets you push a Worker to a workers.dev URL with just wrangler deploy --temporary on Wrangler 4.102.0 or later.
The published Worker lasts only 60 minutes.
Within that window, open the claim URL and log in or sign up to Cloudflare to take over the whole Temporary Preview Account as your own.
If you don’t claim it, the account and the deployment are deleted automatically.
Cloudflare ships this as an AI-agent feature.
But going by how it behaves, it’s also a “try a Worker on a real URL for 60 minutes before creating a Cloudflare account” feature.
Simon Willison also wrote that it’s interesting as a temporary Worker beyond the AI framing, and actually temp-deployed an HTTP redirect checker built from Codex Desktop.
What was stuck was login, not the code
By Cloudflare’s account, the old friction wasn’t the Worker build or the deploy command; it was OAuth, dashboard steps, API token creation, and MFA.
With a human Copilot beside you, “open this URL and log in” is enough.
For an agent running in the background, that’s where work stalls.
In the new flow, the agent runs wrangler deploy as usual.
When no Cloudflare credentials are found, Wrangler prints that you can re-run with --temporary.
The agent reads that output and retries the same deploy with wrangler deploy --temporary.
When trying this path, log out first with wrangler logout. If credentials remain, --temporary itself errors out.
Here’s the whole flow.
flowchart TD
A[wrangler deploy] --> B{Credentials found?}
B -->|Yes| C[Normal deploy]
B -->|No| D[Suggest --temporary]
D --> E[wrangler deploy --temporary]
E --> F[proof-of-work check]
F --> G[Create temporary preview account]
G --> H[Publish to workers.dev URL]
H --> I[Print claim URL]
I --> J{Claim within 60 min?}
J -->|Claim| K[Transfer to your account]
J -->|Don't claim| L[Auto-deleted after 60 min]Even without teaching --temporary up front in the prompt, the CLI’s error output itself shows the agent the next move.
When Cloudflare shipped its unified CLI and Local Explorer at April’s Agents Week, there was also a thread about aligning the CLI and docs so AI agents wouldn’t call commands that don’t exist.
Temporary Accounts applies that idea to the auth flow of a first deploy.
You can redeploy to the same temporary account for 60 minutes
The Cloudflare Workers docs state that Wrangler 4.102.0 or later is required.
The CLI creates a temporary preview account, publishes the Worker to a workers.dev URL, and prints a claim URL.
The temporary account it creates is cached on the Wrangler side.
Within 60 minutes, you can repeat wrangler deploy --temporary to the same temporary account.
The agent writes code, curls the public URL, fixes it on failure, and redeploys: that short loop runs.
After claiming, you treat it as a normal Cloudflare account.
If you keep working on the same Worker afterward, you wrangler login and deploy without --temporary.
Conversely, when Wrangler can already use OAuth, CLOUDFLARE_API_TOKEN, or a global API key, --temporary errors out.
--temporary only goes through for an unauthenticated first deploy; it can’t add more preview environments to an existing account.
The supported resources aren’t just the Worker itself
The resources you can use in a Temporary Preview Account are limited, but broader than the Worker alone.
The docs list Workers, Workers Static Assets, KV, D1, Durable Objects, Hyperdrive, Queues, and SSL/TLS certificates.
The limits are concrete too. The per-resource caps are written out with numbers in the docs.
| Resource | Temporary Preview Account limit |
|---|---|
| Workers Static Assets | Up to 1,000 files, 5MiB each |
| D1 | 1 database, 100MB per database, 100MB total |
| Hyperdrive | Up to 2 database configurations, 10 connections |
| Queues | Up to 10 |
| KV / Durable Objects / SSL/TLS | Available (no specific numeric limit stated in the docs) |
Within this range you can try more than just Hello World: a light API, a small web app with static assets, even a prototype that touches D1.
On the other hand, custom domains, production CI/CD, long-lived test environments, and connecting to existing Cloudflare resources all mean moving to a Permanent Account.
Like Cloudflare Artifacts and Cloudflare Email Service, April’s batch of announcements pointed toward “agents holding state and channels on Cloudflare.”
What Temporary Accounts removes is the auth step that stalled before the first Worker even went out. It isn’t adding a new runtime on top.
How preview URLs change
If all you want is to expose a local dev server, a tunnel or preview share is enough.
What Temporary Accounts changes is that an agent can verify a URL running on the real Workers environment by itself.
Workers run on a V8 isolate.
Code that leans on Node.js fs or child_process won’t run as-is, and Cloudflare-specific bindings differ between local and production.
Earlier, in VoidZero’s Cloudflare-native deploy, I wrote about V8 isolate constraints and the conditions for moving to Cloudflare Pages.
With this temporary deploy, you hit those constraints early on the real Cloudflare side.
Before a human reviews, the agent hits the public URL and checks the response.
If it’s a trinket that’s good enough, don’t claim it; drop it after 60 minutes.
If it turns out worth keeping, claim it.
But using this as a stand-in for production changes things.
Cloudflare’s changelog also says to use a normal Cloudflare account, wrangler login, and an API token for production and CI/CD.
Temporary Accounts isn’t a place to build durable permission management or audit logs.
Controlling creation abuse comes before billing accidents
Once you can publish a Worker without logging in, abuse prevention comes to mind.
The Cloudflare docs say a proof-of-work check runs before a temporary account is created, handled automatically by the CLI.
A short delay can occur, but no extra input is asked for.
Proof-of-work (PoW) is a mechanism that forces the requester to spend a certain amount of computation.
The CLI receives a challenge, brute-forces a hash that satisfies the condition, and returns the answer. Rather than requiring human interaction like a CAPTCHA, it makes you pay the cost in CPU time.
The per-attempt delay is a few seconds, so humans and legit agents barely notice; but trying to mass-create unauthenticated accounts with a script makes the computation pile up each time until it isn’t worth it.
It’s designed to balance the wide-open entrance of no-login with deterring automated mass creation.
There’s a rate limit on creation too.
Create too many temporary preview accounts in a short time and you’ll either wait and retry, or authenticate with a normal Cloudflare account.
This is a spot where, when building it into an agent platform, you shouldn’t pack retry intervals too tightly.
On cost, since it’s a small preview account that vanishes in 60 minutes, the risk is smaller than creating a permanently billed Cloudflare account outright.
Still, once you claim, it becomes an ordinary account. Whatever the agent built inside the temporary account ties straight to your permanent account.
If you’re taking over a prototype that touches D1, Queues, and Hyperdrive, inspect what’s inside right after claiming.
- List out the D1 databases, KV namespaces, Queues, and Durable Objects the agent created. They may have been churned out sloppily within the temporary limits
- Check that the binding definitions in
wrangler.toml/wrangler.jsoncmatch the resources that actually exist. Look for IDs left over from the temporary account - Check for hardcoded values or dummy secrets left behind
- If you’ll run it in production, issue a least-privilege API token yourself. The temporary deploy path doesn’t issue one
- Workers redeployed many times in the verification loop stay around, so delete the ones you don’t need
The claim URL is the ownership of the temporary account itself, so don’t commit it to git or paste it into a public channel.
Whether to claim is decided by a human at the moment they open the claim URL. It isn’t a mechanism for an agent to keep creating production accounts on its own.