A fresh sandbox is ready in 0.6 ms. App scale-out from a ready warm-pool instance takes 1.5 ms. When the warm pool is empty, cold scale-out is ready to accept connections in about 16 ms.

These are production-host measurements from local requests. They exclude client network latency and application response time.

ready before demand

Kedge keeps clean sandbox runtimes and initialized app instances ready in warm pools. They are parked in a paused state until needed. A sandbox request gets a fresh, hardware-isolated runtime. App scale-out resumes an instance whose app and network are already initialized.

Neither path repeats a boot or starts the app again.

when the warm pool is empty

Kedge restores an initialized instance from the deploy snapshot, so cold scale-out does not repeat app startup.

see it on a request

App responses report whether that request waited for an instance:

curl -si https://myapp.kedge.run | grep x-kedge-restore
x-kedge-restore: warm
x-kedge-restore-ms: 1.5

x-kedge-restore is warm or cold when the request triggered a restore, and none when an instance was already running. x-kedge-restore-ms appears only for a restore and reports how long the instance took to become ready.

See runtime & scaling for the snapshot lifecycle or sandboxes for one-shot and interactive use.