Skip to content

Instantly share code, notes, and snippets.

@zeke

zeke/cloudflare-workers-claim-deployments.md

Last active July 2, 2026 19:34
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save zeke/02c18380e2cd20ecee32d2e29dc1f545 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save zeke/02c18380e2cd20ecee32d2e29dc1f545 to your computer and use it in GitHub Desktop.
Download ZIP
Cloudflare Workers claim deployments and temporary preview accounts
Raw
cloudflare-workers-claim-deployments.md

Cloudflare Workers Claim Deployments

Cloudflare's claim deployments feature, also described as temporary preview accounts, lets an unauthenticated environment deploy a Worker to Cloudflare with wrangler deploy --temporary and then hand the result to a human through a claim URL.

This summary is based only on publicly available Cloudflare sources: Cloudflare Workers docs, Cloudflare changelog, and the Cloudflare blog.

How It Works

  1. An unauthenticated environment runs wrangler deploy.
  2. Wrangler detects that no Cloudflare credentials are available and tells the agent to rerun with --temporary.
  3. wrangler deploy --temporary creates or reuses a temporary preview account.
  4. The Worker is deployed to a workers.dev URL.
  5. Wrangler prints the live Worker URL and a claim URL.
  6. The temporary account stays live for 60 minutes.
  7. During that window, the agent can redeploy and verify changes.
  8. To keep the deployment, someone opens the claim URL, signs in or creates a Cloudflare account, and claims the temporary preview account.
  9. If nobody claims it within 60 minutes, Cloudflare deletes the temporary account and its deployments.

What It Is For

  • AI coding agents that need to deploy without stopping for OAuth, dashboard clicks, MFA, or API tokens.
  • Background agent sessions.
  • Quick prototypes.
  • First-time Workers evaluations.
  • Throwaway deploy-verify loops where the agent can curl the deployed Worker and iterate.

What It Is Not For

  • Production deployments.
  • CI/CD.
  • Authenticated Cloudflare usage.

If Wrangler already has OAuth, CLOUDFLARE_API_TOKEN, or a global API key available, --temporary errors. Cloudflare says to use normal wrangler login or API tokens for permanent or production workflows.

Supported Cloudflare Primitives

Primitive Temporary account support / limit
Workers Deploys to a workers.dev URL only
Workers Static Assets Up to 1,000 files, max 5 MiB per asset
Workers KV Supported for commands using temporary credentials
D1 One database, up to 100 MB total
Durable Objects Supported for commands using temporary credentials
Hyperdrive Up to 2 database configs and 10 connections
Queues Up to 10 queues
SSL/TLS certificates Supported for commands using temporary credentials

Current docs do not list R2, Vectorize, Workers AI, Workflows, Browser Rendering, Images, Stream, custom domains, or production routes as supported temporary preview account primitives.

Handoff Semantics

Claim URLs grant ownership of the temporary preview account, so they should be treated as sensitive bearer links.

This supports agent-to-user handoff by design. It can also function as a pre-claim handoff between people if the claim URL is shared, but the docs describe this as claiming the temporary preview account, not transferring an individual Worker between arbitrary Cloudflare users.

After the temporary preview account is claimed, normal Cloudflare account ownership, membership, permissions, and migration mechanisms apply. The --temporary flow is no longer involved.

Existing Users and Account Merge

An existing Cloudflare user can claim a temporary preview account. The claim flow lets the user sign in to Cloudflare, then claim the temporary preview account. After that, the Worker and supported resources created in the temporary account remain available to that user.

The public docs do not describe this as merging the temporary preview account into an existing Cloudflare account ID, nor do they describe automatically moving the Worker or resources into one of the user's existing production accounts.

The documented model is:

  1. Temporary preview account is created by wrangler deploy --temporary.
  2. A user opens the claim URL and signs in or creates a Cloudflare account.
  3. The temporary preview account is claimed and becomes permanent for that user.

The documented model is not:

  1. Temporary preview account is created.
  2. Its resources are folded into an existing production account automatically.

If the goal is to run the Worker inside an existing production account, the practical path is to claim the temporary preview account before it expires, inspect or keep the generated resources there, then redeploy the project to the desired permanent account using normal Wrangler authentication without --temporary.

Source Links

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment