Scale-to-Zero: How It Works and When to Use It

# Scale-to-Zero: How It Works and When to Use It

Scale-to-zero is one of the most cost-effective patterns in modern infrastructure: when a service has no traffic, it shuts down completely and costs nothing, then spins back up when a request arrives. It's also widely misunderstood. This article explains the mechanics and the real trade-offs.

The core concept

Most services run a fixed minimum number of replicas 24/7, even at 3 a.m. when nobody is using them. You pay for that idle capacity. Scale-to-zero changes the floor: when traffic drops to nothing, replicas scale down to zero. The service consumes no compute until the next request, at which point the platform spins an instance back up to handle it.

Traffic:   ▇▇▇▆▅▃▁ ............... ▁▃▅▆▇▇
Replicas:  3  2  1  0 (idle, $0)  0  1  2  3
                        ▲
                  request arrives → cold start

How it actually works

Three pieces make scale-to-zero possible:

1. 1An activator/proxy sits in front of the service. When replicas are at zero, incoming requests hit this component instead of the (nonexistent) app.
2. 2The activator holds the request and signals the autoscaler to start a pod.
3. 3Once the pod is ready, the activator forwards the buffered request and steps aside.

This is the model used by [KEDA](https://keda.sh/) (Kubernetes Event-Driven Autoscaling) and Knative. The autoscaler watches a signal — HTTP request rate, queue depth, a custom metric — and drives replica count, including all the way down to zero.

# KEDA ScaledObject — scale to zero on idle
spec:
 minReplicaCount: 0 # the magic: allow zero
 maxReplicaCount: 10
 cooldownPeriod: 300 # wait 5 min of idle before scaling to zero
 triggers:
 - type: prometheus
 metadata:
 query: sum(rate(http_requests_total[1m]))
 threshold: "1"

The trade-off: cold starts

There is no free lunch. When a request arrives at a scaled-to-zero service, it has to wait for an instance to start — the cold start. Depending on the workload, that's anywhere from a fraction of a second to several seconds. The components of a cold start:

The user who triggers the wake-up eats this latency. Everyone after them (while the instance stays warm) gets normal speed.

When scale-to-zero is a great fit

• Dev, staging, and preview environments — frequently idle, rarely latency-critical.
• Internal tools — used during business hours, dead overnight.
• Bursty/event-driven workloads — webhook receivers, batch processors.
• Side projects and low-traffic apps — cost matters more than tail latency.

When to avoid it

• Latency-critical user-facing paths — checkout, login, anything where a multi-second wait loses the user.
• Steady, predictable traffic — if you always have requests, you never reach zero, so you gain nothing and add complexity.
• Workloads with very heavy initialization — if booting takes 30 seconds, cold starts are unacceptable for synchronous requests.

A common middle ground is minReplicas: 1 — keep one warm instance to avoid cold starts, and autoscale up from there. You give up the zero-cost idle state in exchange for consistent latency.

How PandaStack uses scale-to-zero

PandaStack applies scale-to-zero via KEDA for free-tier apps, alongside gVisor sandboxing and spot/preemptible nodes. This is precisely what makes a genuinely useful free tier economically viable: your idle free-tier app costs the platform nothing, so it can be offered at $0. The honest trade-off, stated plainly: free-tier apps cold-start after a period of inactivity, and they run on preemptible nodes, so they're ideal for hobby projects, demos, internal tools, and preview environments rather than latency-sensitive production traffic.

The practical guidance is the same as anywhere: use scale-to-zero where idle cost savings matter more than first-request latency, and when you need consistent low latency for a production workload, run it on a paid tier with warm capacity. Pairing scale-to-zero with the cold-start mitigations in our dedicated guide (smaller images, lean startup) gets you the best of both.

References

• [KEDA documentation](https://keda.sh/docs/latest/concepts/)
• [Knative Serving: Autoscaling](https://knative.dev/docs/serving/autoscaling/)
• [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)
• [AWS: Operating Lambda — cold starts](https://aws.amazon.com/blogs/compute/operating-lambda-performance-optimization-part-1/)

Get scale-to-zero free-tier apps with no idle cost on PandaStack — start at [dashboard.pandastack.io](https://dashboard.pandastack.io).