Try Kubius
⌘K

Optimisation & nodes

Right-sizing persistence (sharing across your team)

By default, every right-sizing result is saved only on your Mac. Kubius Pro adds an optional way to store results inside your own cluster so other Pro users on that cluster see the same history - useful when a team shares responsibility for a cluster.

It is off by default, opt-in at two levels, and - this is the important part - your data never leaves your cluster. Kubius stores it as a custom resource in your cluster and sends nothing to Kubius.

Turning it on

Persistence is enabled in two places, both opt-in:

  1. Per cluster - Settings ▸ Persistence, scoped to the cluster you’re connected to. The first time you enable it, Kubius installs a small custom resource definition (CRD) called RightSizingResult. This is a one-time step that needs cluster-admin:

    • If you have permission, Kubius shows you the exact YAML and installs it once you confirm.
    • If you don’t, Kubius shows the YAML and the kubectl apply command to hand a cluster admin. Until the CRD exists, your results simply stay local.

    The CRD adds no workload and runs no controller - it only stores data.

  2. Per workload - once cluster persistence is on, each workload’s right-sizing page gets a Share results to the cluster switch. Every supported workload is included by default; turn one off to keep that workload’s results on your Mac only. Enabling a workload also backfills its existing local history to the cluster.

Toggling either of these takes effect immediately - no reconnect needed.

What’s stored, and how it’s protected

Each workload gets one RightSizingResult resource holding a rolling history of runs (the newest ~20). The envelope - which workload, when, how many runs - is plain, but the CPU/memory values and recommendations are encrypted at rest, so someone simply listing the resource can’t read them. Kubius quietly skips any entry that has been tampered with or can’t be read, so a bad entry never breaks the list or gets applied.

The encryption is a deterrent against casual reading (e.g. kubectl get … -o yaml or a non-Pro user), not a guarantee against a determined cluster admin - the protection is honest-user strength.

The resource lives under the Kubius API group kubius.io - the same across dev, production and local builds, so a teammate on a different build still sees your shared results. Browse it with kubectl get rsr -A (the group is also shown in Settings ▸ Persistence).

Seeing shared results

On a workload’s right-sizing page, PREVIOUS ANALYSES merges your local history with what’s stored in the cluster, deduplicated, and badges each result:

  • Local - saved on this Mac only.
  • In cluster - stored in the cluster (perhaps by a teammate).
  • Synced - both.

A result whose workload has since been deleted still appears, read-only (you can’t apply it).

Notifications

When sharing is in use on a cluster, you get a desktop notification when a teammate records a new result - on by default, and you do not need to enable persistence yourself to receive them (that’s only required to share your own results). So if a colleague enables sharing, everyone on the team is notified of new results without any extra setup.

You’re never notified about your own runs, and there’s no flood on launch - only results that arrive while Kubius is running trigger a notification (the existing backlog is ignored). Notifications carry no personal information - only the workload; tapping one opens that workload’s right-sizing page. Turn them off any time in Settings ▸ Notifications ▸ “Shared right-sizing result”.

Removing data from the cluster

  • One result - delete it from PREVIOUS ANALYSES; for a shared (In cluster / Synced) result, this removes the cluster copy too.
  • Everything - Settings ▸ Persistence ▸ Remove from this cluster deletes the CRD and all stored results for every workload on that cluster (cluster-admin). Your local history is untouched. You can also do this by hand with kubectl delete crd rightsizingresults.<group>.