Change proposals
KubeOn proposes. You choose how it ships.
Each saving arrives as a change proposal: what runs now, what should run instead, the measurements behind it, the risk and the patch. Approve it and KubeOn opens a pull request on your own repository. Nothing reaches your clusters until it is merged and your CD deploys it.
Recommendations nobody ships
No evidence, no change:
Engineers will not cut a request on a dashboard's word. They need the usage that justifies it.No owner:
A list of savings across forty teams belongs to nobody, so it sits there.No safe path:
Automated rightsizing bypasses code review, which most production teams will not allow.No record:
Six months later, nobody remembers which savings were taken and which were rejected, or why.
Evidence and risk
Every proposal shows the numbers that justify it
A proposal lists the current and proposed state, the evidence behind the change (p95 usage, peak requests, days a volume has been orphaned), a risk level and a monthly saving. An optional summary is written only from that evidence. It can raise the computed risk, never lower it.
- Low, medium or high risk, computed per kind of change
- Risks and safe rollout steps on every proposal
- Long tails bundled per cluster or account, with per-item evidence
Ready-to-apply patches
The change is already written
Rightsizing proposals carry the YAML requests patch. Node proposals carry a Karpenter NodePool snippet or managed node group steps. Volume cleanups carry a script that checks each volume's state and snapshots it before deleting. On approval, KubeOn opens the pull request on the file the workload is defined in, found through Argo CD, Flux or Helm, and changes only the target lines.
- YAML requests in millicores and MiB
- kubectl scale for idle workloads, which is reversible
- Snapshot-then-delete scripts for volumes
# Check and delete possible orphans: touches only volumes still "available"for vol in vol-0c6a1e5f2b8d47391 vol-0e31f7c2a9d84b605; do state=$(aws ec2 describe-volumes --volume-ids "$vol" \ --query 'Volumes[0].State' --output text) [ "$state" = "available" ] || { echo "skip $vol ($state)"; continue; } aws ec2 create-snapshot --volume-id "$vol" \ --description "KubeOn before delete" --tag-specifications \ 'ResourceType=snapshot,Tags=[{Key=kubeon,Value=pre-delete}]' aws ec2 delete-volume --volume-id "$vol"doneReview workflow
Proposed, approved, applied, with every decision recorded
Admins, platform engineers and team leads can approve, reject, reopen or mark a proposal applied, with a note. Every transition is written to the audit log. Proposals regenerate daily and keep their decisions; ones the data no longer supports are marked superseded.
- One proposal per change worth $25 or more a month
- Coverage shows how much of the savings total has a proposal
- Explain with AI on any proposal
Automation
Run it automatically where you trust it
Clusters start on team approval. Turn on Automatic mode for a cluster and KubeOn opens the pull requests itself, within your limits: requests stay above p95 plus headroom, cuts are staged, only a few changes are open at once, and freezes and change windows hold. Production always waits for a person to merge.
- Team approval or Automatic, set per cluster
- Staged cuts, open-change limits, freezes and an off switch
- A CI check re-runs the safeguards before merge
Measured results
Every merged change, measured and reversible
After the merge, KubeOn confirms the deployment from Argo CD, Flux or the live spec and watches the cluster's health. A change that fails its checks is reverted with a pull request and an alert. What held is measured on the bill for node changes and on released requests for workload changes.
- Before-and-after charts per cluster
- Automatic revert and an alert on failure
- Projected and measured savings side by side
Where the Kubernetes savings are
off the monthly bill: $21,842 a month found at our sample company
Sample company, not a customer result
Proposal kinds
Ten kinds of change, each with its own patch
| Kind | Patch | Default risk |
|---|---|---|
| Right-size requests | YAML resource requests for the workload | Low |
| Scale idle workload to zero | kubectl scale --replicas=0, reversible | Low |
| Off-hours schedule | kube-downscaler namespace annotation | Low |
| Delete orphaned volume | Snapshot, then delete | Low |
| Reclaim released volume | Check the reclaim policy, then delete the PV and volume | Low |
| Shrink over-provisioned volume | New PVC and a copy-and-switch migration | High |
| Use smaller nodes | Karpenter NodePool or managed node group change | Medium |
| Change node family | Karpenter instance-category or node group change | Medium |
| Clean up orphaned file system volumes | Delete PVs and access points, keep directory paths on record | Medium |
| Check and delete possible orphans | Script that touches only volumes in the available state | Medium |
The agent stays read-only: its RBAC is get, list and watch, and the billing role reads billing data and writes only its own Athena query results. KubeOn changes a cluster only through pull requests, or through the separate controller on clusters where you granted write access.
Change control built in, not bolted on
Patches, not advice
Every proposal includes the change in the format your repo uses.
Risk levels
Computed per kind; summaries can raise them, never lower them.
Approve and track
Proposed, approved, applied, rejected or superseded.
Audit log
Who decided what, when, and the note they left.
Bundles
Small changes grouped per cluster or account, with per-item evidence.
Reversible by default
Scale-to-zero and snapshot-first deletes keep a way back.
Change proposals: your questions answered
KubeOn
Keep exploring
Evaluate change proposals with your team
Bring your platform and FinOps priorities. We will walk through the data, controls and evidence for your evaluation.