Kedge does not boot your app to serve a request. It restores a snapshot taken after the app finished initializing, so scaling from zero costs a restore rather than a startup.

autoscaling

Public services scale from zero by default. Kedge adds instances as requests arrive and removes them after they become idle.

scale.min, scale.max, scale.concurrency, and scale.idle-cooldown override that behavior. Recent demand also warms capacity ahead of bursts and nearby regional forwarding. See the Compose reference for exact fields.

readiness and health

The listen() boundary proves a server reached its socket. A Compose or image HEALTHCHECK adds an in-guest exec probe; deploy and replacement wait for it before reporting ready.

Deploy workflows explains how readiness gates traffic cutover and rollback.

workers and persistent services

A portless service is a worker and keeps a floor of one. It restarts work after a deploy; durable jobs belong in its queue, not memory.

A service with a persistent volume runs as stable members instead of following request demand.

warm and cold starts

Restore cost is mostly fixed platform work rather than workload startup. Reading /shared.db pages during wake can add faults from object storage.

Instant sandboxes & scale-out explains the measured latency of the ready and cold paths.

snapshots

Kedge boots a new service once and traps the moment it calls listen(). The process has initialized but has not accepted a connection. The VM freezes at that boundary as the deploy snapshot.

Later instances restore after framework startup, not before it. Memory and disk are copy-on-write, so clones share clean pages.

lazy image loading

Image blocks load only when the process reads them. A fresh host does not download the whole image before boot. Blocks are cached per host and shared by every clone, so untouched image data is never fetched.