# Wrangler: the Cloudflare Workers command line tool

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

Author: Flavio Copes | Published: 2026-06-21 | Canonical: https://flaviocopes.com/cloudflare-wrangler/

If you build on [Cloudflare Workers](https://flaviocopes.com/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:

```jsonc
{
  "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

```bash
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

```bash
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:

```bash
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:

```bash
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:

```bash
npx wrangler d1 create my-database
```

Or apply database migrations:

```bash
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](https://flaviocopes.com/typescript/), this command reads your config and generates types for all your bindings:

```bash
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:

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

Then you deploy a specific one:

```bash
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](https://developers.cloudflare.com/workers/wrangler/).