Temporary Cloudflare accounts: agents can now deploy without signing up
By Flavio Copes
wrangler deploy --temporary deploys a Worker with no Cloudflare account. Live for 60 minutes, claimable with a link. How it works and its limits.
AI agents are great at writing code. Then they try to deploy it, and they hit a wall built for humans: sign up in a browser, click through a dashboard, copy an API token, pass MFA.
For an agent you work with interactively, that’s annoying. For a background agent, it’s a hard stop.
Cloudflare’s answer is temporary accounts. An agent (or you) can now run:
npx wrangler deploy --temporary
and get a live Worker on a workers.dev URL without an account, login, or token.
How it works
Cloudflare provisions a temporary account on the fly, gives wrangler a short-lived token, deploys the Worker, and prints two things:
- the live URL (
https://your-worker.some-name.workers.dev) - a claim URL
The deployment stays live for 60 minutes. Open the claim URL within that window, sign in or sign up, and the temporary account becomes permanently yours. This includes the Worker and any resources it created.
If you don’t claim it, the account expires and gets deleted on its own.
You can keep redeploying while the window is open. Wrangler caches the temporary account and reuses it, so an agent can iterate: deploy, curl the URL, fix, redeploy.
How agents discover the flag
How does an agent even know the flag exists? Nobody prompts their agent with “use —temporary”.
Cloudflare solved it in the CLI output. When wrangler has no credentials and you run a plain wrangler deploy, it prints:
To continue without logging in, rerun this command with `--temporary`.
Wrangler will use a temporary account and print a claim URL.
The agent reads the error, discovers the flag, and reruns the command without asking a human. Cloudflare put the instructions in the tool output, where the agent will read them.
Try it yourself
You need Wrangler 4.102.0 or later, and you must not be logged in. The flag errors out if wrangler already has credentials (OAuth, CLOUDFLARE_API_TOKEN, or a global key). It’s strictly for the unauthenticated case.
The prompt Cloudflare suggests for a coding agent:
Make a very simple Hello World Cloudflare Worker in TypeScript
and deploy it using the Wrangler CLI. Do not ask me questions.
The agent writes the Worker, tries to deploy, discovers the flag, deploys, and verifies its own work by fetching the URL. The full write → deploy → verify loop, with no account.
What a temporary account can hold
Temporary accounts currently support the Worker and these resources:
- Workers on
workers.dev - static assets (up to 1,000 files, 5 MiB each)
- KV, Durable Objects
- one D1 database (100 MB)
- up to 10 Queues, two Hyperdrive configs
An agent can scaffold a small full-stack app with a Worker, database, and storage. You get one claim link for the whole thing.
Be careful with the claim URL
The claim URL grants ownership of the account. Whoever opens it first gets the deployment and everything in it.
Treat it like a credential: don’t paste it in public channels, don’t log it somewhere permanent. Cloudflare also rate-limits temporary account creation and runs a proof-of-work check before provisioning one, so this doesn’t become a free-compute abuse vector.
When not to use it
This is a prototyping and agent tool, not a deployment strategy.
For production and CI/CD, use a permanent account with wrangler login or an API token, like always. If you want to publish a static site without touching a terminal, use Cloudflare Drop. You drag in a folder and get a site.
Platforms are starting to treat agents as first-class users. Signup flows, dashboards, and copy-pasted tokens all assume a human with a browser. Temporary accounts remove that assumption from deployment.
Want me to talk about your product? You can sponsor this site.
Related posts about cloudflare: