App code in the image, data in a volume

Originally published on docker.learnio.dev — part of the Docker fundamentals course. View this lesson on the original site.

Two homes for two kinds of files

App code and long-lived data do not belong in the same place in a container workflow.

• Put application code and runtime setup in the image (built from a Dockerfile).
• Put data that must survive container replacement in a volume or external service.

flowchart TD
    img["image: code + runtime"] --> ctr["container"]
    vol["volume: durable data"] --> ctr

For PHP: the image holds PHP, extensions, Composer output, and your app tree; a database container mounts a volume for its data files.

Try it

Run a container, write a file inside it, remove the container, run again:

docker run --rm --name cw-demo alpine sh -c 'echo inside > /tmp/scratch.txt && cat /tmp/scratch.txt'
docker run --rm alpine cat /tmp/scratch.txt

The second command fails — the file lived only in the first container’s writable layer.

If it goes wrong

• Expecting edits inside a running container to survive docker rm: they will not unless you used a volume or rebuilt the image.
• Storing uploads only in the container filesystem: they disappear on replace.

Remember

When a file changes, ask: should this be in the image, or should it outlive the container?

From Docker fundamentals — Install Docker, see the value, and learn the basics