tmpfs Mounts

We’ve covered two ways to keep data alive outside a container’s writable layer — bind mounts and volumes. There’s a third option that does the opposite of “persist”: it stores data purely in memory, guarantees it never touches disk, and vanishes completely the moment the container stops. That’s tmpfs, and it earns its place for a specific, security-conscious set of situations.

What tmpfs Actually Is

A tmpfs mount is a directory inside your container that’s backed entirely by the host’s RAM, not by disk at all — not the container’s writable layer, not a bind-mounted host folder, not Docker’s managed volume storage. It behaves exactly like any other directory from the application’s point of view, but under the hood, every byte written there lives in memory.

    flowchart LR
    subgraph Host["Host Machine"]
        RAM["RAM<br/>(volatile memory)"]
        Disk["Disk<br/>(never touched)"]
    end
    subgraph Container["Container"]
        T["/run/secrets<br/>(tmpfs mount)"]
    end
    T <==>|"reads/writes"| RAM
    Disk -.->|"never involved"| T
  

The moment the container stops, that memory is released and everything written to the tmpfs mount is gone — instantly, completely, with no trace left on disk anywhere.

Why Use tmpfs

Given that it’s non-persistent, tmpfs might sound like the least useful of the three options. In practice, that exact property — guaranteed non-persistence — is precisely why it exists:

• Speed. RAM is dramatically faster than any disk, including SSDs. For workloads that need to write and read scratch data fast and don’t care about keeping it, tmpfs is about as fast as storage gets.
• Security for sensitive data. Secrets, tokens, decrypted credentials, or temporary keys that you don’t want lingering on disk — even briefly, even in a volume you’ll clean up “later” — belong in tmpfs. If the host is compromised or the disk is imaged, there’s nothing on disk to find.
• Guaranteed cleanup. No forgotten volumes, no orphaned bind-mounted files, no cleanup script that might not run. When the container stops, the data is gone — full stop, no follow-up action needed.
• Reducing disk wear and I/O contention. For high-churn temporary files (think cache directories with constant small writes), routing that traffic through RAM instead of disk reduces wear on physical storage and avoids competing with other disk I/O on the host.

Creating a tmpfs Mount

There are two equivalent ways to declare one:

# Shorter flag
docker container run -d \
  --name secrets-demo \
  --tmpfs /run/secrets:size=64m,mode=1770 \
  myapp:latest

# Explicit --mount syntax
docker container run -d \
  --name secrets-demo \
  --mount type=tmpfs,destination=/run/secrets,tmpfs-size=67108864,tmpfs-mode=1770 \
  myapp:latest

A few options worth knowing:

• size — caps how much RAM the mount can consume (defaults to unlimited otherwise, which is risky — always set this explicitly).
• mode — standard Unix permission bits for the mounted directory (e.g., 1770 restricts access tightly).

Real World Scenario: Handling a Decrypted Credential at Runtime

Say your app needs to decrypt a database credential at startup and write it to a file that a startup script reads, rather than passing it as a plain environment variable (which can leak into logs, process listings, or crash dumps more easily). You don’t want that decrypted file sitting on disk even momentarily.

docker container run -d \
  --name app-with-secret \
  --tmpfs /run/secrets:size=16m,mode=1700 \
  -e ENCRYPTED_DB_PASSWORD="$(cat encrypted.pass)" \
  myapp:latest

Inside the container’s entrypoint script, the app decrypts the credential and writes it to /run/secrets/db-password. That file exists only in RAM, only for as long as the container runs, and is never written to disk at any point — not even transiently. When the container stops or is removed, the credential is gone with it, with nothing to clean up and nothing left behind to accidentally back up, sync, or leak.

How tmpfs Is Different from Default Ephemeral Nature?

Here’s a fair question to pause on: the writable layer we covered back in the Ephemeral Nature section also disappears once you remove a container. So does tmpfs.

If both vanish eventually, what’s actually different?

The honest answer is: it’s not about whether the data disappears, it’s about where it physically lives while the container is still alive.

The writable layer isn’t a special temporary zone — it’s ordinary files sitting on your host’s disk, typically under something like /var/lib/docker/overlay2/<container-id>/diff/. Docker just deletes that directory once you remove the container. Until that moment, it’s regular disk-resident data like any other file on your machine.

tmpfs never touches disk at all, at any point. It’s backed directly by kernel memory pages, exposed as a filesystem. There’s no directory on disk for it to occupy — not while the container is running, not after it stops.

    flowchart LR
    subgraph WL["Writable Layer"]
        D1["Lives on disk<br/>the entire time"]
        D2["Deleted only when<br/>container is removed"]
    end
    subgraph TM["tmpfs"]
        M1["Lives in RAM<br/>the entire time"]
        M2["Released the moment<br/>container stops"]
    end
  

That distinction matters because being disk-resident, even temporarily, drags in a whole set of risks that have nothing to do with the container’s own lifecycle:

• It can get baked into a new image. docker commit snapshots the writable layer’s contents into an actual image layer. Anything sensitive sitting there — even briefly — can end up permanently embedded in an image, possibly one that gets pushed to a registry.
• It’s inspectable while the container is merely stopped, not removed. Tools like docker diff or docker cp can pull data out of a stopped container’s writable layer without it ever running again.
• It shows up in host-level backups. Back up /var/lib/docker at the host level, and every container’s writable-layer contents come along for the ride — including anything that was only ever meant to be temporary.
• Deletion isn’t the same as erasure. Removing a container unlinks its files, but on most filesystems the underlying disk blocks aren’t wiped, just marked free — which leaves a real (if narrow) window for forensic recovery.

tmpfs avoids all four of these structurally, not just by policy. There’s no on-disk file for docker commit to capture, nothing for docker diff to expose after a stop, nothing in a disk-level backup, and nothing sitting in freed disk blocks to recover — because it was never disk-resident in the first place.

Put simply: the writable layer’s disappearance is a bookkeeping decision Docker makes — it deletes something that was real disk data the entire time it existed. tmpfs’s disappearance is a structural guarantee — there was never a disk artifact for anything to leak, snapshot, back up, or recover in the first place.

Limitations and Gotchas

• Data is gone on container stop — not just removal. Unlike a volume or bind mount, tmpfs doesn’t even survive a container restart in the way the writable layer does. Stopping the container releases the memory. Treat tmpfs strictly as scratch space, never as anything you need even briefly across a restart.
• Counts against host memory, not disk. A large tmpfs mount competes with everything else running on the host for RAM. On memory-constrained hosts, an unbounded or oversized tmpfs mount can trigger OOM (out-of-memory) issues for completely unrelated processes.
• Not shareable between containers. Unlike a volume, a tmpfs mount is private to the single container it’s attached to — there’s no way to mount the same tmpfs into a second container to share its contents.
• Linux-only in practice. tmpfs is a Linux kernel feature; it’s not available the same way on Windows containers.
• Not a substitute for docker secrets in Swarm or Kubernetes Secrets. If you’re running an orchestrator, those systems have purpose-built secret management (encrypted at rest, access-controlled, rotated). tmpfs is the right tool for a single container’s ad hoc runtime secret handling, not a replacement for a full secrets management system in a cluster.

Quick Recap: All Three Options Together

With all three in your toolkit, the decision usually comes down to one question: does this data need to survive the container, and does it need to avoid touching disk? Answer that, and the right storage option follows naturally.