What is a container?

A container is a lightweight, isolated environment that packages an application together with everything it needs to run — code, libraries, and configuration — so it behaves the same way on any machine. Think of a container like a food delivery box: the box holds the meal, keeps it separate from everything else in the delivery bag, and once you finish eating, the box is thrown away. The meal (your application) was real and useful, but the box itself was never meant to be kept forever.

What does “ephemeral” mean?

Ephemeral means short-lived, temporary, disposable. Containers are designed to be ephemeral on purpose. Docker Inc. and the wider container ecosystem (including companies like Google, which pioneered large-scale container orchestration internally with a system called Borg) built containers to be thrown away and recreated constantly, because that is what makes them fast to scale, easy to update, and simple to replace when something goes wrong. If a container misbehaves, you do not repair it — you kill it and start a fresh one from the same image, the same way you would not try to fix a crumpled paper cup, you would just grab a new one.

What is persistent storage?

Persistent storage is any storage location whose data survives beyond the lifetime of the container that wrote it. In Docker, this means the data lives outside the container’s own writable layer, in a location managed by the Docker Engine or by the host operating system, so that even if the container is stopped, removed, or replaced by a brand-new container, the data is still there waiting to be reattached.

Why does this matter?

Most real applications are not stateless. A web server that only returns “Hello World” does not care if it restarts, but a database storing customer orders, a message queue holding unread messages, or a content management system storing uploaded images absolutely cares. These applications hold “state” — information that must not disappear. Running stateful applications inside ephemeral containers, without persistent storage, is like running a bank inside a building that resets to empty every night. Persistent storage is what lets Docker run both stateless and stateful workloads safely, side by side.

The container’s writable layer

Every running container gets its own thin “writable layer” sitting on top of the read-only image layers it was built from. This is where a container writes files by default if you do nothing special. It is fast and simple, but it is tightly bound to that one container’s lifecycle — delete the container, and this layer is deleted with it.

Volumes — the Docker-native answer

A volume is a chunk of storage that Docker itself creates, names, and tracks, usually kept under a managed directory on the host (on Linux, typically under /var/lib/docker/volumes/). Because Docker manages it, a volume can be created before any container uses it, attached to a container, detached, and then reattached to a completely different container later — the data does not care which container is currently using it.

Bind mounts — pointing straight at the host

A bind mount is different: instead of Docker managing the storage location, you are pointing directly at an existing folder or file that already lives somewhere specific on the host machine, for example a developer’s source code folder. This is powerful during development, because changes made on the host appear instantly inside the container, but it ties your container tightly to the exact folder structure of that one host machine, which becomes a problem the moment you try to run the same container on a different server.

tmpfs mounts — deliberately temporary

A tmpfs mount is the odd one out: it is not meant to persist at all. It stores data purely in memory for speed and privacy — useful for things like temporary session tokens or sensitive data you never want touching a disk — and it is wiped the instant the container stops. It is included here because understanding what is not persistent is just as important as understanding what is.

