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 — no account, no login, no 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 — the Worker plus any resources it created — becomes permanently yours.

Don’t claim it, and it expires and gets deleted on its own. No orphaned accounts, no cleanup.

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.

The clever part: discovery

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. No human in the loop. It’s a small thing, but it’s exactly how you design for agents: put the instructions where they’ll be read — in the tool output.

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

It’s not just the Worker. Temporary accounts currently support:

• 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

So an agent can scaffold a small full-stack app — Worker, database, storage — and hand you 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. And if you just want to drop a static site on a URL without touching a terminal, the browser version of this same idea is Cloudflare Drop — drag a folder, get a site.

What I take away from this: platforms are starting to treat agents as first-class users. Signup flows, dashboards, and copy-pasted tokens all assume a human with a browser. The ones who remove that assumption first will be where agents deploy by default.

~~~

Related posts about cloudflare: