[{"data":1,"prerenderedAt":48},["ShallowReactive",2],{"\u002Fcf-vs-wrangler":3},{"title":4,"description":5,"path":6,"date":7,"updated":8,"verified":7,"category":9,"keywords":10,"officialSources":16,"related":26,"readingTime":30,"html":31,"toc":32},"cf vs Wrangler: what changes?","cf brings API-wide command discovery and TypeScript configuration. Wrangler remains a valid choice while the new CLI is in beta.","\u002Fcf-vs-wrangler","2026-09-29","2026-09-30","Overview",[11,12,13,14,15],"cf vs wrangler","cloudflare cf vs wrangler","wrangler vs cf","cf cli vs wrangler","cloudflare cli comparison",[17,20,23],{"label":18,"url":19},"cf CLI source and README","https:\u002F\u002Fgithub.com\u002Fcloudflare\u002Fcf\u002Ftree\u002Fmain\u002Fpackages\u002Fcli",{"label":21,"url":22},"Cloudflare configuration types and helpers","https:\u002F\u002Fgithub.com\u002Fcloudflare\u002Fworkers-sdk\u002Ftree\u002Fmain\u002Fpackages\u002Fconfig\u002Fsrc",{"label":24,"url":25},"Cloudflare cf launch announcement","https:\u002F\u002Fblog.cloudflare.com\u002Fcloudflare-cf-cli-launch\u002F",[27,28,29],"\u002Fwrangler-to-cf","\u002Fcloudflare-config","\u002Fwrangler-to-cf-commands",2,"\u003Ch2 id=\"the-short-answer\">The short answer\u003C\u002Fh2>\n\u003Cp>Use Wrangler for an established deployment that already works. Try cf in a separate branch when you want its new configuration model or API command discovery. A working production project does not need an immediate CLI migration.\u003C\u002Fp>\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\"># Check which versions you are comparing\u003C\u002Fspan>\ncf --version\nnpx wrangler --version\n\n\u003Cspan class=\"hljs-comment\"># Discover a task instead of guessing a command\u003C\u002Fspan>\ncf cli search \u003Cspan class=\"hljs-string\">"create a D1 database"\u003C\u002Fspan>\n\u003C\u002Fcode>\u003C\u002Fpre>\u003C\u002Fdiv>\u003Ch2 id=\"what-is-different\">What is different?\u003C\u002Fh2>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Concern\u003C\u002Fth>\n\u003Cth>Wrangler\u003C\u002Fth>\n\u003Cth>cf open beta\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>Primary scope\u003C\u002Ftd>\n\u003Ctd>Workers and related developer workflows\u003C\u002Ftd>\n\u003Ctd>Commands generated from the wider Cloudflare API, plus project workflows\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Configuration\u003C\u002Ftd>\n\u003Ctd>wrangler.jsonc, wrangler.json or wrangler.toml\u003C\u002Ftd>\n\u003Ctd>cloudflare.config.ts with typed helpers\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Development\u003C\u002Ftd>\n\u003Ctd>Wrangler bundling or framework integrations\u003C\u002Ftd>\n\u003Ctd>Framework detection and delegation through cf dev\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Deployment\u003C\u002Ftd>\n\u003Ctd>Wrangler’s deployment workflow\u003C\u002Ftd>\n\u003Ctd>Build Output produced by a supported build integration\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Finding commands\u003C\u002Ftd>\n\u003Ctd>Wrangler documentation and help\u003C\u002Ftd>\n\u003Ctd>Intent search, per-command help and API schema inspection\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cp>cf command names often follow an API resource hierarchy. Replacing the word \u003Ccode>wrangler\u003C\u002Fcode> with \u003Ccode>cf\u003C\u002Fcode> is not a reliable conversion strategy. Our \u003Ca href=\"\u002Fwrangler-to-cf-commands\">command reference\u003C\u002Fa> distinguishes documented workflows from API operations.\u003C\u002Fp>\n\u003Ch2 id=\"configuration-changes\">Configuration changes\u003C\u002Fh2>\n\u003Cp>The new format groups bindings under \u003Ccode>worker.env\u003C\u002Fcode>. Helpers such as \u003Ccode>bindings.d1()\u003C\u002Fcode> describe the binding; the key in that object is the name your application receives on \u003Ccode>env\u003C\u002Fcode>.\u003C\u002Fp>\n\u003Cdiv class=\"code-block\">\u003Cdiv class=\"code-toolbar\">\u003Cspan>cloudflare.config.ts\u003C\u002Fspan>\u003Cbutton type=\"button\" data-copy-code aria-label=\"Copy code\">Copy\u003C\u002Fbutton>\u003C\u002Fdiv>\u003Cpre>\u003Ccode class=\"hljs language-ts\">\u003Cspan class=\"hljs-keyword\">import\u003C\u002Fspan> { bindings, defineConfig } \u003Cspan class=\"hljs-keyword\">from\u003C\u002Fspan> \u003Cspan class=\"hljs-string\">"cf\u002Fconfig"\u003C\u002Fspan>;\n\n\u003Cspan class=\"hljs-keyword\">export\u003C\u002Fspan> \u003Cspan class=\"hljs-keyword\">default\u003C\u002Fspan> \u003Cspan class=\"hljs-title function_\">defineConfig\u003C\u002Fspan>({\n  \u003Cspan class=\"hljs-attr\">worker\u003C\u002Fspan>: {\n    \u003Cspan class=\"hljs-attr\">name\u003C\u002Fspan>: \u003Cspan class=\"hljs-string\">"notes-worker"\u003C\u002Fspan>,\n    \u003Cspan class=\"hljs-attr\">compatibilityDate\u003C\u002Fspan>: \u003Cspan class=\"hljs-string\">"2026-09-29"\u003C\u002Fspan>,\n    \u003Cspan class=\"hljs-attr\">entrypoint\u003C\u002Fspan>: \u003Cspan class=\"hljs-string\">".\u002Fsrc\u002Findex.ts"\u003C\u002Fspan>,\n    \u003Cspan class=\"hljs-attr\">env\u003C\u002Fspan>: {\n      \u003Cspan class=\"hljs-attr\">DB\u003C\u002Fspan>: bindings.\u003Cspan class=\"hljs-title function_\">d1\u003C\u002Fspan>({ \u003Cspan class=\"hljs-attr\">name\u003C\u002Fspan>: \u003Cspan class=\"hljs-string\">"notes-db"\u003C\u002Fspan> }),\n    },\n  },\n});\n\u003C\u002Fcode>\u003C\u002Fpre>\u003C\u002Fdiv>\u003Cp>This is an ordinary Worker example, not a Nuxt entrypoint. Framework adapters own their build output and may need different integration steps.\u003C\u002Fp>\n\u003Ch2 id=\"when-to-keep-wrangler\">When to keep Wrangler\u003C\u002Fh2>\n\u003Cp>Keep your existing workflow if the framework integration you need has an unresolved cf issue, your CI depends on Wrangler-specific flags, or you cannot yet validate parity for your bindings and deployment targets. Beta status is a reason to test deliberately, not a reason to assume either tool is unusable.\u003C\u002Fp>\n\u003Cp>For example, the \u003Ca href=\"\u002Ferrors\u002Fcf-deploy-mode-nuxt\">Nuxt mode issue\u003C\u002Fa> affects a specific build delegation path in cf 1.0.0-beta.5. It does not prove that every Nuxt deployment fails.\u003C\u002Fp>\n\u003Ch2 id=\"a-practical-migration-path\">A practical migration path\u003C\u002Fh2>\n\u003Cp>Create a branch, save your current configuration and run \u003Ccode>cf migrate --dry-run\u003C\u002Fcode>. Review the planned edits before applying them. Then check local behavior, generated configuration, scripts and deployment targets.\u003C\u002Fp>\n\u003Cp>Follow the \u003Ca href=\"\u002Fwrangler-to-cf\">migration guide\u003C\u002Fa> and the \u003Ca href=\"\u002Fcloudflare-config\">configuration guide\u003C\u002Fa>. Keep the original workflow available until your migrated project has passed its own checks.\u003C\u002Fp>\n",[33,36,39,42,45],{"id":34,"text":35},"the-short-answer","The short answer",{"id":37,"text":38},"what-is-different","What is different?",{"id":40,"text":41},"configuration-changes","Configuration changes",{"id":43,"text":44},"when-to-keep-wrangler","When to keep Wrangler",{"id":46,"text":47},"a-practical-migration-path","A practical migration path",1790729614466]