Console
The console and the CLI are peers. Anything you can do to an app from a terminal you can do from a browser: create it, deploy it, scale it, read its logs, roll it back, promote it. Neither is the real interface with the other bolted on.
They drive the same API, so a team can mix them freely — someone deploys from CI, someone else scales a component from a phone during an incident, and the deploy history records both the same way.
Not supported by the current release. The app-layer commands named on this page —
kubenest deploys, kubenest logs and kubenest status — were removed from the command tree and
are frozen scope under decision D1. The released CLI installs and operates the platform only, so
this callout comes off only when a release that lifts that decision is promoted.
What it is better at
Looking at more than one thing. The fleet view is every cluster at once: bundle version, HA tier, health verdict, when its last restore drill passed. A terminal shows you one cluster well; a screen shows you forty and which two need attention.
History with shape. Deploys, upgrades, drill results and access changes over time, with who did
what. kubenest deploys prints a list; the console shows the same list next to the health graph it
moved.
People without a terminal. The person who needs to pause an app, approve a maintenance window, or check whether last night’s backup drill passed is not always the person with the CLI installed and a token in their shell.
What the CLI is better at
Anything that belongs in a repository. kubenest.yaml is reviewable in a pull request and
revertable with a commit. A form is neither.
Anything a machine does. CI deploys, scheduled jobs, scripts, --output json piped into
something else.
Working on one thing, quickly. kubenest logs api -f is faster than finding the app, the
component and the tab.
The fleet view
Every cluster the control plane knows about, worst first:
| Cluster | Name, bundle version, HA tier, node count |
| Health | The verdict, and the check that produced it |
| Backup | Target configured, last backup, last drill and whether it passed |
| Version | Which bundle, whether a newer one is available, and the diff to it |
| Access | Who can reach this cluster, and at what role |
A check the agent could not collect shows as unknown, ordered above ok and rendered distinctly.
Forty green and two grey is the truth; forty-two green is the failure the whole health system exists
to prevent.
Day-2 operations
The day-2 work has a home here rather than only in a terminal:
- Upgrades — see what a bundle would change, run the pre-flight gates and watch the stages
- Restore drills — the result of every drill, what it verified, and the alert when one fails
- Maintenance and reboot windows — set per cluster, in your timezone
- Backup targets — configure, and see immediately that a cluster has none
Apps
Everything in Deploying apps, through a screen: create an app, edit its components, wire an addon export into a workload, set a secret, scale, pause, read logs, roll back to a numbered deploy, and promote a deploy from staging to production with the diff in front of you.
An app created in the console is the same object as one deployed from a file. There is no
console-managed and CLI-managed distinction to trip over — kubenest status sees an app someone
created in a browser, and the console shows an app deployed from CI. You can export any app to a
kubenest.yaml and start committing it whenever you decide you want to.
Next: Deploying apps · Day 2