AI Tool Profile
Cloudflare Temporary Accounts: Security, Limits, and Pricing
Cloudflare Temporary Accounts let Wrangler create a 60-minute preview account so an unauthenticated coding agent can deploy, verify and revise supported Workers resources before a human claims ownership.
Verification & Sources
- Evidence state
- Recheck due
- Source links
- 4
- Freshness
- Needs recheck: checked July 27, 2026
- Last updated
- July 28, 2026
What this evidence state means
- Definition
- The claim was previously checked, but its review window expired or a material change may have invalidated it.
- Required provenance
- The prior evidence and check date are retained, together with the expiry or change signal that triggered recheck.
- Owner
- Kingy freshness queue owner and assigned editorial reviewer
- Freshness rule
- This is already outside its freshness rule. It must not be presented as current until reviewed against current evidence.
- Disputes and corrections
- Use “Suggest a correction” on the record. Kingy editorial reviews the cited evidence, records material corrections, and changes or removes the state when it is not supported.
Key source checks
Suggest a correction
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
The Kingy Brief
Follow The Kingy Brief.
One consequential launch, one pricing, limit, or shutdown change, one hands-on test, one exact prompt or Test Pack, and one try / watch / skip verdict.
Free · Choose your subjects · Double opt-in · Unsubscribe anytime
Tool Links
Launch History
Cloudflare Temporary Accounts for AI Agents
Cloudflare added 60-minute Temporary Accounts to Wrangler so an unauthenticated coding agent can deploy and revise supported Workers resources, return a preview and claim URL, and let a…
- Launch readiness
- 7.6 / 10
- Demo evidence
- Not scored yet
- Creator-story fit
- Not scored yet
Score definitions and rubric
These are launch-record readiness heuristics, not product ratings.
Launch readiness
How complete and reviewable the launch record is, not the quality of the product.
Inputs and weights: Launch date 15%; qualifying source 10%; what launched 10%; demo 15%; category 10%; audience 10%; editorial assessment 10%; traction evidence 10%; creator or audience fit 10%.
Evidence inputs: Reviewed launch metadata, public source links, demo links, taxonomy, audience, editorial notes, and recorded traction signals.
Demo evidence
Whether the record contains useful, reviewable demonstration evidence; it is not a rating of product output quality.
Inputs and weights: Working demo URL 45%; video walkthrough 25%; clear description of what launched 10%; audience 10%; editorial assessment 10%.
Evidence inputs: Demo and video URLs plus the reviewed launch description, audience, and editorial notes.
Creator-story fit
Whether a launch has enough demonstrable evidence and audience relevance for a useful creator story; it does not predict views or guarantee coverage.
Inputs and weights: Demo evidence 25%; visual creator category 15%; audience 15%; editorial assessment 15%; traction evidence 10%; pricing clarity 10%; API or open-weight evidence 10%.
Evidence inputs: Reviewed demo, category, audience, editorial, traction, pricing, API, and open-weight fields.
- Scale
- 0.0–10.0. A present qualifying input receives its published weight; a missing input receives zero. Scores are rounded to one decimal.
- Assigned by
- Suggested by the deterministic field-completeness helper and assigned or approved by a Kingy editorial reviewer.
- Rubric and check date
- Rubric version P0-2026-08-10. The record’s “Last verified” date is the score check date. Checked: 2026-07-27.
- Confidence and missing data
- Confidence depends on source completeness. “Not scored yet” means no reviewed value; “Needs review” means the value or score set failed validation.
- Freshness
- Recalculate after a material launch, source, demo, pricing, audience, or traction change and during the record freshness review.
- Disputes
- Use “Suggest a correction” on the record and cite the relevant evidence. Commercial relationships cannot buy or alter a score.
Temporary Accounts remove real signup friction and delete unclaimed previews after 60 minutes. The claim URL and temporary token are sensitive values, so production…