Use Wrangler development tools

Wrangler is the Cloudflare CLI. It’s the one tool that connects your source code, your configuration, the local emulator, your bindings, deployment, and production logs. You use it dozens of times a day, so let’s learn the three commands that matter most.

npx wrangler dev
npx wrangler types
npx wrangler deploy --dry-run

wrangler dev runs the Worker locally. wrangler types regenerates worker-configuration.d.ts from your config. wrangler deploy --dry-run bundles and validates everything without publishing.

Local by default

wrangler dev runs your code in a local copy of the Workers runtime, with local copies of D1, KV, R2, and Queues. Data lives in a .wrangler/state folder on your machine. You can delete it and start clean any time.

That’s the default for a reason. A development command should never be able to touch real users’ data by accident.

When you do need the real thing, add --remote. Use it only for a test that depends on real behavior, and only with disposable data. Before running anything that writes, read the active environment and the binding names Wrangler prints at startup. Local and remote resources often share similar names, and that’s where mistakes happen.

Regenerate types after every config change

Each binding you add to wrangler.jsonc becomes a property on env. Run wrangler types right after editing the config, and env.DB shows up with the right type in your editor. Skip it and TypeScript complains about a property that clearly exists in the config.

Don’t maintain a second Env interface by hand. It will drift from the config, and the compiler will trust the wrong one.

What a dry run proves, and what it doesn’t

wrangler deploy --dry-run proves the bundle builds and the configuration is valid. That’s it.

It does not prove production secrets exist, that remote migrations ran, or that a downstream API is reachable. For those, keep a short smoke check you run against the deployed Worker: one curl to the health route, one request that touches each binding.

Reading production logs

wrangler tail streams live logs from the deployed Worker to your terminal. It’s great for watching one request go through while you debug.

Be careful with it though. The stream can be sampled under load, and nothing is stored. Close the terminal and the evidence is gone. Production observability needs retained logs, which we set up in the last module.

Now try the loop on your own project. Add a variable to wrangler.jsonc:

{
  "vars": { "ENVIRONMENT": "development" }
}

Run npx wrangler types and check that ENVIRONMENT appears in worker-configuration.d.ts. Then run npx wrangler deploy --dry-run and confirm it ends with a success message and no warnings.