datumctl v0.16.0 — Bring your own plugin catalog

[scotwells]

The plugin system just got its ecosystem. Since v0.15.0, datumctl could install plugins from a single, Datum-operated catalog. With v0.16.0, anyone — a community author, an open-source project, or an enterprise platform team — can publish their own plugin catalog, and you can register, search, browse, and install across all of them with the same commands you already know. The curated datum catalog remains the trusted, zero-configuration default, so nothing changes if you never add another one.

This release also arrives alongside new and much-improved documentation for datumctl at datum.net/docs/datumctl — linked throughout below, and worth a bookmark.

---

New: register third-party catalogs with datumctl plugin index (#224)

Plugins can now come from more than one place. Adding a catalog is a single command, and the source can be an HTTPS URL, a GitHub repository, or a local path:

datumctl plugin index add acme https://plugins.acme.example/index.yaml
datumctl plugin index list

Adding a catalog is an explicit, one-time trust decision: datumctl tells you up front that Datum does not review plugins from third-party catalogs, and asks you to confirm before the catalog is registered (pass --yes in scripts). index update refreshes a catalog and index remove unregisters it.

📖 Adding catalogs covers the full command suite and the trust model.

Search, browse, and install across every catalog (#224)

datumctl plugin search and datumctl plugin install now span every registered catalog at once, and every result carries a clear official vs. third-party badge — provenance is never ambiguous. Prefer to explore? datumctl plugin browse opens an interactive marketplace view across all of your catalogs.

You can also pin the exact release you want with the @version syntax:

datumctl plugin install dns
datumctl plugin install compute@v0.8.0-dev.7

📖 Using plugins walks through search, browse, install, upgrade, version pinning, and how plugin trust and checksum verification protect you.

Your plugins, right on the landing screen (#224)

Running datumctl with no arguments now shows the plugins you've installed as runnable commands, each badged with the catalog it came from, along with a pointer to datumctl plugin browse for discovering more.

For platform teams: managed catalogs and publisher allow-lists (#224)

Private internal catalogs are first-class. Two environment variables give platform teams governance over where plugins can come from:

• DATUMCTL_PLUGIN_MANAGED_CONFIG — pre-seed approved catalogs for your organization from a YAML file.
• DATUMCTL_PLUGIN_ALLOWED_INDEXES — restrict which catalog sources users can register, scoped down to individual GitHub owners or repositories (github.com/acme-corp, github.com/acme-corp/plugins) or non-GitHub hosts (plugins.acme.example).

The allow-list is enforced continuously, not just when a catalog is added: if a catalog's source falls out of policy, it is disabled with a clear warning and excluded from search, browse, and install — though it stays visible in index list and can still be removed. Catalog authors can also check their work before publishing with datumctl plugin index validate <path | url>.

Important

If you already use DATUMCTL_PLUGIN_ALLOWED_INDEXES, two entry forms change meaning in this release. A raw.githubusercontent.com host entry no longer blanket-authorizes every GitHub repository — scope GitHub sources explicitly with github.com/<owner> or github.com/<owner>/<repo> instead. And a bare catalog-name entry now authorizes local sources only; remote catalogs must match a host or GitHub pattern. Catalogs that no longer match your policy are disabled the next time datumctl loads them.

📖 Publishing catalogs covers hosting your own catalog, and the enterprise controls are documented in Adding catalogs.

Note

Third-party plugins run on your machine with your Datum credentials, so this release got a careful security pass: HTTPS-only downloads with verification at every redirect, SHA256 checksum verification on every run, an install-time manifest probe that runs with a scrubbed environment, and explicit trust gates for anything Datum doesn't curate. The datum catalog remains the trusted, zero-setup default.

---

New documentation for datumctl 📚

The datumctl docs have been rebuilt from the ground up at datum.net/docs/datumctl. Whether you're brand new or automating datumctl in CI, there's now a dedicated guide:

• Quickstart — from install to your first resource in a few minutes.
• Logging in and managing accounts & tokens — including service accounts for automation.
• Working with resources — reading, changing, and making safe, declarative changes with server-side dry runs and datumctl diff.
• Contexts & scoping — switching between organizations and projects.
• Plugins — everything above, plus building your own plugin.
• Activity & audit — querying audit logs, events, and change history.
• AI assistant and the MCP server — connect datumctl to your AI tools.
• CI/CD — including GitHub Actions, plus output formats & scripting for building on datumctl.
• For kubectl users: using datumctl with kubectl and GitOps with Flux & Argo CD.

---

Full changelog: datum-cloud/datumctl@v0.15.2...v0.16.0