> Tell us your hopes and dreams for a Cloudflare-wide CLI
It'd be great if the Wrangler CLI could display the required API token permissions upfront during local dev, so you know exactly what to provision before deploying. Even better if there were something like a cf permissions check command that tells you what's missing or unneeded perms with an API key.
Wonderful post and I will be taking inspiration from it. Surprised not to see TypeSpec https://typespec.io/ mentioned, which is a TypeScript-like schema language that I like to describe as "what if OpenAPI was good". I'm guessing they considered it and decided building their own would be both simpler and more flexible. The cost of BYO has come down a lot thanks to agents.
Please add resource groups and the ability to enforce permissions per resource group before you do this so that we don’t have agents (or people) blowing up prod from their command line. Thank you.
Currently you can only enforce zone-based permissions (domain based) BUT plenty of resources, such as workers, don’t belong to zones so essentially their code can be replaced or deleted with the lowest level permission. And there’s no way to block it…
Alternatively if you could please allow us to create multiple accounts that share a single super account (for SSO and such), similar to GitHub Enterprise which has Enterprises and Organisations. Then we could have ACME Corp. and ACME Corp (Prod) and segregate the two and resource groups wouldn’t be strictly required.
The trend of CLI-first design because AI agents need it is interesting. We ended up in the same place building developer tools, the CLI and API came first because that's what agents actually consume. The dashboard came after.
The cf permissions check idea from the top comment is great. One thing I've found is that agents are surprisingly good at using CLIs but terrible at diagnosing why a command failed. Clear error messages with the exact fix ("missing scope X, run cf token add --scope X") matter way more for agent usability than the happy path.
> You can try the technical preview today by running npx cf. Or you can install it globally by running npm install -g cf.
A couple of obvious questions - Is it open source (npmjs side doesn't point to repo)? And in general will it be available as a single binary instead of requiring nodejs tooling to install/use? If so, using recently-acquired Bun or another product/approach?
I found that agents can already figure out how to do everything in CloudFlare as long as they have an API token with the right privileges. They are smart enough to figure out how to use the API. But the friction spot is that I need to make the API token by hand and basically add permission to do everything they might ever need to do. It would be nice to have a smoother way to handle the permissions so I can let them do everything they need to do frequently without asking for permission yet still make it easy to approve actions that are only needed occasionally, without having to guess in advance which permissions fall into which category
> Tell us your hopes and dreams for a Cloudflare-wide CLI
No long lived tokens, or at least a very straightforward configuration to avoid them.
One option: an easy tool to make narrowly scoped, very short lived tokens, in a file, and maybe even a way to live-update the file (so you can bind mount it).
Another option: a proxy mode that can narrow the scope. So I set it up on a host, then if I want to give a container access to one domain or one bucket or whatever, I ask the host CLI to become a proxy that gives the relevant subset of its permissions to the proxied client, and I connect the container to it.
Ironically, with the advent of AI agents and stuff, we're going back from "checkbox engineering" in GUI webpages to CLI tools. Every time I need to clear cache in cloudflare when I upload a new version of an asset, I have to click through a bunch of things. Would be nice to just message my openclaw agent to do it.
> So we introduced a new TypeScript schema that can define the full scope of APIs, CLI commands and arguments, and context needed to generate any interface. The schema format is “just” a set of TypeScript types with conventions, linting, and guardrails to ensure consistency.
I'm confused though, why isn't that tool/framework being shown here. What is it and how does it work? It is similar to the TypeSpec tool someone else posted?
> Tell us your hopes and dreams for a Cloudflare-wide CLI
Initial impression:
-h and --help should follow the short / long standard of providing more / less info. The approach currently used is -h and --help show command lists and point at a --help-full flag. The --help-full output seems to give what I'd expect on -h. This needs to be much better - it should give enough information that a user / coding agen doesn't have to read websites / docs to understand how the feature works.
Completions are broken by default compared to the actual list of commands - i.e. dns didn't show up in the list.
When I ran cf start -h it prompted to install completions (this was odd because completions were already installed / detected). But either way, -h should never do anything interactive
Some parts of the cli seem very different to the others (e.g. cf domains -h is very different to cf dns -h). Color / lack of color, options, etc.
I will be adding support for Cloudflare for https://github.com/sufield/stave soon. Currently it supports AWS, Azure and GCP. I have been using AWS CLI for end to end testing. Where can I get support if I run into problems during development?
The restish tool by the author of Huma is functionally correct, but I'm finding the models are not doing a great job at inferring the syntax. Admittedly I am having a hard time following the syntax too.
I really dislike wrangler, though i understand the need to make something for mainstream appeal (agent cli tools + npx execution) It would be really nice if the cli was a layer on top of a git ops enabled declarative layer that was usable directly. (The terraform provider does not count...)
Finally. Jumping between wrangler, the dashboard, and raw API calls has been annoying for a while. I'm keen on the local explorer most, debugging Workers locally has always been clunky. Anyone know how this plays with Terraform-managed infra?
Tell us your hopes and dreams for a Cloudflare-wide CLI
This is only partly about the CLI and mostly about the API itself, but a straightforward and consistent way to manage environments would be nice.
I have a project using CF workers and Astro, with an ugly but working wrangler.toml defining multiple environments. When Cloudflare acquired Astro, I assumed that would be a good thing, but the latest version of the Cloudflare plugin (mandatory if you want to use the latest Astro) seems to manage environments in its own special incompatible way.
Wrangler currently has two auth modes: OAuth, full user permissions and static tokens that are manually created in the dashboard. Neither is designed for the pattern where a human operator and one or more AI agents need different permission boundaries.
I'd like the ability to create scoped, short-lived tokens from the CLI itself. There's an open GitHub issue (13042) for this.
But, there needs to be a twist: Tokens should be sociable not just by resource type, but by specific resource ID and action.
Build using ecosystem with a better standard library. Too little in node so you have to install lots of deps. I have to encapsulate your tool in docker to prevent node supply chain attack. If you use a better ecosystem with larger standard library you will be installing fewer rando deps. You can do it. You are very AI forward organization. Fewer dependencies and write all code yourself. You have LLM.
Node, Python etc. allow arbitrary footgun tech to lose all local data. You have to use better tech.
The consistency enforcement at the schema layer is the part I'd want to steal. Enforcing get vs info, standardizing --json across commands, these sound obvious but they're the things that break agent pipelines silently.
One thing I'm curious about: Cloudflare uses TypeScript for Workers and now this CLI, but Rust for the actual edge runtime. Is there a rough heuristic the team uses internally for when TS wins vs when you reach for something else?
Please have an endpoint for up-to-minute billing with hooks for notifications and setting limits, importantly have it correlate-with/be the endpoint that shows usage analytics.
Previous-co could never get argo billing to match argo analytics, and with no support from CF over months we backed away from CF completely in fear that scale-up would present new surprise unknown/untraceable costs
Previous-previous-co is probably the largest user of web worker
API tokens are complete mess on CF. There are 2 or 3 types of them. Agents constantly confuse, which one does what. Documentation is not referring to them correctly. I still don't understand the difference myself and can't explain clearly to an agent. Why we need to bother at all?
I'm happy that there will be more tooling, but the reason for that (and the target audience) should not be ai agents. It should be a good experience for humans!
Tools should be tested and quality assured. Something that was utterly missing for cloudflare's unusable v5 terraform provider.
Quality over quantity with a ux that has humans in mind!
Fantastic. I recently automated a bunch of operations across ~50 domains with an agent, an API key, and a bunch of HTTP requests. I kept thinking that surely cloudflare had to be working on better ergonomics for this -- glad to see they were :D
108 comments
> Tell us your hopes and dreams for a Cloudflare-wide CLI
It'd be great if the Wrangler CLI could display the required API token permissions upfront during local dev, so you know exactly what to provision before deploying. Even better if there were something like a
cf permissions checkcommand that tells you what's missing or unneeded perms with an API key.Currently you can only enforce zone-based permissions (domain based) BUT plenty of resources, such as workers, don’t belong to zones so essentially their code can be replaced or deleted with the lowest level permission. And there’s no way to block it…
Alternatively if you could please allow us to create multiple accounts that share a single super account (for SSO and such), similar to GitHub Enterprise which has Enterprises and Organisations. Then we could have ACME Corp. and ACME Corp (Prod) and segregate the two and resource groups wouldn’t be strictly required.
The cf permissions check idea from the top comment is great. One thing I've found is that agents are surprisingly good at using CLIs but terrible at diagnosing why a command failed. Clear error messages with the exact fix ("missing scope X, run cf token add --scope X") matter way more for agent usability than the happy path.
> You can try the technical preview today by running npx cf. Or you can install it globally by running npm install -g cf.
A couple of obvious questions - Is it open source (npmjs side doesn't point to repo)? And in general will it be available as a single binary instead of requiring nodejs tooling to install/use? If so, using recently-acquired Bun or another product/approach?
> Tell us your hopes and dreams for a Cloudflare-wide CLI
No long lived tokens, or at least a very straightforward configuration to avoid them.
One option: an easy tool to make narrowly scoped, very short lived tokens, in a file, and maybe even a way to live-update the file (so you can bind mount it).
Another option: a proxy mode that can narrow the scope. So I set it up on a host, then if I want to give a container access to one domain or one bucket or whatever, I ask the host CLI to become a proxy that gives the relevant subset of its permissions to the proxied client, and I connect the container to it.
No, the customers never mattered but the mythical "LLM agent" is vitally important to cater too.
> So we introduced a new TypeScript schema that can define the full scope of APIs, CLI commands and arguments, and context needed to generate any interface. The schema format is “just” a set of TypeScript types with conventions, linting, and guardrails to ensure consistency.
I'm confused though, why isn't that tool/framework being shown here. What is it and how does it work? It is similar to the TypeSpec tool someone else posted?
> Tell us your hopes and dreams for a Cloudflare-wide CLI
Initial impression:
-h and --help should follow the short / long standard of providing more / less info. The approach currently used is -h and --help show command lists and point at a --help-full flag. The --help-full output seems to give what I'd expect on -h. This needs to be much better - it should give enough information that a user / coding agen doesn't have to read websites / docs to understand how the feature works.
Completions are broken by default compared to the actual list of commands - i.e. dns didn't show up in the list.
When I ran cf start -h it prompted to install completions (this was odd because completions were already installed / detected). But either way, -h should never do anything interactive
Some parts of the cli seem very different to the others (e.g. cf domains -h is very different to cf dns -h). Color / lack of color, options, etc.
I wish we would stop building CLIs and instead use something like this:
https://executor.sh/
https://github.com/RhysSullivan/executor
https://github.com/danielgtaylor/huma https://github.com/go-fuego/fuego
The restish tool by the author of Huma is functionally correct, but I'm finding the models are not doing a great job at inferring the syntax. Admittedly I am having a hard time following the syntax too.
https://github.com/rest-sh/restish
I need to do proper evals, but it makes me wonder if
curlor a CLI with more standard args / opts parsing will work better.Thanks to Cloudflare for sharing their notes, anyone else figure this out?
> Tell us your hopes and dreams for a Cloudflare-wide CLI
Please call it flare.
A very welcome development - much better for machines to the APIs - but it always would have been welcome without AI.
I have few domains on Cloudflare and when making some changes, I wish there were a way to apply the same changes to multiple domains for consistency.
CLI preview for UI action will make it possible.
This is only partly about the CLI and mostly about the API itself, but a straightforward and consistent way to manage environments would be nice.
I have a project using CF workers and Astro, with an ugly but working wrangler.toml defining multiple environments. When Cloudflare acquired Astro, I assumed that would be a good thing, but the latest version of the Cloudflare plugin (mandatory if you want to use the latest Astro) seems to manage environments in its own special incompatible way.
I'd like the ability to create scoped, short-lived tokens from the CLI itself. There's an open GitHub issue (13042) for this.
But, there needs to be a twist: Tokens should be sociable not just by resource type, but by specific resource ID and action.
Node, Python etc. allow arbitrary footgun tech to lose all local data. You have to use better tech.
One thing I'm curious about: Cloudflare uses TypeScript for Workers and now this CLI, but Rust for the actual edge runtime. Is there a rough heuristic the team uses internally for when TS wins vs when you reach for something else?
Previous-co could never get argo billing to match argo analytics, and with no support from CF over months we backed away from CF completely in fear that scale-up would present new surprise unknown/untraceable costs
Previous-previous-co is probably the largest user of web worker
it was magical
Tools should be tested and quality assured. Something that was utterly missing for cloudflare's unusable v5 terraform provider. Quality over quantity with a ux that has humans in mind!