15+ min
Growing a disk used to take 15+ minutes of retries and checks, sometimes while a customer was down. Now volumes scale themselves.
Cast AI watches how full each persistent volume gets, expands it before it fills, and tunes IOPS and throughput to match demand on supported disks in GKE and EKS. It starts in dry-run mode, so you review every change first.
100 ā 120 GiB plannedTrusted by 2,100+ companies
When a volume fills, writes fail with ‘no space left on device’ and the app goes down. When IOPS or throughput is set too low, latency creeps up with no clear error, because kubelet exposes neither. Fixing both by hand is slow, and homegrown scripts can fail.
Growing a disk used to take 15+ minutes of retries and checks, sometimes while a customer was down. Now volumes scale themselves.
Storage Autoscaler watches how full each persistent volume gets, and expands it once usage stays above your threshold.
On supported disks, Cast AI reads real IOPS and throughput usage from your cloud and adjusts what you provision, up or down, with a buffer.
100 ā 120 GiB plannedStorage Autoscaler installs in dry-run mode by default, so planned actions are logged and nothing changes until you turn it on.
Policies decide which volumes are managed and how: by namespace, name, label, or storage class.
Install with Helm in minutes. A default policy covers every eligible volume in dry-run mode, and nothing changes.
Review the planned expansions and performance changes in the logs, and check them against what you expect.
Switch a policy to live mode for one set of volumes, then widen it as you gain trust.
Use the StorageClasses you already have on GKE or EKS as long as they allow volume expansion.
Cast AI expands capacity as data grows, keeping room for new writes within the limits you set.
Tracks AWS EBS change limits and Google Cloud disk cooldowns before applying changes.
Annotations show the matched policy, disk type, current IOPS and throughput, operation status and last error.
Track volumes monitored, usage percent and growth count.
Validate the full resize path on a single volume, then go live on the rest.
Canāt find what youāre looking for?
Contact usGKE and EKS, on Kubernetes 1.29 or later. Capacity expansion works on every supported disk; IOPS and throughput tuning works on GKE Hyperdisk and PD Extreme, and on EKS gp3, io1 and io2. The StorageClass must allow volume expansion.
No. It installs in dry-run mode with a default policy that matches every volume, and it only logs planned actions. Volumes change only after you switch a policy to live mode. By default every eligible volume is covered, so scope policies by namespace, label or annotation before you go live.
No. Capacity expands only, and it manages persistent volumes only. Node root disks and ephemeral storage aren’t covered. On supported disks, IOPS and throughput can be tuned down as well as up.
It expands once usage stays above the threshold for the set period, 5 minutes by default, then waits through a cooldown. For volumes that grow fast, shorten the period or lower the threshold.
Read-and-write access to your cloud disks, read access to cloud disk metrics, and Kubernetes read access to disk usage. On GKE that’s a Google service account bound via Workload Identity Federation; on EKS it’s an IAM role assumed through IRSA (IAM Roles for Service Accounts). The exact roles and permissions are in the installation guide.
The controller reports its actions, configuration and logs to Cast AI, and Kvisor sends storage metrics such as usage and disk type. Every resize runs inside your cluster.
It can go either way. Matching IOPS and throughput to demand can lower cost on disks provisioned above what they use, and raise it on busy disks that need more than their baseline. Capacity only grows. Set per-volume caps on capacity, IOPS and throughput to keep a ceiling.
Install in dry-run mode, review the planned changes, and go live when you trust them.