When a stopped container is restarted in place rather than replaced with a fresh one, what is kept and what is discarded?
answer
- same container or a new one
- identity is the dividing line
- restart keeps the writable layer
- replacement starts from the spec
- only durable storage survives both
basics
~20 sA restart in place reuses the same container: same identity, same settings, same private writable layer and everything written into it. Only the process restarts, so memory, caches and in-flight work are lost. A replacement is a new container with a new empty writable layer.
solid answer
~50 sThe two look the same from the outside and keep completely different things. **Restarting in place** runs the first process again inside the *same* container: the identity, the settings bound at creation and the private writable layer are all still there, so files the previous run wrote locally are still on disk. What it does lose is everything that lived in the process — memory, caches, open connections, work in flight. **Replacing** creates a new container from the same spec: new identity, a new empty writable layer, and any changed spec or re-resolved image now takes effect, while everything the old container wrote locally goes with it. The only state that reliably survives both is what was written outside the container — a durable volume or an external store. Which of the two happens depends on the platform, so code that works because a restart kept local files fails the first time it is replaced.
go deeper
Hold on to the difference: restarting reuses the same container and the files it already wrote locally; replacing makes a new one that starts with nothing written.
Explain what each keeps — identity, bound settings, the private writable layer — and note that both lose everything held in the process's memory.
Show where it bites in production: a workload that looks resilient because a single-host restart kept its local files, and fails the first time a platform replaces it instead.
Make it a standard: workloads assume a cold start and own no local durable state, so the platform is free to replace rather than restart without any workload needing to know.
## Two different things are called "restart" When a container ends and something comes back, one of two things happened, and they are not variations of each other: - **Restart in place** — the *same* container runs its first process again. Same record, same identity, same settings, same private writable layer. - **Replacement** — a *new* container is created from the same spec and started, and the old one is stopped and eventually removed. Everything below follows from which of those two occurred, so it is worth refusing the ambiguous word in an incident conversation and asking which one it was. ## What a restart in place keeps - **Identity.** The same container, still listed under the same name and reference. - **The settings bound at creation.** They were fixed when the container was created, which is why a changed spec generally does not take effect on a restart — that needs a new container. - **The image it was created from.** A restart does not re-resolve a tag, so a newer image behind the same tag does not appear. - **Its private writable layer.** Anything the previous run wrote to a local path that was not a mount is still there: temporary files, caches on disk, partial output, lock files. And what it discards is exactly what lived inside the process: memory, in-process caches, open connections, anything in flight when it ended. The process starts from the beginning, with a disk that is not empty. ## What a replacement discards - **Local files.** The new container has a fresh, empty writable layer; nothing the old one wrote locally comes across. - **Identity.** A different container, with its own record and its own status history. - **Whatever was fixed at the old container's creation.** The replacement is built from the spec as it is *now*, which is the point of replacing rather than restarting: a changed spec or a re-resolved image takes effect here. ## Side by side | | restart in place | replacement | |---|---|---| | identity | same container | new container | | private writable layer | kept, with everything in it | new and empty | | settings and image | as bound at creation | taken from the spec now | | process memory and connections | lost | lost | | a durable volume or external store | kept | kept | The last row is the one to build on. Content on a durable volume, or in a database or object store outside the container, survives both — that is what "durable" buys. Everything in the first four rows differs, and none of it is something a workload should depend on. ## Why designs differ, and why that is the trap A single-host runtime typically restarts the same container in place: the container is the unit it manages, and starting it again is the cheap thing to do. A cluster scheduler typically does the opposite, creating a fresh instance from the spec — sometimes on a different machine entirely — because the spec, not the container, is what it treats as real. Neither is wrong; they are different levels of abstraction. The trap is that the same application behaves differently under the two without changing a line. A worker that writes progress to a local file, crashes, and is restarted in place picks up where it left off and looks resilient. The same worker under a platform that replaces it starts with an empty local disk, silently redoes or skips work, and the defect is blamed on the platform. The rule that survives both: treat anything written inside the container as gone at the next stop, and put anything that must outlive the run somewhere the container does not own. ## What this means for a workload 1. Write state that must survive to a durable volume or an external store — never to a local path that just happens to persist across restarts today. 2. Assume the process starts cold every time, whichever path it takes, because both lose memory. 3. Expect a changed setting or a newly published image to need a new container, not a restart. 4. When explaining an incident, say which of the two happened — "it restarted" and "it was replaced" imply different surviving state and therefore different causes.
- A worker keeps a local cache file to avoid refetching reference data on start-up. What happens to it under each path?A restart in place finds the cache exactly as the previous run left it, including anything stale or half-written. A replacement starts with no cache at all and refetches everything, so start-up is slower and any load that implies falls on the dependency. The code must therefore handle both a missing cache and a corrupt one.
- Why does a newly published image behind the same tag not take effect when a container is restarted in place?Because the container was created against a specific image and restarting reuses that container; nothing re-resolves the tag. A new image only takes effect when a new container is created, which is one reason platforms replace rather than restart when the spec changes.
- Does the previous run's exit code survive a restart in place?It depends on what the platform keeps: the container itself has one current status, so restarting overwrites the live view, and how much history is retained varies. That is why diagnosing a container that has ended and come back relies on what the platform preserved about the previous attempt rather than on the container's current state.
Restarting in place is rebooting the same machine — the disk is exactly as it was left. A replacement is a new machine built from the same blueprint, with a blank local disk; only what was stored off the machine is still there.
saying these in an interview costs you the question
- Assumes a restarted container always starts with an empty writable layer
- Expects local files written by the old container to appear in its replacement
- Says a restart picks up newly changed settings or a newer image
- Believes in-memory caches survive a restart of the container's process
- Uses restart and replacement as one word when reasoning about surviving state