> 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.
contrahax 52 minutes ago [-]
A doctor command that does this is always nice! Wish more services would have this
dcre 3 hours ago [-]
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.
thegagne 3 hours ago [-]
Love TypeSpec, agree it makes writing OpenAPI really easy.
But I’ve moved to using https://aep.dev style APIs as much as possible (sometimes written with TypeSpec), because the consistency allows you to use prebaked aepcli or very easily write your own since everything behaves like know “resources” with a consistent pattern.
Also Terraform works out of the box, with no needing to write a provider.
esafak 1 hours ago [-]
Which parts of Openapi does it fix?
ks2048 16 minutes ago [-]
Kind of ironic that AI and Agents seems to be leading to more CLI/API stuff, when AI actually allows human-like computer use for the first time.
A very welcome development - much better for machines to the APIs - but it always would have been welcome without AI.
porphyra 2 hours ago [-]
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.
deadbabe 38 minutes ago [-]
Why bother with OpenClaw? Just call the CLI command directly. That is the point of a CLI.
shimman 11 minutes ago [-]
Yeah but you can waste $10-50 having an LLM do that for you instead rather than using your engineering experience to do it. Think of the shareholder value!
kodablah 3 hours ago [-]
> 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?
bakugo 3 hours ago [-]
I can't find any repository, either, but the package is listed as MIT-licensed and includes source maps, so I assume it will be published soon.
amingilani 1 hours ago [-]
> 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?
nzoschke 2 hours ago [-]
I have been experimenting with Open API spect -> CLI too. I have Go and specs auto-generated either with Huma or 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.
I need to do proper evals, but it makes me wonder if `curl` or a CLI with more standard args / opts parsing will work better.
Thanks to Cloudflare for sharing their notes, anyone else figure this out?
ks2048 9 minutes ago [-]
> TypeScript is "the lingua franca of software engineering."
Seems odd to me. I guess we all live in our bubbles.
If there is some fancy tool out there, "does it have binding for language X"? X seems to be much more commonly Python than Typescript.
cordwainersmith 3 hours ago [-]
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?
f-serif 2 hours ago [-]
I wish there were CLI preview command when making changes in Cloudflare.
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.
acedTrex 2 hours ago [-]
Its so depressing that it took widespread LLM psychosis to finally get company leadership to invest in actual CLI tooling.
No, the customers never mattered but the mythical "LLM agent" is vitally important to cater too.
bensmoif 3 hours ago [-]
Oh yes to this! I spent yesterday morning working this out when it smacked me in the face
queuep 3 hours ago [-]
I’ve used a lot of cloudflare functionality with Claude and their API. Worked very good
anju-kushwaha 33 minutes ago [-]
waiting this feature from long time
kodama-lens 3 hours ago [-]
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!
marcusestes 3 hours ago [-]
Making a good experience for AI agents also makes a good experience for the humans that are tasked with the management of their agents.
climike 3 hours ago [-]
Exactly! Number of turns, average tokens to achieve a task using your CLI, as well as average number of characters being returned per CLI command alongside other metrics: all important to both users and agents! I am working on allowing to accurately capture this at www.cliwatch.com! Feel free to request an example eval suite for a list of tasks you want to achieve with your CLI
2 hours ago [-]
5701652400 43 minutes ago [-]
> First Principles
am I the only one put off with such language? they talk as if they invented compilers or assembly or Newton's law of gravity.
risyachka 3 hours ago [-]
> Tell us your hopes and dreams for a Cloudflare-wide CLI
Please call it flare.
jamesog 48 minutes ago [-]
I was the original author of the cloudflare-go library (which I worked on in my spare time while working at Cloudflare), and I included a `flarectl` command with it, but sadly it didn't get much traction :-(
This, but for Bunny DNS, so I can get closer to 100% European clouds. :)
j45 2 hours ago [-]
Complete CLI coverage is so great to see.
latchkey 3 hours ago [-]
I just wish they'd fix billing notifications. The ux makes it impossible to set it up. Been complaining about that on X, got a couple people saying they would look into it, even one that gave me his email address. Pure silence.
benatkin 3 hours ago [-]
> Right now, cf provides commands for just a small subset of Cloudflare products.
Why didn't they vibe code support for more? With this on the heels of EmDash, and this being a technical preview, it feels inconsistent.
> We write a lot of TypeScript at Cloudflare. It’s the lingua franca of software engineering.
This scares me more than Im able to admit, typescript sucks and in my opinion its way worse than the more commonly used lingua franca of computing, which I would attribute to C. At least C can be used to create shared objects i guess?
dewey 3 hours ago [-]
“Typescript sucks” is not really a great reason.
tombert 3 hours ago [-]
Personally I haven't felt like Typescript has bought me enough over JavaScript to use it in contexts that I don't have to. I have to use TypeScript for work, and it's "fine", but I guess I haven't found that it helps all that much.
I'm not sure why; I guess it's because the web itself is already really flexible that I find that the types don't really buy me a lot since I have to encode that dynamism into it.
To be clear, before I get a lecture on type safety and how wonderful you think types are and how they should be in everything: I know. I like types in most languages. I didn't finish but I was doing a PhD in formal methods, and specifically in techniques to apply type safety to temporal logic. I assure you that I have heard all your reasoning for types before.
xnacly 3 hours ago [-]
Well it does suck for a huge list of reasons but specifically disqualifying for being the lingua franca would be it being controlled by microsoft
seabrookmx 2 hours ago [-]
It's open source. If Microsoft did anything weird it would be immediately forked ala. terraform, ElasticSearch etc.
There's so much momentum behind it from the front-end community alone it's not going anywhere.
IMO using Typescript sucks because of the node ecosystem/npm. The language itself is passable.
rvz 3 hours ago [-]
Well it does suck, and it isn't really great for implementing performant developer tools, such as parsers, formatters and so on.
The performance is that bad that the typescript developers are rewriting the language itself in Go. [0]
Tells me everything I need to know about how bad typescript is from a performance stand point.
That’s the lsp not runtime. Bun runs Typescript very fast. It’s a fantastic language and ecosystem.
skydhash 3 hours ago [-]
I’ve just checked FFI in bun and it’s marked as experimental. There are great libraries in C/C++ world and FFI is kinda table stakes to use them.
rvz 3 hours ago [-]
No where did I say "runtime".
Even with Bun it's because of Zig, not TypeScript and that only proves my point even more.
steve_adams_86 2 hours ago [-]
Why do you think it sucks?
I used to dislike JavaScript a lot after learning it and PHP, then using languages like C#. Then TypeScript came along making JS much easier to live with, but has actually become quite nice in some ways.
If you use deno as your default runtime, it's almost Go-like in its simplicity when you don't need much. Simple scripts, piping commands into the REPL, built-in linting, testing, etc. It's not that bad!
Of course you're welcome to your opinion and we'd likely agree about a lot of what's wrong with it, but I guess I feel a bit more optimistic about TS lately. The runtime is improving, they've got great plans for it, it's actually happening, and LLMs aren't bad at using it either. It's a decent default for me.
PUSH_AX 2 hours ago [-]
Not OP, I use TS but only because it’s the only option. TS is a build your own typing sandbox, more than enough rope to hang yourself.
Coming from typing systems that are opinionated, first class citizens of their languages, it doesn’t stand up.
steve_adams_86 2 hours ago [-]
This is one of my dislikes as well.
You look at libraries like Effect, and it's genuinely incredible work, but you can't help feeling like... Man, so many languages partially address these problems with first-class primitives and control flow tooling.
I'm grateful for their work and it's an awesome project, but it's a clear reflection of the deficiencies in the language and runtime.
newspaper1 2 hours ago [-]
I think it sucks because it transpiles to JavaScript and is an interpreted language. Users have to resolve the dependencies themselves and have the correct runtime. I definitely prefer my CLI tools be written in a compiled language with a single binary.
steve_adams_86 2 hours ago [-]
I agree, though one cool thing arriving lately (albeit with some major shortcomings) is the ability to compile binaries with deno or bun (and nodejs experimentally, I think).
With Go you can compile binaries with bindings for other binaries, like duckdb or sqlite or so on. With deno or bun, you're out of luck. It's such a drag. Regardless, it's been quite useful at my work to be able to send CLI utilities around and know they'll 'just work'. I maintain a few for scientific data processing and gardening (parsing, analysis, cleaning, etc) which is why the lack of duckdb bundling is such a thorn. I do wish I could use Go instead and pack everything directly into the binary.
Rendered at 19:36:45 GMT+0000 (Coordinated Universal Time) with Vercel.
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.
But I’ve moved to using https://aep.dev style APIs as much as possible (sometimes written with TypeSpec), because the consistency allows you to use prebaked aepcli or very easily write your own since everything behaves like know “resources” with a consistent pattern.
Also Terraform works out of the box, with no needing to write a provider.
A very welcome development - much better for machines to the APIs - but it always would have been welcome without AI.
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'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?
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 `curl` or a CLI with more standard args / opts parsing will work better.
Thanks to Cloudflare for sharing their notes, anyone else figure this out?
Seems odd to me. I guess we all live in our bubbles.
If there is some fancy tool out there, "does it have binding for language X"? X seems to be much more commonly Python than Typescript.
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.
No, the customers never mattered but the mythical "LLM agent" is vitally important to cater too.
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!
am I the only one put off with such language? they talk as if they invented compilers or assembly or Newton's law of gravity.
Please call it flare.
https://github.com/cloudflare/cloudflare-go/tree/v0/cmd/flar...
Why didn't they vibe code support for more? With this on the heels of EmDash, and this being a technical preview, it feels inconsistent.
(Disclaimer: I work for Speakeasy)
This scares me more than Im able to admit, typescript sucks and in my opinion its way worse than the more commonly used lingua franca of computing, which I would attribute to C. At least C can be used to create shared objects i guess?
I'm not sure why; I guess it's because the web itself is already really flexible that I find that the types don't really buy me a lot since I have to encode that dynamism into it.
To be clear, before I get a lecture on type safety and how wonderful you think types are and how they should be in everything: I know. I like types in most languages. I didn't finish but I was doing a PhD in formal methods, and specifically in techniques to apply type safety to temporal logic. I assure you that I have heard all your reasoning for types before.
There's so much momentum behind it from the front-end community alone it's not going anywhere.
IMO using Typescript sucks because of the node ecosystem/npm. The language itself is passable.
The performance is that bad that the typescript developers are rewriting the language itself in Go. [0]
Tells me everything I need to know about how bad typescript is from a performance stand point.
[0] https://devblogs.microsoft.com/typescript/typescript-native-...
Even with Bun it's because of Zig, not TypeScript and that only proves my point even more.
I used to dislike JavaScript a lot after learning it and PHP, then using languages like C#. Then TypeScript came along making JS much easier to live with, but has actually become quite nice in some ways.
If you use deno as your default runtime, it's almost Go-like in its simplicity when you don't need much. Simple scripts, piping commands into the REPL, built-in linting, testing, etc. It's not that bad!
Of course you're welcome to your opinion and we'd likely agree about a lot of what's wrong with it, but I guess I feel a bit more optimistic about TS lately. The runtime is improving, they've got great plans for it, it's actually happening, and LLMs aren't bad at using it either. It's a decent default for me.
Coming from typing systems that are opinionated, first class citizens of their languages, it doesn’t stand up.
You look at libraries like Effect, and it's genuinely incredible work, but you can't help feeling like... Man, so many languages partially address these problems with first-class primitives and control flow tooling.
I'm grateful for their work and it's an awesome project, but it's a clear reflection of the deficiencies in the language and runtime.
With Go you can compile binaries with bindings for other binaries, like duckdb or sqlite or so on. With deno or bun, you're out of luck. It's such a drag. Regardless, it's been quite useful at my work to be able to send CLI utilities around and know they'll 'just work'. I maintain a few for scientific data processing and gardening (parsing, analysis, cleaning, etc) which is why the lack of duckdb bundling is such a thorn. I do wish I could use Go instead and pack everything directly into the binary.