Right-size your entire cluster. Without a single restart.

Autopilot continuously tunes every pod, node, and autoscaler to real usage, in place, inside your cluster. Zero downtime, flat cost, no telemetry.

Production, on schedule Autopilot the conductor · on-cluster Pods in place Nodes exact machine Autoscalers only misfits Consolidate fewer nodes four systems, one loop · no restarts

Built on the primitives Kubernetes gives you, not around them.

  • KEP-1287 in-place resize
  • Prometheus-native
  • PDB-aware draining
  • GKE & EKS
  • runs on-cluster
The bill

A right-sized cluster is a smaller bill.

The gap between what your cluster reserves and what it actually uses is money: most fleets run far below what they pay for. Right-sizing reclaims that difference, and Autopilot reclaims it continuously, recomputed as your usage shifts.

Four systems, one loop:

Right-size every pod

KEP-1287 in-place resizing matches every workload to its real CPU and memory usage, recomputed continuously and applied with no restarts, no rescheduling, no dropped connections.

Provision the exact node

When pods can't fit, Autopilot picks and provisions the right machine per pod instead of a one-size pool, spot and on-demand together, and drains the empties when demand drops.

Tune the autoscalers that need it

Analyzes every HPA and only touches the ~27% that are misconfigured: oscillation stabilized, min replicas right-sized, elasticity intact.

Consolidate, safely

Bin-packs fragmented capacity onto fewer, cheaper nodes, with a proven placement simulation and PDB-aware draining before a single pod moves.

Resilience

Right-sized is also resilient.

The same tuning that cuts the bill keeps production standing: workloads floored so they don't fall over on their busy day, autoscaler flapping damped before it cascades.

Autoscaler · backend replicas CPU vs target Min replicas floor suggested floor · preview HPA replicas flapping damped · floored floor
Headcount

Extend your DevOps team without extending headcount.

When right-sizing is automated and provably right, resource management stops being a team's job. The cluster stays correct without anyone standing over it.

Vertical optimization real usage in, right size out, pod untouched right-sized over-provisioned under-provisioned needs attention Workload CPU · request → recommended task backend database ▮ current request ▬ recommended
Signals before switches

It earns every change before it makes it.

The reason autonomous optimizers don't get turned on is fear they'll break production. Autopilot is built the opposite way:

  1. Start in observe-only mode.

    Watch what it would change, and why, before it changes anything.

  2. Every decision is visible.

    The dashboard shows the reasoning behind every resize, scale, and consolidation.

  3. Your settings always win.

    Floors, ceilings, and any explicit operator setting override Autopilot, per workload, permanently.

  4. No restarts, ever.

    Resizes apply in place while workloads keep serving: no rollout, no cold start, no dropped requests.

Pricing

Flat cost beats a tax on your savings.

Savings-based tools charge you more precisely when they work best. Autopilot is priced by footprint, not savings: a small, fixed monthly cost that doesn't grow with your cluster or your results.

Monthly cost Savings-based fee grows as your results do Autopilot fixed monthly · priced by footprint cluster size and savings →
Docs

Everything’s in the docs.

The docs cover everything: a 15-minute install, the full optimization loop, scheduled scaling, resource overrides, and pod tools.

autopilot.docs.xano.com
autopilot.docs.xano.com The docs, stop by stop 01 15-minute install 02 Optimization loop 03 Scheduled scaling 04 Resource overrides 05 Pod tools
Questions

Autopilot questions

Does Autopilot restart my pods?

No. Autopilot resizes workloads in place with KEP-1287 in-place resizing, so they keep serving while it applies the change: no rollout, no rescheduling, no cold start and no dropped requests or connections. Consolidation moves pods only after a placement simulation and PDB-aware draining.

What does Autopilot change in my cluster?

Four things, in one loop: each pod’s CPU and memory requests, matched to real usage; the nodes it provisions, picked per pod with spot and on-demand together; the HPAs that are misconfigured (about 27% of them); and fragmented capacity, bin-packed onto fewer, cheaper nodes. Your floors, ceilings and operator settings always override it.

What data leaves my cluster?

Autopilot runs on-cluster and works inside your cluster, with no telemetry. It is Prometheus-native and built on the primitives Kubernetes already gives you (in-place resize and PDB-aware draining), and the dashboard shows the reasoning behind every resize, scale and consolidation it makes.

Can I see what it would change before it changes anything?

Yes. Start in observe-only mode to watch what Autopilot would change, and why, before it changes anything. Every decision stays visible in the dashboard afterwards, and floors, ceilings and any explicit operator setting override Autopilot per workload, permanently.

Which clusters does it run on, and how is it priced?

Autopilot runs on GKE and EKS, and the docs cover a 15-minute install. It is priced by footprint, not savings: a small, fixed monthly cost that does not grow with your cluster or your results. Read the Autopilot docs or talk to an engineer.

Your cluster, understood.
Deployed in about 15 minutes.

Tell us about your setup and we'll show you what Autopilot would reclaim: a tailored savings estimate, a guided install when you're ready, and migration help from savings-based tools or manual right-sizing.