How to Use Cloudflare cf CLI

The practical win is not a shorter command. It is less integration work. A founder can inspect an account without hunting through the dashboard, a platform team can give an agent machine-readable results, and an agency can standardize Cloudflare work across client accounts without maintaining a separate API wrapper for every product.

There is no separate cf license to buy. The repository is open source, a small Worker can start on Cloudflare's Free plan, and Workers Paid has a $5 monthly minimum. At the other end of the budget, a general infrastructure governance platform such as Spacelift lists a $20,000 Starter+ tier. cf removes much of the API plumbing between those ends. It does not remove the need for approvals, audit trails, or careful permissions.

What the new cf CLI actually is

cf is a generated command surface for the whole Cloudflare API, plus hand-built project workflows for tasks such as creating, building, migrating, and deploying Workers. Think of Wrangler as a well-stocked specialist bench for Workers. cf adds the directory and service counter for the full Cloudflare building, then keeps sending some Worker jobs back to Wrangler when that is still the reliable tool.

That distinction also separates this release from Cloudflare's April 13 technical preview. The April build covered only a small subset of products. The September open beta is the release with full API coverage, default JSON results, command search, TypeScript Worker configuration, and Vite as the default Worker path.

The four pieces that change the workflow are straightforward:

• Full API surface: generated commands follow cf <product> [group…] <operation> across more than 3,000 operations.
• Command search: cf cli search takes a plain-language job and returns five ranked JSON matches. You do not need to memorize the command tree.
• JSON by default: structured API results go to standard output as pretty-printed JSON, which means a person, a script, or a coding agent can filter the same response.
• Typed Worker setup: cloudflare.config.ts gives editors and coding agents TypeScript feedback. It starts with Workers today. Whole-account configuration for DNS, zones, and policies is a future direction, not current functionality.

Install, authenticate, and prove one read

Start with a read-only operation. It confirms the package, credential, account selection, command discovery, and JSON path before you let a script change anything.

The official package requires Node.js 22 or newer. For a person at a terminal, cf auth login manages the default OAuth profile. For CI, set a narrowly scoped CLOUDFLARE_API_TOKEN; cf checks that environment variable before any stored OAuth profile. Named profiles can be created and bound to different directories when you work across client or company accounts.

Keep the text you give cf cli search generic. Ask for the action and resource type, not a domain, email address, account ID, or token.

node --version
npm i -g cf
cf --version

cf auth login
cf auth whoami

cf cli search "list zones in an account"
cf zones list | jq -e 'type == "array" and all(.[]; has("name") and has("status"))'

The search currently ranks cf zones list first for that job. The final line is the proof: it makes a read-only API call and exits successfully only when the result is a JSON array whose entries include name and status. If you have several accounts, select a named profile with --profile or filter the command with --account-id.

Do not paste a token into shell history. Put a scoped token in the process environment used by CI, and give it only the read or write permissions the job needs. OAuth is the more comfortable default for an individual terminal session because cf can refresh the selected profile.

What the disposable test established

A fresh isolated install on September 29 returned cf v1.0.0-beta.5. Command search returned a valid five-item JSON array, cf init created a typed Worker project, and both the new project and a migrated Vite fixture built locally. The environment did not contain a Cloudflare test-account credential, so the authenticated zones read and a deployment were not represented as completed tests.

That last boundary matters. A successful local build proves the project path. It does not prove that the token has the right production permissions or that a deployment reached Cloudflare.

Create a small Worker, then inspect what cf made

cf init is the quickest clean test of the new project workflow. In an empty directory it creates TypeScript source, cloudflare.config.ts, vite.config.ts, package scripts, and generated Worker types. cf build then delegates to the Cloudflare Vite Plugin and produces standardized Build Output.

cf init hello-cf --package-manager npm
cd hello-cf
npm run build

# In a copied existing Vite Worker:
cf migrate --dry-run
cf migrate
npm run build

Open cloudflare.config.ts after either path. For a basic Worker, expect a worker block with its name, compatibility date, entrypoint, and typed bindings. A text binding is declared through the configuration API rather than copied through several environment blocks. That is where TypeScript earns its place: a misspelled field can become editor feedback before it becomes a failed deployment.

The generated Vite setup is not decoration. Vite is now the default local development and build path for cf, and Cloudflare recommends its Vite plugin for both frontends and backend APIs. In the disposable project, npm run build delegated to Vite and completed. Deployment was deliberately left out. When your review and account test are complete, the documented cf deploy command builds and uploads by default.

Where Wrangler still belongs

Do not remove Wrangler just because cf installed successfully. The right migration decision depends on the project's build path.

For an existing Vite Worker, cf migrate can translate Wrangler JSON, JSONC, or TOML into cloudflare.config.ts. The command detects the Cloudflare Vite plugin beside the Wrangler configuration and chooses the Vite path. If the plugin is not declared, current beta releases choose the Wrangler bundler instead. Run the dry preview, read every follow-up item, and migrate a copy or clean branch before touching the working project.

For JavaScript Workers that still depend on Wrangler's esbuild behavior, cf delegates development and deployment to Wrangler. It does the same for Rust and Python Workers. This is compatibility, not a failed migration. The team gets cf as the front door while the proven builder stays in the path.

Cloudflare's support clock is also easy to misread. Wrangler maintenance is planned for 18 months after the open beta ends, not 18 months from the September 28 launch. There is no reason to force a Rust, Python, or esbuild project through a Vite conversion this week.

