Deploy Cloudflare Workers Without an Account Using --temporary

This skill gives an agent a way to ship a Cloudflare Worker to a live workers.dev URL without creating an account, logging in, or copying tokens. It is built around wrangler deploy --temporary, which provisions a throwaway Cloudflare account, deploys your code, and prints a claim URL valid for 60 minutes. Reach for it when you want a tight write, deploy, verify loop in an autonomous session where a browser OAuth step would stall everything.

What it does

wrangler deploy --temporary is a hidden flag that only works when Wrangler is unauthenticated. When you run it, Cloudflare creates a temporary account on the fly, deploys your Worker to a workers.dev URL, and prints a claim URL. That URL is your only way to keep the deployment: open it within 60 minutes to claim the account and its resources. If you never claim it, the account and everything on it auto-delete.

The practical effect is a deploy loop that needs no signup, no OAuth dance, and no environment variables. You write code, deploy, curl the live URL to confirm the body matches, edit, redeploy, and verify again. Within the 60-minute window, Wrangler reuses the same temporary account, so the URL stays stable across redeploys.

This skill does not cover production deploys. For those, use wrangler login or a permanent account. It also does not cover non-Worker Cloudflare products beyond the temporary-account limits listed below.

Before you start

• Wrangler 4.102.0 or later. This is the version that introduced --temporary. Earlier versions do not have it. Verify with npx wrangler@latest --version.
• Node 18+ / npm (or npx, yarn, pnpm). No global install needed, npx wrangler@latest works.
• No Cloudflare credentials present. --temporary only works when Wrangler is unauthenticated: no OAuth login, no CLOUDFLARE_API_TOKEN / CLOUDFLARE_API_KEY env var, no ~/.wrangler / ~/.config/.wrangler cached OAuth. Use the terminal tool's environment as-is; do not set those vars.
• Network egress to cloudflare.com and workers.dev.
• Using --temporary accepts Cloudflare's Terms of Service and Privacy Policy.

How to run

Use the terminal tool for every step. Always pin the version (wrangler@latest or wrangler@4.102.0 or newer) so you don't accidentally run an old global wrangler that lacks the flag.

1. Scaffold a minimal Worker

Skip this if the project already exists. A Worker needs a wrangler.toml (or wrangler.jsonc) and an entry script. Minimal TypeScript example, write these with write_file:

wrangler.jsonc:

{
  "name": "hello-agent",
  "main": "src/index.ts",
  "compatibility_date": "2025-01-01"
}

src/index.ts:

export default {
  async fetch(): Promise<Response> {
    return new Response("hello cloudflare");
  },
};

2. Deploy with --temporary

From the project directory, run:

npx wrangler@latest deploy --temporary

The proof-of-work check adds a short automatic delay. On success Wrangler prints an Account: (created) (or (reused)) line, a Claim URL, and the live https://..workers.dev URL.

3. Parse the URLs

Do not eyeball the output. Run the helper to extract the URLs reliably:

npx wrangler@latest deploy --temporary 2>&1 | python scripts/parse_deploy_output.py

(Resolve scripts/parse_deploy_output.py to this skill's absolute path.) It prints JSON: {"live_url", "claim_url", "account", "account_state", "expires_minutes", "deployed"}.

4. Verify the deploy is actually live

Do not trust the deploy log alone. curl the live URL and confirm the body matches what the code returns:

curl -sS <live_url>

5. Iterate

Edit the code, redeploy with the same npx wrangler@latest deploy --temporary. Within the 60-minute window Wrangler reuses the cached temporary account (Account: (reused)), so the URL stays stable. curl again to confirm the change.

6. Hand the claim URL to the user

Tell them: open it within 60 minutes to keep the deployment and any resources; if they don't claim it, everything auto-deletes. Treat the claim URL as a secret, it grants ownership of the account.

Quick reference

Step	Command
Check version (need 4.102.0+)	npx wrangler@latest --version
Deploy (no account)	npx wrangler@latest deploy --temporary
Deploy + parse URLs	npx wrangler@latest deploy --temporary 2>&1 | python scripts/parse_deploy_output.py
Verify live	curl -sS
Clear cached temp account	npx wrangler@latest logout

Temporary account product limits

Product	Limit on a temporary account
Workers	Deploys to workers.dev
Static Assets	Up to 1,000 files, 5 MiB each
KV	Allowed
D1	1 database, 100 MB per DB / 100 MB total
Durable Objects	Allowed
Hyperdrive	2 configs, 10 connections
Queues	Up to 10
SSL/TLS certs	Allowed

When not to use it

• Production or CI/CD → use a permanent account (wrangler login or CLOUDFLARE_API_TOKEN). --temporary errors out if any credential is present.
• Wrangler is already authenticated → --temporary returns an error by design. Run wrangler logout first only if the user explicitly wants a throwaway deploy.
• Long-lived hosting → temporary deployments are deleted after 60 minutes unless claimed.

Limits and gotchas

• --temporary is not in wrangler deploy --help and is not a global flag. It is intentionally hidden and surfaced dynamically: when an unauthenticated wrangler deploy fails, Wrangler prints "rerun with --temporary". Don't conclude the flag is missing just because --help omits it, check the version instead.
• Old global wrangler. A stale globally-installed wrangler (=4.102.0) so you control the version.
• Auth present → hard error. If wrangler login was ever run, or CLOUDFLARE_API_TOKEN/CLOUDFLARE_API_KEY is set, --temporary errors. Either unset the var for this shell or wrangler logout. Never strip a user's real credentials without telling them.
• Rate limiting. Creating temporary accounts too fast fails. Reuse the cached account (just redeploy) within the 60-minute window instead of forcing a new one; if rate-limited, wait or use a permanent account.
• 60-minute hard expiry, not extendable. If the deploy must outlive an hour, the user must claim it. Surface this clearly.
• curl may briefly serve the old body after a redeploy. workers.dev has a short edge cache; the (reused) line plus a new Current Version ID confirm the deploy succeeded even if curl shows stale content for a few seconds. Re-curl, or add a cache-busting query string, before concluding a redeploy failed.
• Don't log the claim URL into shared transcripts as "just a link." It is credential-equivalent.

Verification

• npx wrangler@latest --version returns >= 4.102.0.
• npx wrangler@latest deploy --temporary prints a workers.dev live URL and a claim-preview?claimToken= claim URL.
• curl -sS returns the exact body the Worker code produces.
• A second deploy reports Account: (reused) and the live URL is unchanged.
• The parser script's self-test passes: python scripts/parse_deploy_output.py --selftest.

What pairs with this

This skill is part of the Web Development category in the optional skills set. It pairs naturally with other web development skills that involve writing and testing Workers code, and with any skill that needs a live URL for verification. For production deploys, look for skills that cover wrangler login and permanent account setup.