flowchart TB
    subgraph HOST["Docker Host Machine"]
        DE["Docker Engine"]
        subgraph STORAGE["Storage Options"]
            VOL["Named Volume
(Docker-managed)"]
            BIND["Bind Mount
(Host folder/file)"]
            TMPFS["tmpfs Mount
(RAM only)"]
        end
        subgraph C1["Container A"]
            APP1["Application Process"]
            WL1["Writable Layer
(ephemeral)"]
        end
    end
    DE -->|creates & tracks| VOL
    APP1 -->|writes local files| WL1
    APP1 -->|writes durable data| VOL
    APP1 -->|reads/writes host files| BIND
    APP1 -->|writes temp secrets| TMPFS
    VOL -.->|survives after| C1
    WL1 -.->|deleted with| C1
    TMPFS -.->|deleted with| C1
    

Layers upon layers: the union filesystem

A Docker image is built from a stack of read-only layers, each one representing an instruction in the Dockerfile — installing a package, copying a file, setting a configuration. Docker uses a technology called a union filesystem (most commonly the “overlay2” storage driver on Linux) to stack these layers so they appear to the running process as one single, normal-looking filesystem, even though physically they are separate layers on disk.

When a container starts, Docker adds one more layer on top of the stack: the writable layer mentioned earlier. Any file the application creates or modifies goes into this top layer, using a technique called “copy-on-write” — if the application changes a file that originally came from a read-only layer below, Docker copies that file up into the writable layer first, then applies the change there, leaving the original layer untouched. This is precise and efficient, but it also explains why the writable layer disappears with the container: it was only ever a temporary “top sheet” on the stack, not a permanent part of the image.

How a volume bypasses the writable layer entirely

When you mount a volume into a container at a specific path, Docker does something clever: for that specific path, it stops using the union filesystem stack altogether and instead redirects all reads and writes straight to the volume’s location on the host disk. The application inside the container has no idea this is happening — from its point of view, it is just writing to a normal folder. But behind the scenes, none of those writes ever touch the temporary writable layer, so none of them are lost when the container is removed.

Named volumes vs. anonymous volumes

Docker distinguishes between named volumes, which you create with a specific identifiable name so you can find and reuse them deliberately, and anonymous volumes, which Docker creates automatically (often because an image’s Dockerfile declared a mount point) but gives a random-looking ID. Anonymous volumes are easy to lose track of and are a common source of “mystery” disk usage on developer laptops, because nothing obviously points back to which container created them.

What an interviewer may ask

An interviewer may ask you to explain, in your own words, why a container’s writable layer is deleted on removal but a mounted volume is not. A strong answer references the union filesystem: the writable layer is just a temporary top layer in the stack tied to that container’s identity, whereas a volume mount redirects the relevant path outside that stack entirely, to storage Docker manages independently.

This lifecycle is the entire reason persistent storage exists in Docker: it decouples the lifetime of your data from the lifetime of any single container, which is exactly what lets you upgrade, restart, and even completely replace containers without any data loss.

The central trade-off is this: the very thing that makes containers powerful — being disposable and identical every time — is in direct tension with the very thing stateful applications need — memory of what happened before. Persistent storage is the compromise that lets you keep both properties at once, but it does mean accepting a little extra operational complexity in exchange for data safety.

File permissions and ownership

A volume’s files carry real Linux file ownership and permission bits, exactly like any other file on the host. If a container process runs as the root user inside the container (which is the default unless explicitly changed), files it writes into a volume are typically owned by root on the host too. This becomes a real problem if that same volume is later mounted into a less-trusted container, because that container may now have unintended access to sensitive files.

Bind mounts and the “escape the sandbox” risk

Because a bind mount points directly at a real path on the host, mounting something too broad — for example, mounting the entire host root filesystem, or the Docker daemon’s own socket file — can give a container the ability to read or modify files well outside its intended boundary, effectively breaking the isolation containers are supposed to provide. This is a well-documented category of container escape technique and is one reason security teams treat bind mounts with more caution than named volumes.

Encryption and sensitive data

Data sitting in a volume on disk is not automatically encrypted. Companies handling regulated data — payment details, health records, personal information — typically pair Docker volumes with host-level disk encryption, or use cloud-backed volume drivers (such as Amazon EBS with encryption enabled) that provide encryption at rest as a built-in feature of the underlying storage service.

Least privilege for storage

A strong security practice is to mount volumes as read-only wherever the application does not genuinely need to write to them — for example, mounting a configuration folder read-only prevents a compromised application process from tampering with its own configuration. Combined with running the container as a non-root user, this significantly narrows what an attacker could do even if they managed to compromise the application inside the container.

What an interviewer may ask

An interviewer may ask how you would prevent a compromised container from damaging data outside its intended scope. A good answer combines least-privilege mounts (read-only where possible), avoiding broad bind mounts of host system paths, running as a non-root user, and using volume drivers with encryption at rest for sensitive workloads.

What to monitor

Operations teams typically track how much space each volume is consuming, how quickly that space is growing, and how close a volume is to filling its underlying disk — a full disk can cause an application to fail in ways that are confusing to diagnose if you were not already watching the trend. They also monitor read and write latency for each volume, since a sudden slowdown in storage response time often shows up first as a mysteriously “slow” application, when the real cause is the storage layer underneath it.

Finding forgotten volumes

Because volumes outlive containers by design, it is easy to accumulate volumes that no running container references anymore. Regularly auditing for these “dangling” volumes — and safely removing the ones that are genuinely no longer needed — is a routine housekeeping task in any team running Docker in production, similar to periodically clearing out old backup files that nobody remembers creating.

Logging considerations

Container logs themselves are a separate concern from persistent data storage, but the two often interact: if an application logs directly to a file inside a volume instead of to standard output, that log data becomes persistent too, growing indefinitely unless log rotation is configured. Best practice is generally to send logs to standard output (letting Docker’s own logging drivers handle them) and reserve volumes strictly for actual application data.

Pattern: one volume per stateful service

Give each stateful service — a database, a message broker, a search index — its own dedicated volume, rather than sharing one volume across multiple unrelated services. This keeps failure domains isolated: if one service’s data needs to be restored from backup, you are not risking any other service’s data in the process.

Pattern: sidecar for data management

A “sidecar” is a small, secondary container that runs alongside the main application container and shares access to the same volume, handling a supporting task like backups, log shipping, or data synchronization, without that logic having to live inside the main application’s image. This pattern lets you upgrade the backup logic independently of the application itself.

Anti-pattern: the old “data-only container” trick

Early in Docker’s history, before named volumes matured, teams used a workaround called a “data-only container” — a container whose entire purpose was to hold a volume that other containers would then reference. This pattern is now considered obsolete, since Docker’s native named volumes accomplish the same goal directly, without needing a placeholder container to stay around indefinitely.

Databases in containers

Companies running PostgreSQL, MySQL, or MongoDB inside Docker containers universally mount a volume at the database’s data directory. Without it, restarting the database container to apply a routine update — something that happens regularly in any production system — would wipe out every table and row the moment the old container was removed.

Uber and large-scale container platforms

Uber’s engineering teams have published details of their large-scale internal container platforms, where stateful services rely on carefully managed persistent volumes so that thousands of containers can be rescheduled across different machines without any service losing its data during normal cluster operations.

Netflix and resilient infrastructure

Netflix is well known for deliberately and randomly terminating running instances of its services in production (a practice popularized through tools in their “Chaos Engineering” toolkit) specifically to prove that services can be destroyed and recreated without data loss — a discipline that depends entirely on the underlying storage for those services being properly persistent and decoupled from any single running instance.

Content platforms and media storage

Content management and media platforms that let users upload images or files typically avoid storing those uploads inside the application container at all, instead writing them directly to a persistent volume or, at larger scale, to a dedicated object storage service such as Amazon S3, so the application containers themselves remain fully disposable and interchangeable.