Building a CLI for all of Cloudflare (opens in new tab)
Cloudflare is rebuilding Wrangler into a unified CLI for its entire platform, motivated by the growing role of coding agents in configuring and deploying Cloudflare applications. The technical preview, available as npx cf or the globally installed cf package, currently covers only a subset of products but is intended to support the full API surface. The effort depends on a new TypeScript-based schema system that can generate consistent commands, configuration, bindings, documentation, and agent-oriented interfaces.
A CLI for all of Cloudflare
- Cloudflare offers more than 100 products and nearly 3,000 HTTP API operations.
- Agents increasingly use Cloudflare APIs to:
- Build and deploy applications
- Configure accounts
- Query analytics and logs
- Create agents and platforms
- Cloudflare aims to expose its products consistently through:
- CLI commands
- Workers Bindings
- SDKs
- Configuration files
- Terraform
- Documentation and OpenAPI schemas
- MCP servers and Agent Skills
- The new Wrangler technical preview can be tried with:
npx cfnpm install -g cf
- A broader internal version already supports the full Cloudflare API, with ongoing work to make command output useful for both humans and agents.
A new schema and code-generation pipeline
- Existing OpenAPI schemas already generate:
- Cloudflare SDKs
- The Terraform provider
- The Code Mode MCP server
- Other interfaces, including Wrangler commands, Workers Bindings, configuration, documentation, and Agent Skills, were previously maintained manually.
- Manual synchronization was error-prone and could not scale to Cloudflare’s full product range.
- OpenAPI alone is insufficient because it primarily describes REST APIs, while Cloudflare also needs to represent:
- Interactive CLI workflows
- Multiple local and remote actions
- RPC-style Workers Bindings
- Agent Skills and related documentation
- Cloudflare therefore created a TypeScript schema format containing:
- API definitions
- CLI commands and arguments
- Context required to generate different interfaces
- Conventions, linting, and guardrails enforce consistency while allowing the schema to generate OpenAPI and future interfaces.
Consistency for agents and humans
- Agents depend on predictable command names and flags. Inconsistent syntax can cause them to call commands that do not exist.
- Cloudflare is enforcing conventions at the schema layer, including:
get, neverinfo--force, never--skip-confirmations--json, never--format
- Applying these rules across interfaces avoids discrepancies between the CLI, REST APIs, and SDKs.
- Wrangler must also clearly distinguish local and remote resources.
- This is especially important for D1, R2, and KV, where local simulation and remote bindings can coexist.
- Clear defaults and output indicating whether an operation targets local or remote resources help agents avoid modifying the wrong environment.
Local Explorer for simulated resources
- Local Explorer is available in open beta through Wrangler and the Cloudflare Vite plugin.
- It lets developers inspect locally simulated:
- KV
- R2
- D1
- Durable Objects
- Workflows
- Local resources use the same underlying API structure as Cloudflare’s remote APIs and Dashboard.
- Cloudflare’s local development environment runs Workers APIs locally, including D1 backed by SQLite through Miniflare.
- Previously, developers had to inspect
.wrangler/stateor use third-party tools to understand local data. - Local Explorer provides an interface showing:
- Which bindings are attached to a Worker
- What data those bindings contain
- It can be opened with the
ekeyboard shortcut and helps developers or agents verify schemas, seed test data, and reset local databases.
Cloudflare’s direction is to make Wrangler a consistent, machine-readable interface to the entire platform. The technical preview is early, but the new schema-driven system and Local Explorer establish the foundation for a CLI that is easier for both developers and coding agents to use safely.