# Make datumctl your own with plugins > An extensibility model that balances convenience with trust. 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 prod ``` That'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 dns NAME INDEX VERSION TRUST DESCRIPTION dns datum v1.2.3 official Manage Datum Cloud DNS zones $ datumctl plugin install dns $ datumctl dns zones list ``` Here’s how the it works: - ```datumctl plugin search``` looks across catalogs of available plugins - ```datumctl plugin browse``` opens an interactive marketplace right in your terminal - ```datumctl plugin install``` pulls it down, verifies it, and wires it up - ```datumctl plugin list``` shows 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 deploy NAME INDEX VERSION TRUST DESCRIPTION deploy acme v2.1.0 third-party ACME guided deploy workflow $ datumctl plugin install acme/deploy $ datumctl deploy ``` At 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.