What is a Docker container? Images, layers, and where data goes
A container is an isolated process built from a read-only image plus one writable layer, and it forgets everything when deleted. Why that design is right for software that must not forget.
A Docker container is, in Docker’s own words, “simply an isolated process with all of the files it needs to run.” The files come from an image (“a read-only template with instructions for creating a Docker container”), and a container is “a runnable instance of an image.” One image can spawn many containers, each self-contained, isolated from the host and from each other, and disposable: delete a container and nothing else is affected. If you’ve run software with a docker command, an AI agent included, this is what actually happened.
Image vs container: a class and its instance
The relationship trips everyone once, and then it’s obvious. An image is a frozen package (“all of the files, binaries, libraries, and configurations to run a container”) built as a stack of read-only layers, and immutable: “once an image is created, it can’t be modified.” Running it creates a container, which Docker gives one extra, writable layer on top. That’s the whole difference. The docs say it plainly: “the major difference between a container and an image is the top writable layer.” Everything the running program creates or changes lands in that layer; the image underneath stays pristine, which is why you can start a second, identical container from it any time.
Not a virtual machine
A VM boots a whole operating system; a container is just a process the host kernel runs with strong isolation around it. Docker’s framing: containers “all share the same kernel, allowing you to run more applications on less infrastructure.” The practical consequences: containers start in seconds and cost little more than the process itself, but they’re Linux processes at heart, which is why Docker on Mac and Windows quietly runs a small Linux VM underneath, and why a container is an isolation boundary, not a security guarantee equal to separate hardware.
The rule that matters: containers forget
The writable layer lives and dies with its container: “when the container is deleted, the writable layer is also deleted.” Anything you didn’t deliberately store elsewhere is gone. The “elsewhere” is mounts: a volume (“persistent data stores for containers, created and managed by Docker”) or a bind mount (a real host folder mapped into the container). Data written there survives any number of container deletions. This split (disposable container, durable mounts) is the design, not a flaw: it means the software can be replaced, upgraded, or recreated freely while the data stays put.
Why this matters more when the process is an agent
An AI agent is the sharpest version of the containers-forget rule, because its accumulated state (memory, conversation history, workspace) is the thing you care about. OpenClaw’s Docker setup is a textbook example of the split done right: the agent runs from a prebuilt, pinned image (disposable by design: a broken upgrade is fixed by recreating the container), while everything the agent is lives in mounted state directories that no container deletion can touch. Once that clicks, Docker stops being setup-guide voodoo: the image is the software, the container is one running copy, and the mounts are the life it accumulates.