Cloudflare Temporary Accounts: Security, Limits, and Pricing

Full Guide

Kingy verdict: Cloudflare Temporary Accounts solve a specific agent-onboarding problem: an unauthenticated coding agent can deploy and verify a Worker before the user creates credentials. The 60-minute deletion window limits residue, but the claim link and temporary API token are sensitive bearer-like values that require deliberate handling.

How the temporary deployment works

With Wrangler 4.102.0 or later and no Cloudflare credentials present, an agent can rerun deployment with wrangler deploy --temporary. Cloudflare creates a preview account, returns a live Worker URL and a claim URL, and permits repeated changes during the same 60-minute window. Opening the claim URL lets a person sign in or create an account and move the temporary resources into permanent ownership. If nobody claims them, Cloudflare says the account is automatically deleted.

The supported surface is broader than a single script. Current documentation lists Workers, Static Assets, KV, one D1 database, Durable Objects, up to two Hyperdrive configurations, up to ten Queues, and certificate operations, each with temporary-account limits. It is therefore a short-lived sandbox for several application components, not a universal Cloudflare account.

Security and operational limits

The temporary account.apiToken authorizes supported resource operations. The claim URL can transfer ownership to whoever possesses it. Cloudflare tells integrators to keep both out of browser responses, logs, analytics and support telemetry, store them only in backend state scoped to the intended user, and delete copies by expiry. Temporary creation also requires proof of work, is rate-limited, is subject to abuse checks, and is unavailable through the FedRAMP High endpoint.

Temporary mode is intentionally unauthenticated: existing OAuth, API-token or global-key credentials cause an error. This reduces accidental mixing with a permanent account, but it does not validate the generated application, dependency choices or data-handling behavior. Kingy did not run Wrangler or claim an account. Teams should test secret redaction, expiry, claim ownership, resource migration, failed claims and cleanup after agent interruption.

Pricing and production transition

Temporary Accounts are a Workers platform capability rather than a separately priced SKU. After a claim, normal Workers plan limits apply. Cloudflare currently documents a Free plan and a Workers Paid plan with a $5 monthly minimum; paid usage then varies by requests, CPU time and attached products. A successful free preview should not be treated as a production cost estimate.

How Kingy would evaluate it

Deploy a disposable Worker with one supported binding, verify the preview, redeploy once, and capture every place the token and claim URL could leak. Test an expired claim, a claim by the wrong browser session, authenticated-credential rejection and automatic deletion. After claiming a valid project, compare resource IDs, bindings, logs and billing state before allowing an agent to use the flow with customer code.

The product is compelling when signup friction blocks a safe preview. It is the wrong abstraction when the task needs durable identity, regulated endpoints, broad Cloudflare services or unattended production ownership.

Document the handoff as an identity transition, not merely a deployment success. The approving person should know which temporary resources exist, which account will receive them, when the preview expires and how to confirm that no token copy survived the claim.

Primary sources

• Cloudflare announcement
• Dated Workers changelog
• Claim, supported-resource and security documentation
• Workers pricing