wrangler

Run wrangler deploy from your project directory after configuring wrangler.jsonc with your Worker name, main entry point, and compatibility date. Use wrangler deploy --dry-run to validate first, and wrangler deploy --env staging to target a specific environment.

Use wrangler secret put API_KEY with the interactive prompt to set secrets securely, or wrangler secret bulk secrets.json for multiple values. Never pass secret values as command arguments or commit them to wrangler.jsonc; use .dev.vars for local development secrets.

Prefer wrangler.jsonc because newer Wrangler features are JSON-only. Include the $schema field pointing to node_modules/wrangler/config-schema.json for validation and autocompletion of config fields and binding shapes.

Create migrations with wrangler d1 migrations create, then apply them locally using wrangler d1 migrations apply my-database --local or to production with --remote. List pending migrations with wrangler d1 migrations list before applying.

The binding name in your code must exactly match the binding name in wrangler.jsonc. Run wrangler types to regenerate TypeScript definitions after config changes, and note that some bindings like Workers AI require remote: true to work locally.

Yes, start the dev server with wrangler dev --test-scheduled, then visit http://localhost:8787/__scheduled to trigger the scheduled handler manually. This simulates cron events without deploying to Cloudflare.