> setup & auth

Every wrangler session starts here: authenticate the CLI against your Cloudflare account, confirm you're pointed at the right account, and scaffold or wire up a project. These commands establish the credentials, config, and generated types that your later dev, deploy, and binding work builds on.

// setup & auth

7 commands
Log in to Cloudflare with OAuth
$ wrangler login
Log in on a headless server or authenticate CI
$ wrangler login --browser false
Check which account you're authenticated as
$ wrangler whoami
Verify authentication in a CI script
$ wrangler whoami --json
Scaffold a new Worker project
$ wrangler init <name> -y
Import an existing dashboard Worker for local dev
$ wrangler init <name> --from-dash <worker-name>
Generate TypeScript types for your bindings
$ wrangler types

// faq

Where does wrangler store my login, and how do I authenticate in CI?

`wrangler login` runs an interactive OAuth flow and caches a refreshable token under your OS config dir (e.g. ~/.config/.wrangler). CI and headless boxes should skip the browser entirely: set the CLOUDFLARE_API_TOKEN environment variable (and usually CLOUDFLARE_ACCOUNT_ID) and wrangler picks it up automatically.

What's the difference between `wrangler login` and a CLOUDFLARE_API_TOKEN?

`login` is an interactive OAuth grant that stores a refreshable credential for local dev. An API token is a static, scoped credential you export as an env var for automation. A CLOUDFLARE_API_TOKEN in the environment takes precedence over a cached OAuth login.

How often do I need to re-run `wrangler types`?

Whenever you add or change a binding (KV, R2, D1, vars, Hyperdrive, Queues...) or bump your compatibility date. Regenerate, then commit the resulting worker-configuration.d.ts so your editor and CI share the same Env types.

// categories

> view all wrangler commands