A fresh sandbox is ready in 1.7 ms. An app can add an initialized instance in 2.7 ms.

ready before demand

Kedge keeps clean sandbox runtimes and initialized app instances restored and paused. A sandbox request gets a fresh, hardware-isolated runtime. App scale-out resumes an instance with its networking and identity already attached.

Neither path repeats a boot or framework startup.

when capacity is cold

If no paused app instance is available, Kedge restores one from the deploy snapshot on demand. Across Node, Rails, static, and Go apps, the fleet-wide median is 35 ms and p90 is 45 ms. The fastest apps have a 12 ms median.

Cold restore still starts after application initialization, because the deploy snapshot is taken at that boundary. Memory, image, filesystem, and shared-data pages load only as the instance reads them.

see it on a request

App responses report whether that request waited for an instance:

curl -sD - -o /dev/null https://myapp.kedge.run

X-Kedge-Restore: warm
X-Kedge-Restore-Ms: 2.7

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.

what the numbers measure

These are representative production-host medians, measured from a local request for a VM until it is ready. They exclude client network latency and application request time.

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