Another vendor decided the CLI was holding their users back. They're wrong.

A DevOps tooling vendor announced this week that their CLI is entering maintenance-only mode — no new features, security patches only, EOL in eighteen months — with “continued investment” going into their cloud dashboard instead. The announcement called it a “streamlined experience for modern developer workflows.”

This is the third time I’ve read a sentence like that this quarter. The word “streamlined” in a deprecation notice is doing the same work the word “simplify” does in a pricing change: it means something got worse for you and better for them, wrapped in language that makes complaining about it sound like a you problem.

What you actually lose when the CLI goes

A dashboard is not a replacement for a CLI. They are not the same thing with different interfaces. They have different capabilities and different failure modes and only one of them can be invoked from inside a Makefile at 0300 during an incident.

When the CLI goes, you lose:

• Scriptability. The one-liner that checks your deployment status and pages you if it’s wrong can be written against a CLI. It cannot be written against a browser tab. “They have an API” is not an answer unless they also have an API with the same scope, the same auth model, and the same flag semantics — which they frequently don’t, because the API is what the dashboard calls and it’s not designed for your use case.
• Composability. tool status | grep FAILED | awk '{print $2}' | xargs tool rollback is a real pipeline that does a real thing. You cannot pipe a dashboard to awk.
• Offline and air-gapped operation. Cloud dashboard requires the cloud. CLI can be documented, cached, and run from a machine that can’t reach the vendor’s SaaS. Every enterprise with compliance requirements that ever bought this tool is about to discover this the hard way.
• Reproducibility in CI. You can install a CLI in a container. You cannot install a browser in a container in a way that runs unattended against a web UI without shelling out to Playwright and writing a full integration test suite against their frontend, which: no.

The one thing I’ll actually grant them

The new dashboard, from the screenshots, has legitimately better search. The CLI’s help text was impenetrable and the flags were inconsistent — I’ve seen config files that used --timeout and --timeoutSeconds in the same version, both valid, both doing slightly different things. That’s real. Fixing discoverability in a UI costs less than fixing it in a decade of accumulated flag debt.

But that’s a documentation problem and a flag-consistency problem. Solving those by killing the automation interface is treating the symptom in the most user-hostile way possible.

What to do before the EOL clock runs out

Eighteen months sounds long. It isn’t. The typical sequence: the cloud dashboard ships without feature parity for six months (“coming soon”), parity arrives roughly twelve months in, and then the last six months is a rush of teams realizing their scripts are broken because they never tested against the new API surface. By the time EOL hits, you’re patching infrastructure at speed.

Start now:

1. Inventory every place you call this CLI — Makefiles, CI configs, cron jobs, runbooks, that one script Dave wrote and only Dave understands. You need the full blast radius.
2. Wrap the CLI calls in thin shell functions today. If you call tool deploy --env prod in twenty places, wrap it in rodhat_deploy_prod() and call that instead. Now you have one migration point.
3. Evaluate the API surface. If the vendor’s REST API covers your use case and has sane auth (service accounts, token scopes, not “log in through the SSO portal”), write the wrapper against the API now, while the CLI is still there to verify behavior against.
4. File the vendor evaluation. A CLI EOL is the right trigger to ask whether this vendor is the right vendor. Switching costs are real but so is eighteen more months of building on something they’re actively deprioritizing.

The CLI wasn’t holding your users back. It was the part of the product that treated them as engineers instead of as people who need things simplified.

If step 4 lands on “actually let’s just leave,” the usual suspects — DigitalOcean and Linode — both still ship a CLI they haven’t deprecated out of a board meeting, which at this point counts as a competitive advantage.