Scale What Matters, Not Just CPU - Welcome Keda autoscaling
When CPU-Based Autoscaling Falls Short
Many production workloads cannot scale safely using CPU or memory. Take a billing system that processes batch requests via asynchronous jobs: you actually want each worker to run hot at 100% CPU, while scaling should follow the backlog in the queue. With CPU-based autoscaling, scaling often reacts too late, queues grow, and teams end up manually tweaking autoscaling settings during spikes to protect customer SLAs.
Autoscaling as a First-Class Platform Capability
Qovery reduces the operational effort required to run production workloads that need advanced Kubernetes primitives.
With KEDA integrated directly into application autoscaling, Qovery installs and manages KEDA for you and exposes it where you already configure scaling. You can choose standard HPA (CPU/memory) or switch to custom metrics without turning autoscaling into a separate infrastructure project.
What Changes for DevOps Teams
- Reduced risk of incidents on spikes or traffic change
- Fewer scripts or custom autoscalers to maintain
- Less waiting on DevOps to adjust manually the autoscaling
A Real-World Scenario
A customer running a billing system processes invoices through daily asynchronous jobs where latency directly impacts customer SLAs. With CPU-based autoscaling, scaling did not react fast enough to request spikes, forcing the team to manually adjust configurations to avoid delays. By enabling custom autoscaling on their SQS queue, they now scale jobs based on pending requests and consistently meet their SLOs.
How It Works in Qovery
- Open the service settings.
- Update autoscaling to use custom metrics with KEDA.
- Configure the metric source and the scaling rule to follow.
Try It on Your Workloads
Enable this on staging today and validate with a queue-driven workload. Read the docs here
Not yet a customer? Test our platform here!
.svg)
.svg)
.svg)
Suggested articles
At enterprise scale, managing provider-specific Kubernetes YAML across multiple clouds creates crippling configuration drift and operational toil. By adopting an agentic Kubernetes management platform, infrastructure teams abstract cloud-specific configurations (like ingress controllers and storage classes) into a single, declarative intent that automatically reconciles across 1,000+ clusters.
To stop GPU costs from destroying SaaS margins, teams must transition from static to consumption-based infrastructure by utilizing Karpenter for dynamic provisioning, maximizing hardware density with NVIDIA MIG, and leveraging Qovery to tie scaling directly to business metrics.
AI is helping developers write more code, faster than ever. But writing code is only half the story. What happens after? Building, deploying, debugging, scaling. That's where teams still lose hours.We're building Qovery for this era. Not just to deploy your code, but to make everything that comes after writing it just as fast.
By adopting GitOps and utilizing management platforms like Qovery, fintech teams can automatically generate DORA-compliant audit trails, transforming regulatory compliance from a manual, time-consuming chore into an automated, native byproduct of their infrastructure.
Kubernetes success is determined by Day 2 execution, not Day 1 deployment. While migration is a bounded project, maintenance is an infinite loop that often consumes 40% of senior engineering capacity. To protect margins and velocity, enterprises must transition from manual toil to agentic automation that handles scaling, security, and cost.
Day-0 is planning, Day-1 is deployment, and Day-2 is the infinite lifecycle of maintenance. While Day-0/1 are foundational, Day-2 is where enterprise operational debt accumulates. At fleet scale (1,000+ clusters), managing these differences manually is impossible, requiring agentic automation to maintain stability and eliminate toil.
.webp)