# Autoscaling

> Scale an Ownkube web app or worker between a minimum and maximum replica count on live CPU. Pay for what runs, not what you provisioned.

**Autoscaling** adds replicas to a web app or worker under load and removes them when load drops, based on live CPU. Once it's on, Ownkube owns the replica count. On Ownkube Compute, turn it on with the `update_deployment` [MCP tool](/docs/mcp) or the API; on your [own cloud](/docs/own-cloud), from the deployment's **Settings** tab.

## How it works

Ownkube watches the average CPU of a deployment's containers against the target you set. On Ownkube Compute the target is a percentage of the CPU **limit**; on your own cloud it is a percentage of the CPU **request**. When usage crosses the target Ownkube adds replicas up to your maximum; when usage falls it removes them down to your minimum. This is the [horizontal autoscaling](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) model: more copies of the same container, not a bigger container.

### CPU target

Scale out when average CPU exceeds the target, for example 70% of the CPU limit on Ownkube Compute.

### Memory target (own cloud)

Scale out when average memory exceeds the target, for example 80% of the memory request. Ownkube Compute sizes each replica's memory automatically instead.

On your own cloud, set one target, both, or neither. With both, whichever is crossed first wins.

## What you configure

| Field | Default | Range |
|---|---|---|
| Min replicas | 1 | 1 to 100 |
| Max replicas | 3 | 1 to 100 |
| Target CPU utilization | 80% | 1 to 100 |
| Target memory utilization (own cloud) | 80% | 1 to 100 |

On Ownkube Compute the CPU target is a share of the **limit**: with a `500m` limit and a 70% target, Ownkube scales out when replicas average 350 millicores. On your own cloud it is a share of the **request**, so set an honest one.

## A typical setup

For a web service on Ownkube Compute with traffic that varies through the day:

| Setting | Value |
|---|---|
| Min replicas | 2 |
| Max replicas | 10 |
| Target CPU utilization | 70% |
| CPU limit | `1000m` |
| Memory limit | `1Gi` |

Two replicas stay warm, up to ten run under load (scaling out once they average 700 millicores), and the count settles back down when traffic drops. Each replica is metered per minute while it exists, so the bill follows demand. See [Understanding your bill](/docs/billing/usage).

## Autoscaling and the other knobs

- Once autoscaling is on, the fixed **Replicas** field is ignored. Turn autoscaling off to set a manual count.
- Autoscaling and [sleep](/docs/deployments/sleep) are exclusive. Sleep needs a single replica; autoscaling needs at least one always on.
- A **reserved box** billing mode applies per replica. Each replica autoscaling adds bills another box.
- Jobs run to completion and do not scale. Databases scale by changing their box size, see [Postgres](/docs/data/postgres).

## Watch it work

The **Overview** tab shows running and desired replicas and the CPU and memory charts the scaler reads. Scale events appear on the **Activity** tab. A CPU or memory [alert](/docs/observability/alerts) at a lower threshold than the scaling target warns you before the maximum is reached.

- [Sleep and wake](/docs/deployments/sleep)
- [Metrics](/docs/observability/metrics)
- [Cost control](/docs/billing/cost-control)

---

**Don't see a feature you need?** Email [support@ownkube.io](mailto:support@ownkube.io?subject=Feature%20request). Ownkube is shaped by the teams using it and we ship what our users ask for.

## Search

This site has a search endpoint: https://context7.com/api/v2/ask?siteKey=ask_c64dfe8ffaa8d3ad19576838&query=<URL-encoded question>. It returns documentation that answers the question, with a source link for each part. No API key is needed. If nothing matches, it says so.