Cloudflare Temporary Accounts: no signup required

Shipping a Cloudflare Worker from inside an AI agent used to require a human in the loop. The agent needed to call wrangler login, which opens a browser, waits for an OAuth callback, and stores credentials — steps that require exactly the kind of human interaction that makes autonomous agent loops fall apart. On June 19, Cloudflare shipped a flag that removes that entire gate. 1

The pull quote from the accompanying blog post, authored by Sid Chatterjee, Celso Martinho, and Brendan Irvine-Broque, says it plainly: 2

"The moment an agent needs to deploy something — and needs to sign up and create an account — it slams face-first into a wall built for humans."

That wall is now optional.

What the command does

Running npx wrangler@latest deploy --temporary does three things: creates a throwaway Cloudflare account, deploys the Worker to it, and prints a claim URL — all without any prior authentication. 1

Terminal output of `npx wrangler@latest deploy --temporary` showing a temporary account created, a claim URL, and the deployed worker URL — `wrangler 4.102.0` creating a temporary account named "Snapdragon Variety," printing a 60-minute claim window and a live `.workers.dev` URL. 2

The temporary account lives for 60 minutes. During that window, the agent can redeploy changes and verify behavior against the live URL. After 60 minutes, if no human has claimed the account, Cloudflare deletes it automatically. Wrangler 4.102.0 — released the same day — detects when no credentials are present and prompts the agent to use --temporary rather than erroring out. 1

The claim URL converts the temporary account to a permanent one. A human (or a downstream step in a pipeline) opens it, logs in or creates a Cloudflare account, and all Workers, bindings, and configuration transfer over intact. 2

The full deploy-verify-claim loop

The lifecycle Cloudflare describes has five distinct steps:

Flow diagram: AI Agent → Deploy/Verify/Redeploy against Temporary account → Claim via Authentication → Move to Permanent account — The agent loops on deploy/verify/redeploy; the human step (claim) is deferred until the agent signals success. 2

Deploy — agent runs wrangler deploy --temporary; temporary account and Worker created instantly
Verify — agent hits the live .workers.dev URL to confirm behavior
Redeploy — agent applies fixes and redeploys within the same temporary account
Claim — agent surfaces the claim URL to the human operator (email, Slack, dashboard notification)
Move — human authenticates; Worker and all config migrate to the permanent account

This is the write→deploy→verify loop that coding agents need. For context: when Cloudflare launched the Agents SDK Codemode primitive the same week (June 16), it added createCodemodeRuntime with durable execution logs and approval gates for code execution. 3 Temporary Accounts closes the loop: an agent can now write code, execute it in a sandbox, and deploy it to a real Workers environment — all without touching a human until the claim step.

What's actually supported

Not a toy deployment — the temporary account supports the full set of Workers primitives that most production applications depend on: 1

Primitive	Supported in temporary account
Workers (scripts)	✅
Static Assets	✅
KV namespaces	✅
D1 databases	✅
Durable Objects	✅
Hyperdrive	✅
Queues	✅
SSL/TLS	✅

A wrangler.jsonc with a D1 binding works as-is. The agent doesn't need to strip out bindings or deploy a cut-down version for verification.

// wrangler.jsonc — works unchanged with --temporary
{
  "name": "my-api",
  "compatibility_date": "2026-06-19",
  "d1_databases": [
    {
      "binding": "DB",
      "database_name": "prod-db",
      "database_id": "xxxx-xxxx-xxxx"
    }
  ]
}

The binding is provisioned in the temporary account; if the agent's verification query hits D1 and gets a valid response, the config is structurally correct. When a human claims the account, the binding transfers — though the underlying database ID will typically need to be pointed at the production D1 instance manually.

Why Cloudflare built this now

The blog authors frame the motivation around what they call "background AI sessions" — agent workloads running without any user present. The signing-in step assumes a human is watching a browser. An agent running in a CI/CD pipeline or a coding assistant spinning up a test environment cannot satisfy that assumption. 2

Illustration: a robot at a laptop deploys to a temporary cloud (hourglass icon), which routes via dashed arrows to a padlock representing the claim step — AI-generated conceptual diagram of the agent deploy → temporary account → claim lifecycle.

Two broader infrastructure moves sit behind this. Cloudflare notes in the blog post that they are working with Stripe on zero-friction billing for temporary accounts and contributing to auth.md, a community spec for machine-readable authentication documentation that lets agents understand which auth flows they can complete autonomously. 2 Neither is shipping today, but both signal that Cloudflare sees "account creation" as a solved problem for agents, not a permanent human checkpoint.

The pairing with this week's Agents SDK v0.16.1 release is worth noting. That release added Browser Run (CDP-controlled browser sessions for agents that need to navigate human UI flows), Codemode (sandboxed code execution with approval gates), and more reliable WebSocket reconnection for agent sessions. 3 Temporary Accounts is the deployment primitive that makes the SDK's Codemode loop actually useful — you can write code in the sandbox, but you also need somewhere to deploy it.

Migrate or just watch?

Wire it in today if:

You have a coding agent or AI assistant that generates and deploys Workers (e.g., an internal platform tool, a PR-preview bot, or a scaffolding assistant). The --temporary flag is available right now on wrangler@latest with no account changes or plan upgrades required.
You run a CI pipeline that verifies Workers before promoting to production. Adding --temporary to the verification job gives you a real deployment against real Cloudflare infrastructure without risking your production account.
You're building an agent that needs to demo a Worker to a human before committing. The claim URL hands off cleanly from agent to human.

Just watch if:

Your deployment workflow is already human-initiated (you run wrangler deploy yourself). Temporary Accounts adds no value here — it solves the unattended deployment problem.
You deploy to production Workers accounts directly from CI with long-lived API tokens. That pattern still works and doesn't need to change.

The 60-minute claim window is the one constraint worth noting for CI pipelines: if your pipeline takes longer than an hour from initial deploy to human review, the temporary account will expire. For most verification jobs that's not an issue, but pipelines with long approval queues should factor it in.

The feature is available today on Wrangler 4.102.0 across all Cloudflare plans — Free included. 1

Cover image from the Cloudflare blog post