[HN Gopher] Building a CLI for All of Cloudflare
___________________________________________________________________
Building a CLI for All of Cloudflare
Author : soheilpro
Score : 228 points
Date : 2026-04-13 15:44 UTC (7 hours ago)
(HTM) web link (blog.cloudflare.com)
(TXT) w3m dump (blog.cloudflare.com)
| xnacly wrote:
| > 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 wrote:
| "Typescript sucks" is not really a great reason.
| xnacly wrote:
| 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 wrote:
| 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 wrote:
| 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.
|
| [0] https://devblogs.microsoft.com/typescript/typescript-
| native-...
| braebo wrote:
| That's the lsp not runtime. Bun runs Typescript very fast.
| It's a fantastic language and ecosystem.
| skydhash wrote:
| 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 wrote:
| No where did I say "runtime".
|
| Even with Bun it's because of Zig, not TypeScript and
| that only proves my point _even_ more.
| r_lee wrote:
| you're right. we should just not use any
| interpreted/script languages because they're not as fast
| as compiled ones.
|
| why does a CLI tool that just wraps APIs need this native
| performance?
| wiseowise wrote:
| The performance is so bad that the most used software in
| the world is written using it.
| tombert wrote:
| 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.
| steve_adams_86 wrote:
| 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.
| newspaper1 wrote:
| 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 wrote:
| 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.
| r_lee wrote:
| you can already "compile" TS binaries with deno, but
| it'll include the runtime in it and etc. so it'll take
| some disk space but I think these days it's less of a
| concern than before
| PUSH_AX wrote:
| 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 wrote:
| 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.
| 8cvor6j844qw_d6 wrote:
| > 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 wrote:
| A doctor command that does this is always nice! Wish more
| services would have this
| jbethune wrote:
| I would second this. Would be very helpful. Had a fat finger
| issue a while ago that this would have saved.
| LaurensBER wrote:
| That would be glorious! If ChatGPT doesn't get the permissions
| right on the first try I know that I'm going to have to spend
| the next hours reading the documentation or trying random
| combinations to get a token that works.
| kodablah wrote:
| > 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 wrote:
| 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.
| kodama-lens wrote:
| 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 wrote:
| 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 wrote:
| 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
| dhess wrote:
| Agreed that the current Terraform provider is shockingly bad.
| It's changed my estimation of Cloudflare's technical
| competence, drastically. The automated migration from v4 still
| doesn't work and it's been, what, nearly a year since v5 was
| released? (This is not to mention I've never used a Terraform
| provider that made me run external migration tools in the first
| place.)
| bensmoif wrote:
| Oh yes to this! I spent yesterday morning working this out when
| it smacked me in the face
| queuep wrote:
| I've used a lot of cloudflare functionality with Claude and
| their API. Worked very good
| latchkey wrote:
| 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 wrote:
| > 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.
| risyachka wrote:
| > Tell us your hopes and dreams for a Cloudflare-wide CLI
|
| Please call it flare.
| jamesog wrote:
| 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 :-(
|
| https://github.com/cloudflare/cloudflare-go/tree/v0/cmd/flar...
| dcre wrote:
| 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 wrote:
| 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 wrote:
| Which parts of Openapi does it fix?
| cordwainersmith wrote:
| 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?
| porphyra wrote:
| 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 wrote:
| Why bother with OpenClaw? Just call the CLI command directly.
| That is the point of a CLI.
| shimman wrote:
| 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!
| tills13 wrote:
| I think the point is that I don't have to remember the
| command. I just have to tell my agent in plain-English to do
| X.
|
| For example, we're dragging our feet on Github Config as
| Terraform at our org so in the meantime I've been using
| Claude + the gh cli to deploy changes across repos. I don't
| need to know / remember the gh cli command to pull or push a
| ruleset, or script a loop in Bash, I just have to say
|
| > Claude pull the ruleset from <known good repo> and push it
| to <repo 1>, <repo 2>, <repo 3>
|
| The CLI is also nice because it abstracts away
| authentication. I have another flow which doesn't have a CLI
| and Claude is more than happy to interpolate the API key that
| it read from a config file into the chat history
| (horrifying).
| porphyra wrote:
| Exactly. Talking in plain English is a lot less mental
| overhead than reading the man page and figuring out the
| right command. Nowadays I just use AI instead of
| remembering ffmpeg commands too. Your point about
| authentication is important too.
| j45 wrote:
| Complete CLI coverage is so great to see.
| acedTrex wrote:
| 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.
| f-serif wrote:
| 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.
| jeffrallen wrote:
| This, but for Bunny DNS, so I can get closer to 100% European
| clouds. :)
| nzoschke wrote:
| I have been experimenting with Open API spect -> CLI too. I have
| Go and specs auto-generated either with Huma or Fuego
|
| 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?
| nla wrote:
| Excellente!
| mfbx9da4 wrote:
| BTW Speakeasy support generating customizable CLIs written in Go
| from OpenAPI specs. https://www.speakeasy.com/docs/cli-
| generation/create-cli
|
| (Disclaimer: I work for Speakeasy)
| amingilani wrote:
| > 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?
| 5701652400 wrote:
| > 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.
| anju-kushwaha wrote:
| waiting this feature from long time
| ks2048 wrote:
| 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.
| ks2048 wrote:
| > 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.
| upcoming-sesame wrote:
| I recently let LLM deploy a service for me in gcp using gcloud
| cli without going to gcp dashboard even once.
|
| it was magical
| joshka wrote:
| > 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.
| organsnyder wrote:
| I've never heard of this convention. Every getopt-style CLI
| tool I've used has identical behavior whether an option is
| specified in its short- or long-form.
| maleldil wrote:
| Jujutsu does it, and it's quite nice.
| dec0dedab0de wrote:
| Please don't ever make the short version of a cli flag be
| different than the long version.
|
| The short version is for typing on the fly, and the long
| version is for scripts, they should have identical output.
|
| The full thorough documentation should be in man, and/or info.
| forsalebypwner wrote:
| 100% agree, not sure where this idea came from but I'm not a
| fan.
|
| You can just make a `--help-all` (or whatever word you want
| to use), imo the `--help-all` command doesn't need a short
| equivalent because it's not something you'd frequently use.
| FabDee wrote:
| About the cf domains -h vs cf dns -h drift you flagged, in my
| case, I've watched Claude learn one subcommand format, then
| take for granted the same flags on a sibling with a different
| help shape.
|
| It's not cosmetic. Uniform help is a way to not let agents
| hallucinate. Otherwise you end up with invalid commands, or
| worse, silent ones that go through without doing anything at
| all, or go totally wrong.
| amluto wrote:
| > 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.
| oncensher wrote:
| 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
| cleverdash wrote:
| 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.
| jFriedensreich wrote:
| 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...)
| K0IN wrote:
| i love the idea but sad to see that we needed ai to give
| companies incentives to build better dx.
| colesantiago wrote:
| Building CLIs don't make any sense and in fact it is the wrong
| way.
|
| I wish we would stop building CLIs and instead use something like
| this:
|
| https://executor.sh/
|
| https://github.com/RhysSullivan/executor
| hybirdss wrote:
| -h vs --help is one of those small things that gets very loud
| when it's broken
| iainmerrick wrote:
| _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.
___________________________________________________________________
(page generated 2026-04-13 23:00 UTC)