Reference
Wrangler → cf command reference
A focused comparison of common Workers workflows, checked against cf 1.0.0-beta.5. API command names and arguments can differ.
Discover before converting
cf cli search "create a D1 database"
cf d1 create --help
cf schema d1 create
Intent search identifies the current command. Help explains its CLI arguments. Schema inspection shows the underlying API request. Keep search queries generic: task and resource type are enough.
Common project workflows
| Wrangler workflow | cf workflow | What to review |
|---|---|---|
| wrangler login | cf auth login | OAuth profile and account selection |
| wrangler dev | cf dev | Framework detection and local resource behavior |
| wrangler deploy | cf deploy | Builds first; needs supported Build Output |
| wrangler types | cf workers types | Generated type location and config integration |
| Existing config migration | cf migrate | Official migration; inspect the diff |
| wrangler tail | No direct equivalent documented here | Search current CLI surface; do not use tunnel tail as a Worker substitute |
The project commands above are verified in the installed beta. They are workflow counterparts, not promises of identical flags.
Data and storage workflows
| Wrangler command | Current workflow | Important difference |
|---|---|---|
| wrangler d1 create NAME | cf d1 create --name NAME | The generated command uses a named option |
| wrangler d1 migrations apply DATABASE | cf d1 migrations apply DATABASE_ID --dir migrations | cf requires the database ID, not a binding name |
| wrangler r2 bucket create NAME | cf r2 buckets create --name NAME | Resource hierarchy is plural: buckets |
| wrangler kv namespace create NAME | cf kv namespaces create --title NAME | Returns the namespace ID used in config |
| wrangler secret put KEY | npx wrangler secret put KEY --name WORKER_NAME | cf cannot set one Worker secret yet; Wrangler still supports this workflow |
# Upload secrets with a new cf Worker version instead
cf deploy --secrets-file .secrets.local.json
# Inspect D1 migration arguments before applying anything
cf d1 migrations apply --help
cf d1 migrations apply affects remote data by default. Use the documented --local flag when you mean the local simulation, and explicitly check the target ID before applying production migrations.
Keep the secrets file private and out of version control. --secrets-file accepts JSON or .env format and uploads the values with a new Worker version; it is not a single-secret update. See the official command mapping for the current beta behavior.
Commands without a confirmed mapping
Do not infer cf d1 execute, cf secret put or cf tail from Wrangler syntax. Generated API operations may have a different resource shape or accept raw request bodies.
For a workflow not listed here, use cf cli search, then inspect one matching command. If no direct equivalent is documented, keep the working Wrangler command while you investigate. This reference intentionally does not list thousands of generated API operations.
Migration is more than command names
The configuration format and build contract change as well. Read cloudflare.config.ts, review cf migrate, and compare mode behavior before replacing deployment scripts.