Stop Starting, Start Resuming: Quickly starting dockers

Cold starting docker containers is expensive. Before a Dockerized application does anything useful, it pulls images, initializes the runtime, loads classes or modules, allocates memory, opens files and sockets, and slowly warms into a steady operating state. In modern infrastructure, this cost shows up everywhere: pod restarts, scale-outs, rollouts, autoscaling events. Each time, the same warm-up work is paid for again.

Capture and restore offers a different idea: instead of starting containers from scratch, we can resume them.

When a container’s state is frozen, the entire running container is captured at a specific moment. The processes inside it, their memory, threads, and execution state are frozen and written to disk. Restoring the container brings it back exactly where it left off. The container does not rerun initialization code or repeat warm-up logic. Execution continues from the point where it was paused. From the applications’ perspective, this feels less like a restart and more like waking up after a brief pause.

The value for Docker environments is straightforward. Containers are often most expensive right after they start. If a container is already warm, stable, and ready to serve traffic, why throw that away? By saving a warm image at the right time, infrastructure pays the cost of warm-up once and reuses it many times. New containers can appear already prepared to handle work.

Some parts of execution still live outside the container boundary. CPU caches and branch predictors are rebuilt naturally after restore. Scheduling history is lost. Time moves forward while the container is paused, even if the process itself did not experience that passage. Network connections may persist, but the systems on the other end were never frozen. These limits are inherent, but they rarely matter for fast startup and readiness.

This doesn’t weaken the restore model; it just defines the limits. In practice, those limits are rarely a problem. Most systems care far more about preserving progress and avoiding repeated work than about recreating a perfectly identical moment in time. State preservation isn’t about recreating the universe; it’s about resuming useful work with minimal friction.

And it raises an interesting question for the future: What if containers did not just start quickly, but started already warm?

We’re not there yet. But even today, resuming from captures lets systems bend time in useful ways by choosing when warm-up work happens and when it doesn’t have to happen again.