Seven workflows that pay off first

The best first use cases share one property: they replace repeated lookup and formatting work without granting broad write access on day one.

1. An agency standardizes account checks

An agency operator can bind a named OAuth profile to each client directory, search for the relevant read command, and emit the same JSON shape into a review script. That cuts the drift caused by one engineer clicking through dashboards while another maintains a custom curl command. The payoff is repeatability across client work, especially for DNS, zones, account settings, and security reviews.

2. A platform team gives coding agents a safe Cloudflare interface

A platform lead can put an AGENTS.md rule around cf cli search, allow read commands by default, and require human approval for mutations. Search keeps the agent from guessing old Wrangler syntax, while JSON keeps output compact and filterable. This is most useful when the team already asks agents to inspect build status, logs, queues, or account resources and wants one predictable interface.

3. An on-call engineer gathers incident context

During an incident, the operator can search for the right logs, zone, ruleset, or analytics read instead of browsing several product panels. The exact command still matters, and permissions still apply, but the discovery step is now local and the response is ready for jq. For teams running jobs such as Cloudflare Browser Run, that gives the responder a faster path from a failed job to the surrounding account state.

4. A founder starts one Worker without designing a toolchain

A founder building a webhook, redirect service, or small internal API can run cf init, inspect the generated Worker and binding, then use the Vite build without choosing each package separately. The project can begin on Workers Free. If it needs the paid plan, the current minimum is $5 per account per month. The payoff is a short path to a reviewable local artifact, not a promise that production operations become free.

5. A Vite team converts configuration without rewriting the app

An engineering team with a Vite-based Worker can run cf migrate --dry-run on a copy, inspect the generated TypeScript, then build before changing deployment. This is particularly useful when environment blocks have become repetitive. The new format can calculate configuration from a shared base, but the team should migrate behavior, not merely file syntax.

6. A data or operations team feeds Cloudflare reads into reports

Because structured results are JSON by default, an operator can pipe a read into jq, a warehouse loader, or a scheduled report without scraping a Unicode table. The business payoff is boring in the best way: fewer output adapters and fewer fragile parsing rules. Use a scoped read token and keep the command output out of public CI logs.

7. A Worker team inspects local resources before touching production

Supported commands accept --local and talk to a short-lived Miniflare instance backed by local state. That includes defined operations across KV, D1, and R2. If no local equivalent exists, cf returns an error rather than silently falling through to production. A team building a Cloudflare AI Search Worker can use that boundary to test supporting local data without turning a development command into a remote write.

Two products worth building around cf

The CLI itself is not the product opportunity. The opportunity sits in the control layer that teams still need around a very broad API surface.

Best opportunity: Cloudflare change control for agencies

Build a narrow approval and evidence layer for agencies or small platform teams managing several Cloudflare accounts. A user proposes a DNS, zone, WAF, or Worker change; the product uses cf to collect the current JSON state, shows a human-readable diff, requests approval, executes with a scoped profile, and stores the result.

The demand signal is modest but commercial: cloudflare dns management receives about 170 US searches per month, carries a $6 CPC, and shows top-of-page bids from $3.85 to $36.64. General infrastructure governance also supports real budgets. Spacelift lists Starter+ at $20,000. A Cloudflare-specific product can be cheaper and easier to adopt because it does not need to govern every cloud.

The smallest sellable version is a GitHub app or hosted review queue for DNS and Worker changes, with profile isolation, an allowlist of commands, before-and-after JSON, and one-click rollback where the underlying API supports it. The catch is the moat: cf already supplies command coverage, so the defensible work is policy, evidence, permissions, and agency workflow. A thin graphical wrapper will be copied quickly.

Useful feature: Worker migration readiness

Build a scanner that classifies a repository as native Vite, Wrangler-backed esbuild, Python, or Rust, then runs the safe migration preview and turns follow-up items into a pull-request checklist. Buyers are teams with a portfolio of Workers, not a solo developer migrating one small project.

Demand is too small for this to be the whole company. cloudflare worker deployment receives about 10 US searches per month, although the query has transactional intent. The sensible MVP is a paid feature inside a Cloudflare operations product or a migration service: repository scan, cf migrate --dry-run, build verification, and a clear Wrangler fallback report. The catch is release churn during beta. The scanner must follow cf and Cloudflare Vite Plugin versions closely or its advice will age faster than the projects it checks.

Limits and the honest decision

Use cf now for command discovery, JSON-first account reads, new Vite Workers, and careful migration trials. Keep Wrangler installed where cf delegates to it, and keep production writes behind explicit scopes and review.

The open beta does not yet make cloudflare.config.ts a whole-account source of truth. It begins with Workers. It also does not turn every Cloudflare API operation into a safe business workflow. Full API coverage increases what a token can reach, which makes least privilege and command review more important, not less.

The local option is deliberately bounded. Supported KV, D1, R2, Durable Object, and Workflow operations can use local state, but an operation without a local explorer equivalent errors. That is a good safety property, but it means --local is not a universal offline mirror of Cloudflare.

Finally, beta releases move quickly. Pin cf in project dependencies for team work, review the generated configuration, and make CI use the local project version. A global install is convenient for discovery; a pinned version is how collaborators get the same behavior.

If you want a safe Cloudflare automation path designed and built for your team, see AI production systems.