Use it when your goal in servers and infrastructure is clear and you can limit it to the data and actions it actually needs.
Cloudflare Temporary Deploy
Deploy a Worker live, no account, via wrangler --temporary
What does it add to Hermes?
Deploy a Worker live, no account, via wrangler --temporary
Cloudflare Temporary Deploy is a skill related to servers and infrastructure. It helps the agent understand or operate technical resources that can affect cost, availability, and security.
This plain-language explanation is based on the publisher description. The original text remains visible for verification.
Do not add it merely to experiment when Hermes already has a simpler path, or when you cannot review its source and permissions.
Best for users who want a repeatable way of working inside Hermes.
Start in a test environment with a limited account and inspect status before creating or deleting anything.
Deploy a Worker live, no account, via wrangler --temporary
This entry was indexed from Hermes Optional Skills. Our explanation interprets the type and domain without inventing a capability not present upstream.
The source is official or editorially reviewed, but you still need to review permissions and version compatibility.
Inspect, install, then test.
- 01Open the source
Match the publisher, license, and description to your need. Check the real update history.
- 02Review permissions and secrets
Never paste a secret value into this site. Use environment-variable names and grant the smallest scope.
- 03Copy setup only after review
The controls below copy text. They do not execute commands on your device.
- 04Test with a non-sensitive task
Inspect the visible tools, then exclude write or delete tools you do not need.
Review the command, then copy it.
hermes skills install cloudflare-temporary-deployHermes Belarabi does not execute this command. Installation happens on your device and remains subject to Hermes scanning and your review.
Exactly what Hermes loads when this skill runs.
Reproduced from the official documentation. Read it before enabling the skill: this text becomes the agent's instructions.
Deploy a Worker live, no account, via wrangler --temporary.
Skill metadata
A lookup table. Do not read it all; find the row that applies to you.
| Source | Optional — install with hermes skills install official/web-development/cloudflare-temporary-deploy |
| Path | optional-skills/web-development/cloudflare-temporary-deploy |
| Version | 1.0.0 |
| Author | Hermes Agent |
| License | MIT |
| Platforms | linux, macos, windows |
| Tags | cloudflare, workers, wrangler, deploy, temporary, agent, serverless, web-development |
Reference: full SKILL.md
Explains the idea itself. Read it slowly; the later sections build on it.
Deploy a Cloudflare Worker to a live workers.dev URL with zero account setup, using wrangler deploy --temporary. Cloudflare provisions a throwaway account, deploys, and prints a claim URL valid for 60 minutes; unclaimed accounts auto-delete. This gives an agent a tight write → deploy → verify loop without any OAuth, signup, or token copy-paste.
This skill does NOT cover production deploys (use wrangler login + a permanent account for those), nor non-Worker Cloudflare products beyond the temporary-account limits below.
When to Use
Explains the idea itself. Read it slowly; the later sections build on it.
Load this skill when the user wants to:
- Ship agent-written code to a live URL without first creating a Cloudflare account — "deploy this and give me a link"
- Iterate in a background/autonomous session where a browser OAuth step would be a hard stop
- Prototype or evaluate Workers quickly with a throwaway, claimable target
- Build a self-verifying deploy loop — deploy,
curlthe live URL, confirm output matches the code, redeploy
When NOT to Use
Settings you configure once. Change one at a time so you can see what each does. Set CLOUDFLARE_API_TOKEN in your environment, not in the chat.
- Production or CI/CD → use a permanent account (
wrangler loginorCLOUDFLARE_API_TOKEN).--temporaryerrors out if any credential is present. - Wrangler is already authenticated →
--temporaryreturns an error by design. Runwrangler logoutfirst only if the user explicitly wants a throwaway deploy. - Long-lived hosting → temporary deployments are deleted after 60 minutes unless claimed.
Prerequisites
Settings you configure once. Change one at a time so you can see what each does. Set CLOUDFLARE_API_TOKEN, CLOUDFLARE_API_KEY in your environment, not in the chat.
- Wrangler 4.102.0 or later. This is the version that introduced
--temporary. Earlier versions do not have it. Verify withnpx wrangler@latest --version. - Node 18+ / npm (or
npx,yarn,pnpm). No global install needed —npx wrangler@latestworks. - No Cloudflare credentials present.
--temporaryonly works when Wrangler is unauthenticated: no OAuth login, noCLOUDFLARE_API_TOKEN/CLOUDFLARE_API_KEYenv var, no~/.wrangler/~/.config/.wranglercached OAuth. Use theterminaltool's environment as-is; do not set those vars. - Network egress to
cloudflare.comandworkers.dev. - Using
--temporaryaccepts Cloudflare's Terms of Service and Privacy Policy.
How to Run
Settings you configure once. Change one at a time so you can see what each does.
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.
- Scaffold a minimal Worker (skip if the project already exists). A Worker needs a
wrangler.toml(orwrangler.jsonc) and an entry script. Minimal TypeScript example — write these withwrite_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");
},
};- Deploy with
--temporaryfrom the project directory:
npx wrangler@latest deploy --temporaryThe proof-of-work check adds a short automatic delay. On success Wrangler prints an Account: <name> (created) (or (reused)) line, a Claim URL, and the live https://<worker>.<account>.workers.dev URL.
- Parse the URLs from that output. Run the helper to extract them reliably instead of eyeballing:
npx wrangler@latest deploy --temporary 2>&1 | python3 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"}.
- Verify the deploy is actually live — do not trust the deploy log alone.
curlthe live URL and confirm the body matches what the code returns:
curl -sS <live_url>- 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: <name> (reused)), so the URL stays stable.curlagain to confirm the change.
- 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
A lookup table. Do not read it all; find the row that applies to you.
| 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 | python3 scripts/parse_deploy_output.py |
| Verify live | curl -sS <live_url> |
| 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 |
Pitfalls
Settings you configure once. Change one at a time so you can see what each does. Set CLOUDFLARE_API_TOKEN, CLOUDFLARE_API_KEY in your environment, not in the chat.
--temporaryis not inwrangler deploy --helpand is not a global flag. It is intentionally hidden and surfaced dynamically: when an unauthenticatedwrangler deployfails, Wrangler prints "rerun with--temporary". Don't conclude the flag is missing just because--helpomits it — check the version instead.- Old global wrangler. A stale globally-installed
wrangler(< 4.102.0) silently lacks the flag. Always invokenpx wrangler@latest(or a pinned>=4.102.0) so you control the version. - Auth present → hard error. If
wrangler loginwas ever run, orCLOUDFLARE_API_TOKEN/CLOUDFLARE_API_KEYis set,--temporaryerrors. Either unset the var for this shell orwrangler 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.
curlmay briefly serve the old body after a redeploy.workers.devhas a short edge cache; the(reused)line plus a newCurrent Version IDconfirm the deploy succeeded even ifcurlshows 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
Explains the idea itself. Read it slowly; the later sections build on it.
npx wrangler@latest --versionreturns>= 4.102.0.npx wrangler@latest deploy --temporaryprints aworkers.devlive URL and aclaim-preview?claimToken=claim URL.curl -sS <live_url>returns the exact body the Worker code produces.- A second deploy reports
Account: <name> (reused)and the live URL is unchanged. - The parser script's self-test passes:
python3 scripts/parse_deploy_output.py --selftest.