[{"data":1,"prerenderedAt":51},["ShallowReactive",2],{"\u002Fwrangler-to-cf-commands":3},{"title":4,"description":5,"path":6,"date":7,"updated":8,"verified":8,"category":9,"keywords":10,"officialSources":16,"related":29,"readingTime":33,"html":34,"toc":35},"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.","\u002Fwrangler-to-cf-commands","2026-09-29","2026-09-30","Reference",[11,12,13,14,15],"wrangler to cf commands","cf command reference","wrangler cf command differences","cf cli search commands","cf d1 migrations apply",[17,20,23,26],{"label":18,"url":19},"Official Wrangler to cf reference","https:\u002F\u002Fdevelopers.cloudflare.com\u002Fcf\u002Fwrangler\u002Freference\u002F",{"label":21,"url":22},"Official cf project commands","https:\u002F\u002Fdevelopers.cloudflare.com\u002Fcf\u002Fprojects\u002F",{"label":24,"url":25},"cf CLI source and README","https:\u002F\u002Fgithub.com\u002Fcloudflare\u002Fcf\u002Ftree\u002Fmain\u002Fpackages\u002Fcli",{"label":27,"url":28},"D1 migration command implementation","https:\u002F\u002Fgithub.com\u002Fcloudflare\u002Fcf\u002Ftree\u002Fmain\u002Fpackages\u002Fcli\u002Fsrc\u002Fcommands\u002Fd1\u002Fmigrations",[30,31,32],"\u002Fwrangler-to-cf","\u002Fcf-deploy","\u002Fcloudflare-config",3,"\u003Ch2 id=\"discover-before-converting\">Discover before converting\u003C\u002Fh2>\n\u003Cdiv class=\"code-block\">\u003Cdiv class=\"code-toolbar\">\u003Cspan>Terminal\u003C\u002Fspan>\u003Cbutton type=\"button\" data-copy-code aria-label=\"Copy code\">Copy\u003C\u002Fbutton>\u003C\u002Fdiv>\u003Cpre>\u003Ccode class=\"hljs language-bash\">cf cli search \u003Cspan class=\"hljs-string\">"create a D1 database"\u003C\u002Fspan>\ncf d1 create --\u003Cspan class=\"hljs-built_in\">help\u003C\u002Fspan>\ncf schema d1 create\n\u003C\u002Fcode>\u003C\u002Fpre>\u003C\u002Fdiv>\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"common-project-workflows\">Common project workflows\u003C\u002Fh2>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Wrangler workflow\u003C\u002Fth>\n\u003Cth>cf workflow\u003C\u002Fth>\n\u003Cth>What to review\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>wrangler login\u003C\u002Ftd>\n\u003Ctd>cf auth login\u003C\u002Ftd>\n\u003Ctd>OAuth profile and account selection\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>wrangler dev\u003C\u002Ftd>\n\u003Ctd>cf dev\u003C\u002Ftd>\n\u003Ctd>Framework detection and local resource behavior\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>wrangler deploy\u003C\u002Ftd>\n\u003Ctd>cf deploy\u003C\u002Ftd>\n\u003Ctd>Builds first; needs supported Build Output\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>wrangler types\u003C\u002Ftd>\n\u003Ctd>cf workers types\u003C\u002Ftd>\n\u003Ctd>Generated type location and config integration\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Existing config migration\u003C\u002Ftd>\n\u003Ctd>cf migrate\u003C\u002Ftd>\n\u003Ctd>Official migration; inspect the diff\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>wrangler tail\u003C\u002Ftd>\n\u003Ctd>No direct equivalent documented here\u003C\u002Ftd>\n\u003Ctd>Search current CLI surface; do not use tunnel tail as a Worker substitute\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cp>The project commands above are verified in the installed beta. They are workflow counterparts, not promises of identical flags.\u003C\u002Fp>\n\u003Ch2 id=\"data-and-storage-workflows\">Data and storage workflows\u003C\u002Fh2>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Wrangler command\u003C\u002Fth>\n\u003Cth>Current workflow\u003C\u002Fth>\n\u003Cth>Important difference\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>wrangler d1 create NAME\u003C\u002Ftd>\n\u003Ctd>cf d1 create --name NAME\u003C\u002Ftd>\n\u003Ctd>The generated command uses a named option\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>wrangler d1 migrations apply DATABASE\u003C\u002Ftd>\n\u003Ctd>cf d1 migrations apply DATABASE_ID --dir migrations\u003C\u002Ftd>\n\u003Ctd>cf requires the database ID, not a binding name\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>wrangler r2 bucket create NAME\u003C\u002Ftd>\n\u003Ctd>cf r2 buckets create --name NAME\u003C\u002Ftd>\n\u003Ctd>Resource hierarchy is plural: buckets\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>wrangler kv namespace create NAME\u003C\u002Ftd>\n\u003Ctd>cf kv namespaces create --title NAME\u003C\u002Ftd>\n\u003Ctd>Returns the namespace ID used in config\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>wrangler secret put KEY\u003C\u002Ftd>\n\u003Ctd>npx wrangler secret put KEY --name WORKER_NAME\u003C\u002Ftd>\n\u003Ctd>cf cannot set one Worker secret yet; Wrangler still supports this workflow\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cdiv class=\"code-block\">\u003Cdiv class=\"code-toolbar\">\u003Cspan>Terminal\u003C\u002Fspan>\u003Cbutton type=\"button\" data-copy-code aria-label=\"Copy code\">Copy\u003C\u002Fbutton>\u003C\u002Fdiv>\u003Cpre>\u003Ccode class=\"hljs language-bash\">\u003Cspan class=\"hljs-comment\"># Upload secrets with a new cf Worker version instead\u003C\u002Fspan>\ncf deploy --secrets-file .secrets.local.json\n\n\u003Cspan class=\"hljs-comment\"># Inspect D1 migration arguments before applying anything\u003C\u002Fspan>\ncf d1 migrations apply --\u003Cspan class=\"hljs-built_in\">help\u003C\u002Fspan>\n\u003C\u002Fcode>\u003C\u002Fpre>\u003C\u002Fdiv>\u003Cp>\u003Ccode>cf d1 migrations apply\u003C\u002Fcode> affects remote data by default. Use the documented \u003Ccode>--local\u003C\u002Fcode> flag when you mean the local simulation, and explicitly check the target ID before applying production migrations.\u003C\u002Fp>\n\u003Cp>Keep the secrets file private and out of version control. \u003Ccode>--secrets-file\u003C\u002Fcode> accepts JSON or \u003Ccode>.env\u003C\u002Fcode> format and uploads the values with a new Worker version; it is not a single-secret update. See the \u003Ca href=\"https:\u002F\u002Fdevelopers.cloudflare.com\u002Fcf\u002Fwrangler\u002Freference\u002F\">official command mapping\u003C\u002Fa> for the current beta behavior.\u003C\u002Fp>\n\u003Ch2 id=\"commands-without-a-confirmed-mapping\">Commands without a confirmed mapping\u003C\u002Fh2>\n\u003Cp>Do not infer \u003Ccode>cf d1 execute\u003C\u002Fcode>, \u003Ccode>cf secret put\u003C\u002Fcode> or \u003Ccode>cf tail\u003C\u002Fcode> from Wrangler syntax. Generated API operations may have a different resource shape or accept raw request bodies.\u003C\u002Fp>\n\u003Cp>For a workflow not listed here, use \u003Ccode>cf cli search\u003C\u002Fcode>, 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.\u003C\u002Fp>\n\u003Ch2 id=\"migration-is-more-than-command-names\">Migration is more than command names\u003C\u002Fh2>\n\u003Cp>The configuration format and build contract change as well. Read \u003Ca href=\"\u002Fcloudflare-config\">cloudflare.config.ts\u003C\u002Fa>, review \u003Ca href=\"\u002Fwrangler-to-cf\">cf migrate\u003C\u002Fa>, and compare mode behavior before replacing deployment scripts.\u003C\u002Fp>\n",[36,39,42,45,48],{"id":37,"text":38},"discover-before-converting","Discover before converting",{"id":40,"text":41},"common-project-workflows","Common project workflows",{"id":43,"text":44},"data-and-storage-workflows","Data and storage workflows",{"id":46,"text":47},"commands-without-a-confirmed-mapping","Commands without a confirmed mapping",{"id":49,"text":50},"migration-is-more-than-command-names","Migration is more than command names",1790729614467]