Cloud Parts

Wrangler

The command-line tool for Cloudflare Workers: it reads wrangler.jsonc, runs your Worker locally on the real runtime, deploys it, and manages the D1, KV, R2 and other resources it binds to.

What it is
Serverless functions (FaaS)
Part of
Tool for Cloudflare Workers
Type
Open source
Made by
Cloudflare, Inc.
License
MIT or Apache 2.0
Facts checked
12 October 2026
Website Source code

What it is

Wrangler is an npm package you install into each project, so a team pins one version. Its config file, wrangler.jsonc (recommended for new projects; wrangler.toml still works), names the Worker, its entry point, a compatibility_date that fixes runtime behavior, routes, per-environment overrides and every binding: KV namespaces, R2 buckets, D1 databases, Durable Objects, Queues, secrets. Cloudflare treats this file as the source of truth for a Worker’s configuration.

wrangler dev runs your Worker on your machine through Miniflare, which hosts it in workerd, the same runtime as production. Bindings point at local simulations that start empty, unless you mark one remote: true to reach the real resource while the code still runs locally. wrangler deploy bundles the code with esbuild, then uploads and activates a version; versions upload and versions deploy split that into two steps, and rollback, tail (a live log session), secret put and types (generates Env types from your bindings) cover the rest of the loop. Subcommands such as d1, kv, r2, queues, hyperdrive, vectorize and secrets-store manage resources; since v4 they act on local data unless you pass --remote.

Why teams pick it

  • Local development runs the production runtime, not an imitation: Cloudflare measured 10x faster startup and 60x faster reloads than the old remote mode
  • One tool and one config file for code, bindings, environments, secrets and most Developer Platform resources
  • Per-binding remote: true lets you test local code against real data without deploying
  • Open source under MIT or Apache 2.0, and installed per project so CI and laptops use the same version

Watch out for

  • Needs a supported Node.js release (Current, Active or Maintenance LTS) and, via workerd, macOS 13.5+, Windows 11 or a Linux with glibc 2.35+
  • Local simulations start empty and differ from production data; Workers AI always runs remotely, and Durable Objects and Workflows can’t be remote bindings
  • Since v4, kv and r2 commands default to local storage, so old scripts silently stop touching production until you add --remote
  • Some newer features work only with a JSON config file, so older wrangler.toml projects may need converting

How it fits with other technologies

The everyday loop · bash

npm i -D wrangler@4                     # installed per project
npx wrangler dev                        # local server on workerd via Miniflare
npx wrangler types                      # generate Env types from your bindings

npx wrangler d1 execute my-db --local  --command "SELECT count(*) FROM users"
npx wrangler d1 execute my-db --remote --command "SELECT count(*) FROM users"

npx wrangler secret put STRIPE_KEY      # prompts for the value, deploys a new version
npx wrangler deploy                     # upload and activate
npx wrangler tail                       # live log session for the deployed Worker

See it in a real stack

No architecture uses Wrangler yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2019–2025

On March 28, 2019, Ashley Williams open-sourced the first wrangler, written in Rust and installed with cargo install, as “just enough” tooling to build, preview and publish Workers written in Rust and compiled to WebAssembly. Its later wrangler dev command ran your code on Cloudflare’s network, and every change took a few seconds to show up.

On November 16, 2021, Ashcon Partovi and Sunil Pai announced wrangler 2.0, a new generation with zero-config wrangler dev, a Chrome DevTools debugger and a switch to “local mode” powered by Miniflare, a Node.js simulator created by Brendan Coll that had just joined the Cloudflare organization. Version 2.0.0 shipped on npm in May 2022. Local mode reimplemented the runtime in JavaScript, so it never behaved exactly like production.

That changed after Cloudflare open-sourced the real runtime, workerd, in 2022. Wrangler v3, released on May 17, 2023, made local development the default, running Miniflare 3 on workerd. Wrangler v4 followed on March 13, 2025 with a smaller set of changes: a newer esbuild, Node.js 16 dropped, and resource commands that default to local. Wrangler now lives in the workers-sdk monorepo with Miniflare and create-cloudflare.

Why it’s built this way

Local by default since v3
Remote development was slow to start and reload and billed KV and R2 operations. Running workerd locally gave production behavior with 10x faster startup and 60x faster reloads, with --remote kept for real data.
Simulators behind the real runtime
workerd provides the runtime and bindings but not the storage behind them, so Miniflare supplies local KV, R2, D1, Queues and Cache backed by SQLite.
Installed per project, not globally
A team then shares one Wrangler version, can pin it per project and roll back if a release breaks something.

Timeline

  1. 2019

    First wrangler open-sourced on March 28, a Rust CLI for Rust and WebAssembly Workers

  2. 2021

    wrangler 2.0 beta on November 16, with local mode via Miniflare

  3. 2022

    wrangler 2.0.0 released on npm in May

  4. 2023

    Wrangler v3 on May 17 makes workerd-based local development the default

  5. 2025

    Wrangler v4 on March 13; commands default to local data

Sources9 · facts checked 12 October 2026

Improve this page on GitHub