Scaling
Give your application room to grow.
Plan capacity around the workload, with a clear baseline and an upper limit. Keep the scaling policy connected to the application and the infrastructure that supports it.
- Policy
- Defined around the workload
- Bounds
- A floor and a ceiling
- Capacity
- Your cluster and node pool
- Validation
- Test with your application
Inside the product
Capacity, with a clear set of boundaries.
The useful signal, the available headroom and the limits your team chooses. Make each part of the policy explicit.
Interface previews
Illustrative data · Early access
Set a floor and a ceiling
Define the capacity you want to keep available and the upper limit you are prepared to run. Make the boundary a deliberate choice.
Follow the useful signal
Different workloads saturate in different ways. Plan around the signal that reflects your service, from CPU usage to queued work.
Know where replicas can land
Service capacity depends on the cluster underneath it. Keep the available headroom in view when planning for a traffic increase.
Let the infrastructure catch up
Node-pool scaling is designed to support workloads as they outgrow existing capacity. Confirm the provider and policy support for your setup.
Planned capabilityMake limits visible
A service at its ceiling needs a decision. Review its current capacity and load together instead of assuming scaling can keep going.
Give idle environments a policy
Plan when a test environment should sleep or be removed. Persistent data and external resources need their own cost and retention decisions.
Planned capability
See it in context
Load changes. Capacity follows.
This illustrative loop shows the relationship between incoming load, service replicas and response time. Use your own workload to validate the actual behaviour.
Steady at api ×2. Nobody was paged.
Early accessScaling signals, node-pool automation and sleep policies depend on provider and cluster support. Confirm availability for your early-access deployment.
The workflow
Start with a policy. Watch the response.
- 01
Choose the signal
Identify the measurement that reflects your workload’s demand.
- 02
Set the boundaries
Agree baseline capacity, an upper limit and the cluster headroom.
- 03
Review under load
Check the application response and adjust the policy with evidence.
Good to know
A little more
before you start.
Have a particular application or setup in mind? Bring it to the early-access conversation.
Talk through your setup ↗Which scaling signals can I use?
The intended model includes workload-specific signals. The available policy and metrics depend on the cluster and integration confirmed for your deployment.
Does scaling mean the application will never slow down?
No. Startup time, dependencies, available cluster capacity and policy limits all affect the response. Test the application under expected load.
Does sleeping an environment stop every cloud charge?
No. Storage, networking and external services may remain billable. Review the retained resources separately from the workload’s running state.
Connected capabilities
One part of a bigger picture.
Build with Kapten
Start with one service.
Build from there.
Tell us what you want to deploy. We review each request and follow up about fit and onboarding on your preferred cloud.
Free during early access. No card required. Cloud usage billed separately.