Container Storage

A container starts with a filesystem assembled from image layers. It also gets a thin writable layer for changes made while it runs.

That writable layer makes the container usable. It does not make the container a safe home for durable data.

Container storage is the practice of deciding where each kind of runtime data belongs. The key choice is between container-local state and mounted storage.

The first mental model

Picture a container filesystem as two parts:

mounted storage       selected paths with separate lifecycles
------------------    ---------------------------------------
container view    =   image layers + writable layer + mounts
                      read-only      container-local  external

Image layers supply the starting files. The writable layer records runtime changes. Mounts place other storage at chosen paths inside the container.

All three appear in one directory tree to the application. Their lifecycles and operational properties differ.

The writable layer

Every container gets its own writable layer above the image's read-only layers. New files and changed files appear there.

Storage drivers implement this layered view. Many use copy-on-write. A read can use an unchanged file from a lower image layer.

The first modification copies that file into the writable layer. Later changes affect the copy, not the image layer below it.

This design saves space when many containers share one image. Each container stores only its own changes.

The writable layer follows the container. Removing the container removes that layer. A replacement container starts with a fresh writable layer.

Use it for disposable state such as temporary extraction, small caches, or files that can be recreated. Do not use it for required business data.

Heavy writes can also expose copy-on-write overhead. A mounted volume can avoid that storage-driver path for application data.

Mounts change a path's backing storage

A mount attaches storage at a destination inside the container. The application reads and writes the destination as an ordinary file or directory.

The mount hides anything already visible at that destination. Those hidden files still exist below the mount, but the running container cannot reach them there.

This rule explains a common surprise. Mounting storage over a directory populated by the image can make expected configuration or application files appear missing.

Choose mount destinations deliberately. Treat the destination path as part of the application's runtime contract.

Volumes: engine-managed persistence

A volume is persistent storage created and managed by the container engine. Its lifecycle is separate from any one container.

You can remove a container and attach the same volume to a replacement. You can also attach one volume to multiple containers when the application supports sharing.

Volumes fit databases, uploaded files, package caches, and other data that must outlive a replaceable container.

The engine manages the volume's host location. Work with the volume through engine interfaces and mounted containers instead of editing its internal directory.

An empty Docker volume mounted over existing image content is populated from that destination by default. A non-empty volume hides the destination's prior content.

Named volumes give durable data a stable identity. Anonymous volumes also persist in many cases, but their generated names make intentional reuse harder.

Persistence is not protection. You still need backups, restore tests, capacity monitoring, access control, and an intentional deletion policy.

Bind mounts: a specific host path

A bind mount exposes an existing host file or directory at a container path. The engine does not create an independent storage object around that content.

Bind mounts fit development source trees, host-generated configuration, build artifacts, and workflows that require direct host access to the same files.

The tradeoff is host coupling. A container can fail on another host if the required path or content is absent.

Bind mounts are writable by default in Docker. A container process can then modify or delete host files through the mount.

Use a read-only mount when the container only needs input. Limit the mounted path to the smallest required scope.

A bind mount refers to the daemon host. With a remote engine, a client path is not automatically available on that host.

Memory-backed mounts: deliberately temporary

On Linux, a tmpfs mount provides a temporary filesystem backed by host memory. Its contents disappear when the container stops.

Use tmpfs for nonpersistent scratch data when you want writes outside the container's writable layer. Set a size limit so one workload cannot consume unbounded memory.

Memory-backed does not always mean no disk trace. The host can write tmpfs pages to swap unless its memory and swap policy prevents that.

Do not use tmpfs for data that must survive a restart. Do not confuse temporary storage with a protected secret-delivery mechanism.

Choose storage by lifecycle first

Start with one question: what must happen to this data when the container is replaced?

Requirement	Default choice	Reason
Recreated with each container	Writable layer	Same lifecycle as the container
Survives container replacement	Volume	Separate managed lifecycle
Must be edited from the host	Bind mount	Direct host path access
Must disappear when the container stops	tmpfs	Temporary memory-backed filesystem

Then check sharing, portability, performance, security, backup, and capacity needs. The lifecycle answer narrows the field but does not finish the design.

Stateful applications need an operating model

Moving database files into a volume solves only one problem: the files can outlive the container.

It does not make concurrent access safe. The application and filesystem still define whether several processes may share the data.

It does not create consistent backups. A crash-consistent filesystem copy may not match an application-consistent database backup.

It does not move data between hosts automatically. A local volume remains tied to its host unless a volume driver or storage system provides another location.

Document who owns each volume, how it is backed up, how it is restored, and when it may be deleted.

Ownership and access still matter

The process inside a container accesses mounted files through normal filesystem permissions. A mount does not automatically align user and group identities.

An application may see permission errors when the mounted content has incompatible ownership or mode bits. Fix the ownership model instead of granting broad write access.

Read-only mounts reduce accidental modification. They do not make untrusted content safe to parse or execute.

Bind mounts deserve special care because their write scope reaches the host. Avoid mounting sensitive host directories or the container engine socket into ordinary workloads.

Read-only roots sharpen the design

The OCI runtime specification allows a container root filesystem to be read-only. This setting exposes undeclared write assumptions early.

With a read-only root, you add writable mounts only where the application needs them. The result is a clearer map of durable and temporary state.

This is a design and hardening aid, not a complete security boundary. A writable bind mount can still grant broad host access.

Storage is not the image

An image should contain application code and stable defaults. Durable runtime data belongs outside the replaceable container filesystem.

Do not rebuild an image to preserve runtime changes. Do not treat a running container as the only copy of important data.

Configuration also needs a lifecycle decision. Static public defaults can live in the image. Host-owned files may use read-only bind mounts.

Sensitive values need a purpose-built secret mechanism. A general storage mount does not provide rotation, auditing, or secrecy by itself.

Where this course stops

This course covers storage choices at one container host and the concepts shared by container engines.

Cluster storage adds scheduling, remote attachment, provisioning, topology, and failure-domain concerns. Kubernetes volumes and the Container Storage Interface deserve separate study.

Storage drivers for image layers are also distinct from volume drivers for application data. Similar names do not mean the same job.

Your path forward

First, trace which paths an application writes. Classify each path as disposable, durable, host-shared, or temporary.

Next, choose a mount type and test container replacement. Confirm that required data survives and disposable data does not.

Then test backup and restore. Check ownership, read-only behavior, capacity limits, and failure handling.

Finally, study the storage model of your orchestrator and infrastructure. Map local concepts to scheduling, remote storage, snapshots, and recovery objectives.