What is scale-to-zero and how does it change cloud cost?
What is scale-to-zero?
Scale-to-zero flips the traditional cloud billing model: you pay only for the time your code is actually processing requests, not for the time a virtual machine simply exists. When traffic stops, the platform pauses the instance and your compute meter drops to zero. The next incoming request triggers a wake-up, the instance serves the request, and then it returns to a paused state after the idle timeout expires. This means idle hours generate no cost, while active hours are metered precisely to the work done.
Our internal billing data shows the impact of always-on compute. In a recent 16-day window, a customer’s total platform consumption was 1,305 credits, of which 1,096 credits,about 84 %, came from a single line: vCPU-hours on a virtual machine that never slept. The VM averaged under one vCPU of real work but ran for every hour in the period, so the per-hour meter charged for idle time as if it were doing useful work.
The math of always-on
Always-on billing has a fixed exchange with wall-clock time. A machine that never turns off accrues 730 metered hours in a 31-day month, one for each hour whether it served a million requests or zero. At our published rates, $0.036 per vCPU-hour and $0.004 per GB-hour of memory, the always-on baseline looks like this:
| Machine | Idle cost per month |
|---|---|
| 1 vCPU, 1 GB | about $29 |
| 2 vCPU, 2 GB | about $58 |
| 4 vCPU, 8 GB | about $141 |
That is the cost of existence before the machine does any work. In the example above, the customer’s database stored only a few megabytes and object storage held less than a gigabyte, so the non-compute portion of the bill was roughly 210 credits. The compute line was five times larger, and most of those hours contained no traffic at all. This is not a Scalix-specific trap; it is the outcome of two decades of cloud habits where the default is to pick a size, boot it, and leave it running.
Scale-to-zero: bill while serving, not while existing
With scale-to-zero the meter only runs while the instance is actively serving. When the request stream stops, the platform parks the instance and the compute cost drops to exactly zero. When the next request arrives, the instance wakes, serves the request, and then parks again after the idle timeout. Between requests you pay nothing.
On Scalix this model appears in three places:
- Functions - billed per invocation and scale to zero between calls. Nothing runs, nothing bills, until a request arrives.
- Run services - autoscale based on traffic; setting the minimum instance count to zero lets a service park when idle and wake on request.
- ScalixNova shared Postgres - suspends to zero when unused, so you only pay for storage and the brief compute bursts needed to serve queries.
Wake latency
The trade-off is latency on the first request after an idle period. Our production benchmarks measured a parked service waking to serve TCP in roughly 200 ms median, and a full first request through the TLS edge taking about 600 ms median. For APIs, dashboards, and internal tools this delay is imperceptible. For sub-ten-millisecond p99 paths you would keep the workload warm with an always-on instance or a higher minimum count.
When to keep an always-on VM
Keep an always-on machine when:
- Traffic is steady around the clock.
- You rely on persistent connections such as WebSockets or long-running database sessions.
- The workload is stateful and latency-sensitive to the point that even a few hundred milliseconds of wake-up time hurts your SLO.
A simple audit is to compare your billed compute hours to your request volume. Hours without requests are the portion you are renting for nothing; those are the hours scale-to-zero would eliminate.
Which Scalix products support scale-to-zero?
- Functions - per-invocation billing, automatic scale-to-zero.
- Run services - autoscale with min-instance-count set to zero.
- ScalixNova Postgres - suspends to zero when unused, waking on the first query.
If you want to see scale-to-zero in action, try deploying a function from our docs or start a Run service with a zero minimum. The free tier provides a starting line for experimentation, and you can move to a paid plan as your usage grows.
Read the functions quickstart to deploy your first scale-to-zero endpoint today.
FAQ
What is scale-to-zero in plain terms?
Scale-to-zero means a compute instance is billed only while it is actively serving work. When there is no traffic, the instance is paused and costs nothing; the next request wakes it, serves the request, and then it scales back down after the idle timeout.
How much does an always-on virtual machine cost per month on Scalix?
An always-on vCPU accrues 730 metered hours in a 31-day month. At $0.036 per vCPU-hour, one core costs about $26 per month before memory. A 2-vCPU, 2-GB machine idles at roughly $58 per month whether it receives traffic or not.
What is the wake latency for a scaled-to-zero service?
Our production benchmarks show a parked service wakes to serve TCP in about 200 ms median, and a full first request through the TLS edge measures around 600 ms median. For most APIs, dashboards, and internal tools this delay is imperceptible.
When should I keep an always-on VM instead of using scale-to-zero?
Keep an always-on VM when traffic is steady around the clock, when you rely on persistent connections such as WebSockets, or when the workload is stateful and latency-sensitive. Compare your billed compute hours to your request volume; hours without requests are cost you are paying for idle capacity.
Which Scalix products support scale-to-zero?
Functions are billed per invocation and scale to zero between calls. Run services autoscale, so setting the minimum instance count to zero lets a service park when idle and wake on request. ScalixNova shared Postgres suspends to zero when unused.
