Autonomous, inside your guardrails.
Autonomous Infrastructure keeps CPU and memory requests right for your Kubernetes workloads,
shrinking what's over-provisioned and growing what's running short, using production data groundcover already collects.
See the impact first.
Desired CPU and memory, estimated monthly cost, and impact for every deployment, whether or not you turn it on.
Sized for the node, not just the pod.
Node contention goes into every decision, so raising one workload doesn't starve its neighbors.
Requests only, never limits.
Off by default, on per deployment, and your declared limit is always the ceiling.
Your savings, before you
change anythingAutonomous Infrastructure computes desired sizing for every Deployment from the data the groundcover eBPF sensor already collects, so there's no new agent and no waiting for data before you see results. The Autonomous Infrastructure page shows current impact, the impact still available, and how many workloads are under-provisioned, with original and desired CPU and memory side by side for each workload. Dollar figures are estimated monthly USD at default list prices, and admins can enter their own prices and discount.
Sized for the node, not just the pod
Most rightsizing tools size each workload on its own, so a request that looks right for one service can still starve its neighbors on a crowded node. Autonomous Infrastructure folds node contention into every decision. It grows workloads that are running short as well as trimming waste, and it sizes injected and native sidecars like Istio, Linkerd, and Vault agents, where waste often hides. In the demo below, a worker reserving 50m of CPU blows past its 200 ms response target whenever a noisy neighbor fills the node. With its request raised to about 0.6 CPU, it stays on target.
In the views you already use,
running in your cloudAutonomous Infrastructure lives inside groundcover, not next to it. Every workload page has an Auto Infra tab showing requests, cost, and impact, with the toggle right there. Desired requests and estimated costs are queryable in gcQL, so you can build them into dashboards alongside usage and node utilization. It's built on the optimization engine from Wand, the Kubernetes resource optimization company groundcover acquired in September, and it runs in your own cloud on full-fidelity eBPF data.
Built on the sensor you already run
- Built on Wand's Kubernetes optimization engine
- Runs in your cloud on full-fidelity eBPF data from the groundcover sensor, no sampling
FAQ starters
No. It's off by default. You see desired sizing and estimated impact for every Deployment first, and nothing changes until an admin turns it on for a specific Deployment.
CPU and memory requests only. It never raises, lowers, adds, or removes limits. Your declared limit is the ceiling, and a workload capped by it shows as Bounded.
No. Any resource an HPA or KEDA scales on by utilization is locked, and Autonomous Infrastructure won't touch it.
No. It writes annotations only, never labels, and resizes pods in place without touching the Deployment's pod template, so GitOps tools see no drift.
Not when it can be avoided. It resizes running pods in place with no restart, and falls back to a rollout with a backoff gate only when in-place isn't possible.
Kubernetes Deployments, including injected and native sidecars. More workload kinds are on the roadmap.
They're estimated monthly USD at default on-demand list prices, not billed spend. Admins can enter their own price per vCPU-hour and per GiB-hour, plus a discount.
Deactivate it for the Deployment. New changes stop immediately; roll out the Deployment to restore its original values.
Explore More
groundcover products
Discover additional groundcover capabilities that work seamlessly with Autonomous Infrastructure.
Observability
for what comes next.
Start in minutes. No migrations. No data leaving your infrastructure. No surprises on the bill.
