We’ve built enough CLI’s over the years to understand that no single tool covers every workflow. datumctl is no exception, and in recent weeks I found myself reaching past the current state of our CLI while building new features for Datum Compute.
Happily, extensibility is one of the quiet superpowers of the terminal. It’s a tool you can extend. Why file a feature request and wait for weeks (or even years) to get a response when you could add the missing piece on your own by lunchtime? When a tool lets you do that, it stops being someone else's software and starts being your own personal workflow.
When we built datumctl , we set out to serve command-line power users, visual navigators, and AI builders alike. While different in many ways, these users all want to bend a tool to their job, not the other way around. So instead of piling on commands (get, apply, diff, etc) and hoping one of them fits every possible user and team, we decided to get out of the way and let users extend datumctl to match their needs.
And that’s why datumctl now supports plugins!
Like any good extension model, the core idea is pretty boring: drop an executable named datumctl-backup somewhere on your PATH , and datumctl backup just works. Your plugin runs as if it had always been part of the CLI:
$ mv ./bin/backup /usr/local/bin/datumctl-backup$ datumctl backup --project prodThat's it!
Leaning into patterns
If you've written a git subcommand or a kubectl plugin, this will feel very familiar, which of course is the whole point. There's no plugin API to learn and no framework to adopt. A plugin is literally just a program with the right name, which means the wrapper script you have sitting around is most of the way there.
What makes a datumctl plugin more than just a renamed script is that it inherits your context.
Before a plugin runs, datumctl hands it the context about where you’re working (organization and project) along with the API host and a path back to datumctl so it can fetch credentials on demand. This means your plugin doesn't have to reimplement login or juggle tokens. Instead, it asks datumctl for a token when it needs one and gets to work.
Write it in Go and our small SDK gives you the context, a token, and a pre-wired command scaffold in a few lines (or write it in anything else…the contract is just a handful of environment variables and a subprocess call).
If writing a plugin is the first half of the story, then discovering that it already exists is the other half. A plugin nobody can discover isn't much of an ecosystem, so we gave plugins a front door:
$ datumctl plugin search dnsNAME INDEX VERSION TRUST DESCRIPTIONdns datum v1.2.3 official Manage Datum Cloud DNS zones
$ datumctl plugin install dns$ datumctl dns zones listHere’s how the it works:
datumctl plugin searchlooks across catalogs of available pluginsdatumctl plugin browseopens an interactive marketplace right in your terminaldatumctl plugin installpulls it down, verifies it, and wires it updatumctl plugin listshows what you've got and whether anything is out of date
When you open datumctl with no arguments, your installed plugins are right there on the landing screen, sitting alongside the built-in commands as equals.
Collaboration from the start
While the terminal experience can be very personal, software and infrastructure are inherently distributed and collaborative. That’s why we created the concept of catalogs.
As a foundation, we created an official Datum catalog that's available by default and populated with trusted plugins. But we’ve also made it so anyone can publish their own catalog. Simply point datumctl at an HTTPS URL, a GitHub repo, or a local path, and any plugins become searchable and installable just like our official catalog. This means a platform team can stand up an internal catalog of the tooling their engineers use, and hand out a single command to get everyone on the same page:
$ datumctl plugin index add acme github.com/acme-corp/datumctl-plugins
You're adding a third-party plugin catalog: "acme"Datum does not review, verify, or endorse plugins from this catalog.Plugins run on your machine with your Datum credentials.Only add catalogs you trust.
Add this catalog? [y/N] y
$ datumctl plugin search deployNAME INDEX VERSION TRUST DESCRIPTIONdeploy acme v2.1.0 third-party ACME guided deploy workflow
$ datumctl plugin install acme/deploy$ datumctl deployAt this point the tooling from your catalog shows right alongside Datum's official tools. They’re searchable, installable, and badged so you always know which is which.
In the above example, the acme/deploy spelling is there on purpose: if two catalogs both offer a deploy, datumctl won't roll the dice and take a best guess. Instead it will ask you to name the exact one you mean to use.
A few notes on security
In addition to balancing convenience with clarity (so you know the plugin you’re using is the one you expect), we allow administrators to pre-seed approved catalogs and restrict which ones users can add. This helps organizations that need guardrails encouraging extensibility without handing out the keys to everything.
And since a plugin is a program that runs on your machine with access to your Datum credentials, we designed the process for adding third-party catalogs to be intentional and explicit. Here’s how:
- The origin of each plugin is shown wherever you might act on it
- An "official" badge means Datum, "third-party" means someone else
- Managed plugins are checksummed at install and re-verified before every run, which means a binary that changed after you trusted it simply won't execute
- Tokens are never sprinkled into a plugin's environment
- Catalog fetches are locked down against the usual tricks
None of this stuff is glamorous, but we think it is what separates a model you can trust from one you can't.
With the addition of plugins, the commands we ship with our CLI are now just a starting point. When datumctl doesn't fit the way your team works, there's now nothing between you and the piece you're missing. Build it, and if others might need it as well, publish it!
I'm looking forward to seeing what you make.