Serverless & scale to zero

Serverless is a service mode for web services with traffic that comes and goes. When no requests arrive, Koo scales the service to zero; the next request wakes it.

An idle serverless service shows Sleeping on the environment canvas. Sleeping is a normal state, not a problem — see status.

Enable serverless mode

1. On the environment canvas, click the service to open its drawer and go to the Settings tab.
2. In the Deploy section, turn on Enable serverless.
3. Press Deploy on the changes bar (Shift+Enter). The change is staged — nothing applies until you deploy.

Serverless can't be combined with a cron schedule or an attached volume — a web service runs in exactly one mode.

The replica count becomes a ceiling

In serverless mode, the replica count in Settings no longer means a fixed count. It is the scale ceiling: Koo scales from zero up to that many replicas per location on demand, then back down to zero when the service is idle.

The floor is always zero and the ceiling is the replica count — there are no separate minimum and maximum settings, and nothing to tune. Sizes and replica counts are covered in resources and scaling.

Sleeping and waking

When requests stop, the service goes to sleep and shows Sleeping. The next request wakes it: Koo starts a container and holds the request until the container is ready, then hands it to your app.

That first request pays the cold start — roughly your app's boot time. The faster your app boots, the shorter the wait, so keep startup light: a small image, quick initialization, and a health check that reports ready as soon as your app can take requests.

Billing

Compute on paid plans is billed in arrears for the CPU and memory the service declares, for as long as the service exists — sleeping does not pause the meter. See billing for how compute is rated.

When not to use serverless

Serverless fits stateless request handling. It is the wrong mode when:

• Your app keeps state in memory. Everything in memory — sessions, caches, counters — is lost each time the service sleeps. Keep state in a database instead, or run standard.
• Your app does background work. Loops, queue consumers, and in-process schedulers only run while requests keep the service awake; a sleeping service does no work. Run standard, or use cron mode for scheduled work.
• A cold start is unacceptable. If every request must be fast, including the first one after a quiet period, run standard and stay always-on.