Storage Autoscaler

Volumes that grow before they fill

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.

  1. Starts in dry-run mode
  2. SupportsGKEandEKS
Storage AutoscalerDry-run
Capacitypostgres-data-0
82% used, above the 80% trigger100 → 120 GiB planned
PerformanceEBS gp3
Demand above current IOPS
Demand Current: 3,000 IOPS125 MB/s Planned: 6,000 IOPS250 MB/s
2 planned changes.Nothing applied yet.

Trusted by 2,100+ companies

  • Akamai
  • Yotpo
  • Iterable
  • NielsenIQ
  • Swisscom
  • Kakao
  • FICO
  • BMW Group
  • Hugging Face
  • ShareChat
  • WeWork
  • Cisco
  • PlayPlay
  • Roku

Full disks crash your apps, and throttled disks slow them down

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.

Anonymous customer

15+ min

Growing a disk used to take 15+ minutes of retries and checks, sometimes while a customer was down. Now volumes scale themselves.

Capacity and performance that follow demand

Volumes expand before they fill

Storage Autoscaler watches how full each persistent volume gets, and expands it once usage stays above your threshold.

  • Defaults you can change: grow at 80% usage held for 5 minutes, by 20%, at least 5 GiB.
  • A cooldown, 30 minutes by default, stops repeated expansions on the same volume.

IOPS and throughput that follow demand

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.

  • Sized to the peak of the last 6 hours plus a 20% buffer by default, or a percentile you choose.
  • Works on Hyperdisk, PD Extreme and EBS gp3, io1 and io2. Other disk types get capacity expansion only.
Storage AutoscalerDry-run
Capacitypostgres-data-0
82% used, above the 80% trigger100 → 120 GiB planned
PerformanceEBS gp3
Demand above current IOPS
Demand Current: 3,000 IOPS125 MB/s Planned: 6,000 IOPS250 MB/s
2 planned changes.Nothing applied yet.

Start in dry-run mode

Storage Autoscaler installs in dry-run mode by default, so planned actions are logged and nothing changes until you turn it on.

  • Review planned actions in the logs, then go live on one set of volumes first, or everywhere.
  • Switch back to dry-run at any time.

Set rules with policies

Policies decide which volumes are managed and how: by namespace, name, label, or storage class.

  • When several policies match, the higher-priority policy wins, and annotations on a single volume override the policy.
  • Cap capacity, IOPS, and throughput per volume, or turn off any of the three for volumes that shouldn’t change.

Dry-run, validate, automate

  1. Dry-run

    Install with Helm in minutes. A default policy covers every eligible volume in dry-run mode, and nothing changes.

  2. Validate

    Review the planned expansions and performance changes in the logs, and check them against what you expect.

  3. Automate

    Switch a policy to live mode for one set of volumes, then widen it as you gain trust.

Works with your existing StorageClasses

Use the StorageClasses you already have on GKE or EKS as long as they allow volume expansion.

02
Grow the volume before it fills.

Cast AI expands capacity as data grows, keeping room for new writes within the limits you set.

Storage capacity and performance, with and without autoscaling. Illustrative volume capacity and IOPS examples. Full volumes can fail writes. Storage Autoscaler expands capacity before it fills and adjusts provisioned IOPS as demand changes. Volume usage Ā· GiB data-prod-0 0 80 160 Used space Fixed capacity Time → Without autoscaling 100% 100 of 100 GiB used Writes fail No space left on device

More built in

Cloud limits respected

Tracks AWS EBS change limits and Google Cloud disk cooldowns before applying changes.

Status on every volume

Annotations show the matched policy, disk type, current IOPS and throughput, operation status and last error.

Prometheus metrics

Track volumes monitored, usage percent and growth count.

Prove it on one volume

Validate the full resize path on a single volume, then go live on the rest.

Take the next step

Your questions,
answered

Can’t find what you’re looking for?

Contact us
Which clouds and disks are supported?

GKE 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.

Will it change my volumes as soon as I install it?

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.

Does it shrink volumes or manage node disks?

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.

How fast does it react?

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.

What access does it need?

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.

Where is my data stored?

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.

Will it change my storage bill?

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.

#1 on G2262 reviews

Stop resizing disks by hand

Install in dry-run mode, review the planned changes, and go live when you trust them.