CLI for deploying and managing Cloudflare Workers, KV, R2, D1, Vectorize, Hyperdrive, AI, Containers, Queues, Workflows, and Pipelines.
Covers 10+ resource types with dedicated commands for creation, configuration, and lifecycle management across Workers, storage, databases, and compute services Supports local development with wrangler dev using local storage simulation or remote bindings for real resources; includes TypeScript type generation via wrangler types Configuration via wrangler.jsonc with support for environment-specific overrides, secrets management, cron triggers, and Durable Objects bindings Provides deployment workflows including dry-run validation, versioning, rollback, and secret management; tail command for live log streaming
Similar popular skills
Related neighbors and high-traction skills in the same topics — useful to compare before installing.
This skill provides comprehensive instructions for using the Cloudflare Wrangler CLI. It follows security best practices for handling secrets and utilizes official Cloudflare tools and resources. The identified patterns are standard for developer tooling and project management.
snykLOW
Analyzed Apr 23, 2026
No issues detected.
socketScore 0.9000 · 0 alerts
Analyzed Apr 23, 2026
license1
maintenance1
quality0.9
supply chain1
vulnerability1
0 alerts
Also in this package
Other skills from cloudflare/skills · top by installs.
Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.
Claude CodeNot declared
CursorNot declared
CodexNot declared
GitHub CopilotNot declared
WindsurfNot declared
Gemini CLINot declared
ClineNot declared
OpenCodeNot declared
Repository health
Stars2.8K
LicenseLICENSE
Default branchmain
Open issues8
Status
Active
Package contents
Files included with this skill beyond the listing page.
skill mdSKILL.md6,785 B
docsSUMMARY.md3,971 B
History
First seen on skills.sh
First recorded snapshot · 80,700 installs
SKILL.md
Wrangler CLI
Use the project's Wrangler version and retrieve the relevant documentation before writing commands or configuration. CLI flags and configuration fields change; do not rely on memorized examples.
Inspect the Project
Find the package manager, installed Wrangler version, package scripts, framework, and Wrangler config. Run commands through the project's scripts or package manager so they use its local version. Install dependencies using the existing lockfile when needed; do not silently upgrade Wrangler to match current docs. If Wrangler is not a dependency, follow the installation guide to add it locally.
Identify the config used by the build or deploy command, including framework-generated config. Edit its source rather than generated output.
Establish the target account, Worker, environment, and resource before running commands that change them. For data operations, determine whether the target is local or remote.
Retrieve What the Task Needs
Use the Cloudflare MCP docs tool if available, or fetch the relevant linked page directly. Follow links to the specific command or product involved; avoid loading the entire reference. If a page moves, rediscover it through the Wrangler command index or Cloudflare docs search.
Task
Source
Discover commands and flags, including resource management, deployments, rollback, and diagnostics
Project-local wrangler --help and wrangler <command> --help; command reference
Claim deployments for eligibility, expiry, and claim URL handling; use a permanent account for production or CI
Use installed help and schema to check whether documented features exist in the project's version. If a required feature needs an upgrade, make that dependency explicit. If retrieval is unavailable, state the gap and use available local evidence rather than inventing syntax.
Apply the Change
Prefer wrangler.jsonc for new config. Set a new project's compatibility date to today; review runtime changes and test when advancing an existing project's date. Preserve existing project conventions and avoid incidental format migrations.
Check environment inheritance before adding bindings or variables. Some fields must be specified separately for each environment; a working default config does not establish that staging is configured.
With the Cloudflare Vite plugin, select the environment via CLOUDFLARE_ENV at dev or build time. Deploy the resulting build; setting an environment at deploy time does not retarget its flattened config. See Vite environments.
Reconcile dashboard changes with the config before deploying: Wrangler can overwrite dashboard variables and routes. When binding existing resources, verify their identifiers; omitted identifiers can trigger automatic provisioning.
Distinguish local simulation from remote bindings during development. A locally running Worker can still access real resources; check the selected bindings before testing writes.
Keep secret values out of command arguments, source code, and logs. Use the documented interactive input or protected file/stdin mechanism for the command. Local secret files must be ignored by version control and are not automatically uploaded as deployed secrets. For missing local secrets, check file precedence and any secrets.required declaration in the secrets docs.
Treat wrangler secret put and secret delete as deployments: they create a version and deploy it immediately. Use the documented wrangler versions secret workflow when the change must be staged.
Before a rollback, check rollback limitations: connected resources and their data are not rolled back with Worker code.
Validate
After changing config or bindings in a TypeScript project, regenerate types with the project's wrangler types command rather than hand-editing generated declarations. Run the relevant existing typecheck or tests.
For deployment changes, use the project's build workflow and wrangler deploy --dry-run where supported, with the intended config and environment. A successful dry run checks the build and packaging; it does not prove remote resources or runtime behavior work. Use task-specific local or remote checks as appropriate to the requested work.
Report what changed, the target environment, checks performed, and any unresolved validation gaps. Link the documentation used when the result depends on current command or configuration behavior.