Wrangler: the Cloudflare Workers command line tool

By Flavio Copes

A practical guide to Wrangler, the CLI you use to build, run, deploy, and manage Cloudflare Workers and everything attached to them.

If you build on Cloudflare Workers, you’ll spend a lot of time with Wrangler.

Wrangler is the command line tool for Workers. You use it to run your code locally, deploy it, manage your databases and storage, read logs, and handle secrets. Think of it as your remote control for the whole platform.

It comes installed in any project you scaffold with npm create cloudflare, so you usually run it with npx wrangler.

Let’s go through the commands I use every day.

The config file

Everything Wrangler does is driven by a config file in your project, wrangler.jsonc (older projects use wrangler.toml).

A minimal one looks like this:

{
  "name": "my-worker",
  "main": "src/index.ts",
  "compatibility_date": "2026-06-20"
}

name is your Worker’s name. main points to your code. compatibility_date pins the runtime behavior to a date, so your Worker keeps working the same way even as Cloudflare updates things.

This file is also where you attach databases, storage, and other resources. We’ll add to it throughout the series.

Run locally

npx wrangler dev

This runs your Worker on your machine, using the same engine Cloudflare uses in production. You get a local URL and live reload on save.

Deploy

npx wrangler deploy

This uploads your Worker and makes it live. The first time, it opens your browser to log in.

Watch the logs

When something misbehaves in production, you want to see what’s happening. Stream live logs from your deployed Worker:

npx wrangler tail

Every request and console.log shows up in your terminal as it happens.

Manage secrets

Don’t put API keys in your code. Store them as secrets:

npx wrangler secret put STRIPE_KEY

It prompts you for the value, encrypts it, and makes it available on env.STRIPE_KEY in your Worker. The value never lives in your repo.

Manage your resources

Wrangler also creates and manages the things you attach to a Worker. For example, to create a database:

npx wrangler d1 create my-database

Or apply database migrations:

npx wrangler d1 migrations apply my-database --local

There are similar commands for KV, R2, and Queues. Each gets its own post in this series.

Generate types

If you use TypeScript, this command reads your config and generates types for all your bindings:

npx wrangler types

Now env.DB, env.UPLOADS, and the rest are fully typed. I run this whenever I change my config.

Environments

Real apps have more than one environment: production, staging, maybe a beta. Wrangler handles this with named environments in your config:

{
  "name": "my-worker",
  "env": {
    "staging": {
      "name": "my-worker-staging"
    },
    "production": {
      "name": "my-worker-prod"
    }
  }
}

Then you deploy a specific one:

npx wrangler deploy --env production

Each environment can have its own database, its own secrets, its own domain. I’ll come back to environments in a later post, because there are a couple of gotchas worth knowing.

The pattern to remember

Once you know Wrangler, the workflow for any Cloudflare feature is the same: add it to wrangler.jsonc, create it with a wrangler command, then use it through env in your code.

That consistency is the thing I like most. The full command reference is in the Wrangler docs.

Related posts about cloudflare: