CLI · Cloud development · Cloudflare
Cloudflare Wrangler
Develop and manage Cloudflare Workers and related resources with project configuration that can be reviewed in code.
Environment names do not guarantee isolation. A development configuration can reference shared or production resources. Inspect account IDs, bindings and remote settings.
Understand the tool
What it does.
Wrangler is Cloudflare's development CLI for Workers and related services. A Worker runs application code on Cloudflare's platform. Wrangler connects local project files and configuration to development, deployment and resource-management commands.
Why use it?
It gives a Cloudflare project a repeatable set of commands and configuration instead of relying only on dashboard clicks. Start by inspecting the account and project settings, then use the documented development mode appropriate to the application's bindings.
A useful fit for
- Workers development
- Reviewable Cloudflare configuration
- Deployment and resource inspection
From need to output
Ways to put it to work.
These are suggested workflows based on the documented capabilities. They are not recorded runtime results.
Use case 01
Check the target account
A developer works across several Cloudflare accounts and needs to avoid deploying to the wrong one.
- Inspect the active authentication profile.
- Read the project account and environment settings.
- Match both to the intended development target before any write.
Intended outputAn explicit account and environment selection for the next operation.
Use case 02
Test a Worker change
A request handler needs a new validation rule.
- Review the entrypoint and bindings.
- Run the appropriate local development workflow with test data.
- Check response behavior before preparing a separate deployment.
Intended outputA local validation result and a clear deployment decision.
A concrete starting point
Inspect the authenticated account
With Wrangler already installed and available in your terminal, this documented command shows the active Cloudflare identity and account access.
wrangler whoamiWhat this can change
Reads authentication/account information and makes Cloudflare requests as needed. It does not deploy a Worker or edit a resource.
This example has not been executed for this review. Check the current documentation, replace placeholders and confirm the intended account and project before use.
Before you start
Setup and access.
What you’ll need
- Installed Wrangler and its supported Node.js runtime
- A Cloudflare account for remote operations
- Reviewed project configuration and service-specific permissions
- Authentication
- Interactive login or an appropriately scoped API token; profiles can separate account contexts.
- Can read
- Project configuration and source
- Account and service metadata within credential permissions
- Can write or change
- Deployments and enabled Cloudflare resources
- Local build and development state
- Network and data flow
- Cloudflare authentication and APIs
- Configured remote bindings and application endpoints
- Approval and control
- Authentication authorizes operations; deployment and resource commands need an explicit workflow review before execution.
Check your environment
Compatibility, costs and license.
Compatibility notes
- Windows, macOS and Linux with supported Node.js
- Cloudflare Workers ecosystem; binding support varies by development mode
Costs and account requirements
Wrangler source is open source. Workers and connected services have their own usage limits and pricing; a local test can still reach billable remote resources when configured.
Current pricing or plan information ↗MIT OR Apache-2.0
Repository licensing is separate from Cloudflare service terms; check component notices for redistribution.
Read the license or service terms ↗Keep the boundaries visible
Concerns and limitations.
Environment names do not guarantee isolation
A development configuration can reference shared or production resources. Inspect account IDs, bindings and remote settings.
Credentials can authorize broad changes
Use narrowly scoped tokens and avoid placing secrets in committed configuration or terminal transcripts.
Where it may fall short
- Local behavior does not prove full production parity.
- A Worker deployment and changes to its database or storage require separate validation.
Observed behavior · 2026-10-18
Runtime and security findings.
Wrangler bundled a synthetic Worker, rejected a missing entry file and served the expected response on localhost. No Cloudflare account, remote binding or deployment was used.
These checks cover the conditions below. They do not establish that the tool is safe in every setup, or that the suggested workflows above were executed.
What we found
Observed in this evaluation
Local execution and deployment are different evidence
Dry-run bundling and one local HTTP request worked for this Worker. These tests did not validate Cloudflare permissions, deployed behavior or managed bindings.
In practice: Use dry-run to inspect the bundle, then separately validate staging bindings and account/zone targets before deployment.
Documented concern · medium severity under stated conditions
Keep development secrets separate from ordinary configuration
Cloudflare documents local secret files and warns against committing them. This fixture contained no secret values.
In practice: Use the documented secret mechanism, exclude local secret files from Git and review build logs for accidental disclosure.
Version, environment and fixture
- Version or deployment
- 4.151.1
- Tested target
- Official wrangler npm package, installed locally with lifecycle scripts disabled
- Artifact identity
- npm package integrity sha512-OAsa9UAHZshM6mq2PXcVoyxXgWThAanZMBc/IirtqEWd/BauRtmUKzAniOu/pU0pd3pxKuMZ2vsbF4eo6RiNDA==; package-lock retained privately with exact dependencies.
- Environment and fixture
- Windows 11 x64; Python 3.12.10 harness. Raw timestamps UTC.
- Fresh per-tool home/config/cache; child environment constructed from OS/runtime paths, explicit isolation variables and no inherited credentials. Synthetic fixtures only; no user account sign-in.
- Node 24.18.0; synthetic ES-module Worker; local mode bound explicitly to 127.0.0.1.
Checks and results
4 recorded checks. Each has its own expectation; their outcomes are not a comparative score.
Pinned package versionMet expectation
- Method
<node-install>\node.EXE <evaluation>\downloads\cli\wrangler\node_modules\wrangler\bin\wrangler.js --version- Expected
- Print the pinned Wrangler version.
- Observed
- Exit 0. 4.151.1
Bundle without deploymentMet expectation
- Method
Fixture files in the working directory: worker.js = "export default { async fetch() { return new Response(\"ionbin-local-fixture\", {headers:{\"content-type\":\"text/plain\"}}); } };"; wrangler.json = {"name": "ionbin-eval-fixture", "main": "worker.js", "compatibility_date": "2026-10-01"}. Command: <node-install>\node.EXE <evaluation>\downloads\cli\wrangler\node_modules\wrangler\bin\wrangler.js deploy --dry-run --outdir bundle- Expected
- Produce a local bundle and exit without deployment.
- Observed
- Exit 0. Wrangler reported Total Upload 0.22 KiB / gzip 0.18 KiB and exited due to --dry-run. The generated bundle retained the synthetic response handler.
Missing Worker entry pointMet expectation
- Method
Fixture invalid.json = {"name": "ionbin-eval-fixture", "main": "missing.js", "compatibility_date": "2026-10-01"}, with no missing.js file. Command: <node-install>\node.EXE <evaluation>\downloads\cli\wrangler\node_modules\wrangler\bin\wrangler.js deploy --dry-run --config invalid.json- Expected
- Fail clearly when main points to missing.js.
- Observed
- Exit 1. The entry-point file at missing.js was not found.
Run the synthetic Worker locallyMet expectation
- Method
Fixture files in the working directory: worker.js = "export default { async fetch() { return new Response(\"ionbin-local-fixture\", {headers:{\"content-type\":\"text/plain\"}}); } };"; wrangler.json = {"name": "ionbin-eval-fixture", "main": "worker.js", "compatibility_date": "2026-10-01"}. Command: <node-install>\node.EXE <evaluation>\downloads\cli\wrangler\node_modules\wrangler\bin\wrangler.js dev --local --ip 127.0.0.1 --port 60359 --show-interactive-dev-session=false- Expected
- GET / returns HTTP 200 and the fixture body.
- Observed
- HTTP 200; body exactly ionbin-local-fixture. The harness then stopped its owned Wrangler process tree (cleanup exit 0); process exit 1 was termination after the successful request, not an application failure.
Practical caveats
- The first local-server probe could not establish a response inside the host sandbox; the scoped rerun succeeded.
- One simple request does not cover production compatibility, CPU limits, concurrency or billing.
What this evaluation does not establish
- Authentication, account/zone scoping, remote preview/deployment and rollback.
- KV/R2/D1/Queues/service bindings, secret injection, Worker security bugs and production traffic.
Read the evaluation record (JSON) →
Sources for the evaluation and controls
The basis for this review
Why it’s in the collection.
An editorial entry for teams using Cloudflare: clear project configuration and account inspection support repeatability, while platform-specific setup limits general usefulness.
The number is an editorial starting order within the cli tools collection. It does not measure popularity, speed, reliability or safety.
What we reviewed
- Official Wrangler documentation, general commands, profiles, pricing and source
The evaluation above lists the current runtime coverage and untested behavior.
Reviewed Oct 18, 2026. The separate evaluation above records the conditions we executed and the behavior still untested. Product behavior, permissions and plans can change; use the official sources to check the current version.
Follow the evidence
Official sources.
- Wrangler overview ↗developers.cloudflare.com
- General commands ↗developers.cloudflare.com
- Authentication profiles ↗developers.cloudflare.com
- Workers pricing ↗developers.cloudflare.com
- Official source ↗github.com