A Kubernetes desktop client that keeps up with your cluster.

Sternpost talks to the API server directly, subscribes instead of polling, and stays light no matter how big the cluster is.

Request beta accessFree · macOS, Windows, Linux

Reads your existing kubeconfig; nothing to set up.

A Pods table across three namespaces, with CPU and memory usage bars under each number.
The resource list: Pods across three namespaces, with the usage bars visible.

Live, not refreshed.

Every list is a Kubernetes watch. A pod restarts, the row changes. No refresh button, no polling interval, no "last updated 30s ago".

No kubectl required.

Logs, exec, port-forward and rollouts speak the API server's own protocols. Your kubeconfig is enough — tokens, client certificates and exec plugins all work.

Light on purpose.

It watches the fourteen kinds you search for, not the whole cluster. Custom resources load when you open them. Memory stays flat on a big cluster.

Better than the one you're using.

Four things the desktop client on your machine right now gets wrong.

Port forwards that survive a rollout.

Most clients pick a pod when the forward starts and die with it. Sternpost picks a Ready pod per connection: a rollout, a crash or a scale-down costs you only the connections that were open. The rules are still there after you restart.

How it works

A Deployment's logs, not one pod's.

Every pod behind a workload, merged, each line tagged with where it came from. Mute a pod and the lines already on screen filter too. Drag the window to the other monitor.

How it works

Watches, not a refresh interval.

Every list is a Kubernetes watch. Nothing polls, nothing says "updated 30s ago", and a dropped watch reconnects and tells you.

How it works

Flat memory on a big cluster.

It watches the fourteen kinds you search for, not everything. Custom resources load when you open them. A cluster with 20k pods doesn't cost 2GB.

How it works

And the rest of the day.

Everything it does →

Credentials never leave your kubeconfig — Sternpost stores a path and a context name. Secret values are redacted on screen. Every write is confirmed first and tagged fieldManager=sternpost so you can see it in managedFields.

Try it on a real cluster.