Let’s build a precise, grounded definition before exploring the mechanics.

A filesystem that lives in memory, not on disk

A tmpfs mount gives a container a folder that behaves exactly like ordinary storage from the application’s point of view — files can be created, read, written, and deleted normally — except that everything stored there physically lives in the host machine’s memory (RAM), never touching the disk at all. It’s a genuine filesystem, just one built on top of memory instead of a physical storage device.

Deliberately, permanently temporary

Because it’s backed by memory rather than disk, everything stored in a tmpfs mount disappears completely and immediately the moment the container using it stops. There’s no “it might still be there” ambiguity — unlike a stopped container’s own writable layer, which lingers until explicitly removed, tmpfs content simply ceases to exist the instant the container using it is gone.

Understanding the specific gap tmpfs fills makes its design choices much clearer.

Problem 1 — Sensitive data lingering on disk

Sensitive, short-lived information — temporary authentication tokens, decrypted secrets used briefly during processing, session data — written to ordinary disk-backed storage remains physically present on that disk even after the application no longer needs it, and potentially even after the container is stopped, unless something explicitly and securely erases it. This creates a real, if often overlooked, exposure window.

Problem 2 — Unnecessary disk writes for genuinely temporary data

Plenty of data an application generates is never meant to be kept at all — scratch space used mid-calculation, temporary files generated and immediately consumed during processing, short-lived caches. Writing this kind of genuinely disposable data to disk anyway adds unnecessary wear and overhead for something that was never meant to outlive the moment it was created.

Problem 3 — Disk speed as a bottleneck for temporary work

Even fast disks are still measurably slower than memory for reading and writing data. For workloads that repeatedly read and write genuinely temporary data at high frequency, that disk-speed gap can become a real, measurable performance bottleneck — one that’s entirely avoidable if that temporary data never needed to touch disk in the first place.

Placing all three of Docker’s main storage mechanisms side by side makes tmpfs’s distinct role clear.

Volumes and bind mounts — both disk-backed

Named volumes and bind mounts, despite their own differences from each other, share one important trait relevant here: both are ultimately backed by persistent disk storage. Data written to either survives a container being stopped, and in the case of volumes, even survives that container being removed entirely.

tmpfs — the memory-only outlier

tmpfs stands apart from both by being backed entirely by memory, never touching disk at all. This isn’t a minor implementation detail — it’s the defining characteristic that shapes everything about when and why tmpfs is the right choice.

Let’s look at the underlying components that make memory-backed storage possible.

A memory-backed filesystem type

tmpfs relies on a specific kind of filesystem — one supported directly by the host operating system’s kernel — that’s specifically designed to store its contents in memory rather than on a physical storage device. Docker doesn’t invent this capability itself; it exposes and manages an existing, well-established operating system feature.

Scoped to a single container

Unlike volumes, a tmpfs mount isn’t a separate, independently managed object that exists outside of, and can be shared between, multiple containers. It’s created fresh for one specific container, exists only as long as that container does, and isn’t designed to be handed off to, or shared with, any other container.

The mount point, same concept as elsewhere

Just as with volumes and bind mounts, a tmpfs mount is attached to the container at a specific folder path — the mount point. Anything the application writes to that specific path is what actually lands in memory-backed storage; everything else in the container’s filesystem behaves as it normally would.

flowchart TD
    A[Container] -->|writes to mount point| B[tmpfs Mount]
    B --> C[(Host Memory / RAM)]
    A -->|writes elsewhere| D[Container's Own Writable Layer]
    D --> E[(Host Disk)]
        

A closer, more technical look at what’s actually happening when data is written to a tmpfs mount.

Files exist as memory pages, not disk blocks

Where a normal disk-backed file is stored as blocks of data on a physical storage device, a file written into a tmpfs mount instead exists as pages of data held directly in the host’s memory — the same fundamental resource used to run programs and hold their working data.

Growing and shrinking dynamically

A tmpfs mount doesn’t reserve a fixed amount of memory upfront by default; it grows to consume memory as files are written into it, and shrinks — freeing that memory back up — as files are deleted or the mount itself is removed. This dynamic behavior is part of what makes tmpfs efficient for workloads with unpredictable, varying amounts of temporary data.

Interaction with swap space

Depending on the host’s configuration, memory used by a tmpfs mount can, under memory pressure, potentially be moved to swap space — a portion of disk set aside to temporarily hold data that would normally live in memory. This is a subtle but important nuance: for use cases where truly never touching disk is a hard requirement (like handling especially sensitive secrets), this interaction with swap deserves careful attention and explicit configuration.

sequenceDiagram
    participant A as Application in Container
    participant T as tmpfs Mount
    participant M as Host Memory
    A->>T: Write a file
    T->>M: Store as memory pages
    A->>T: Read the file
    T->>M: Retrieve directly from memory
    A->>T: Delete the file
    T->>M: Free the associated memory
        

Because tmpfs consumes real memory, understanding how much it’s allowed to use — and how that’s tracked — matters for anyone relying on it seriously.

Why an unrestricted tmpfs mount is risky

Without any limit in place, a tmpfs mount could, in principle, be filled with enough data to consume a large, potentially unbounded amount of the host’s available memory — directly competing with the memory needs of the application itself, and potentially other containers sharing that same host.

Setting an explicit size limit

To guard against this, a tmpfs mount can be configured with an explicit maximum size, capping exactly how much memory it’s allowed to consume. Once that cap is reached, further attempts to write additional data into it fail, much like running out of space would on an ordinary, disk-backed filesystem.

Memory accounting alongside the container’s own limits

Memory consumed by a tmpfs mount typically counts toward the same overall memory accounting used to track and limit a container’s total memory usage — meaning tmpfs usage isn’t a separate, invisible pool of memory outside of a container’s normal resource constraints, but rather part of the same budget.

This is one of the clearest, most defining differences between tmpfs and Docker’s other storage mechanisms.

Scoped to a single container’s lifecycle by design

Named volumes are independent, standalone objects that can be mounted into multiple containers at once, or reused by a brand-new container later. tmpfs mounts, by contrast, are created and destroyed in lockstep with one specific container — there’s no independent tmpfs object sitting around that a second container could attach to.

Why this makes sense given what tmpfs is for

This restriction lines up naturally with tmpfs’s actual purpose: temporary, sensitive, or scratch data meant to disappear completely and immediately, tied tightly to one specific running instance. Sharing that kind of data between multiple containers would work against the very isolation and secrecy tmpfs exists to provide.

What to use instead when sharing is genuinely needed

For scenarios that genuinely need multiple containers to share the same data, a named volume — or, for smaller, purely in-memory sharing needs, other more specialized inter-container communication mechanisms — remains the appropriate choice, rather than trying to work around tmpfs’s inherently single-container scope.

Speed is one of tmpfs’s most tangible, practically meaningful advantages — worth understanding in a bit more depth.

Why memory access is inherently faster

Memory is fundamentally faster to read from and write to than even the fastest disk-based storage, because of how directly and closely it’s connected to a computer’s processing components. A tmpfs mount inherits this speed advantage directly, simply by virtue of never involving disk at all.

Where this speed advantage matters most

This advantage is most meaningful for workloads that read and write relatively small amounts of data very frequently — situations where disk access overhead, even on fast disks, would otherwise accumulate into a real, measurable slowdown over many repeated operations.

Where the advantage matters less

For workloads dealing with occasional, large, one-off pieces of data, the raw speed difference matters comparatively less, since disk overhead for occasional large operations is a smaller fraction of the overall time involved compared to many small, frequent ones.

Let’s look at the concrete situations where tmpfs is genuinely the right tool.

tmpfs is often reached for specifically because of security concerns — but it’s worth understanding both its real protections and its real limits.

The genuine benefit: avoiding disk persistence

For data that would otherwise be written to disk and remain recoverable after the fact — even after deletion, given how some disk-level deletion doesn’t immediately erase underlying data — routing it through tmpfs instead genuinely removes that particular exposure path, since the data was never written to disk in the first place.

The swap caveat, revisited

As discussed in Chapter 5, under certain memory-pressure conditions, tmpfs contents can still end up written to swap space on disk, depending on host configuration. For especially sensitive material, this nuance deserves explicit attention rather than being assumed away by tmpfs’s memory-backed reputation alone.

Data still exists in memory while the container runs

tmpfs protects data from persisting to disk, but it doesn’t make that data invisible while the container is actively running — anyone with sufficiently privileged access to the host machine’s memory during that time could, in principle, still access it. tmpfs addresses the “leftover on disk” risk specifically, not every conceivable access path.

Because tmpfs directly consumes a shared, finite resource — host memory — keeping an eye on its usage matters.

Tracking tmpfs memory consumption

Monitoring how much memory a container’s tmpfs mounts are actually consuming, ideally as part of the container’s overall memory usage picture, helps catch situations where temporary data is growing unexpectedly large, before it becomes a genuine resource problem.

Watching for size-limit rejections

If a tmpfs mount has an explicit size limit configured, tracking how often write attempts fail due to hitting that limit reveals whether the configured limit is appropriately sized for the actual workload, or needs adjustment.

Correlating with overall host memory pressure

Because tmpfs usage draws from the same overall pool of host memory used by everything else running on that machine, understanding tmpfs consumption in the context of total host memory pressure helps clarify whether tmpfs usage is a meaningful contributor to broader memory constraints.

Good pattern — reserve tmpfs for genuinely temporary, sensitive, or disposable data

tmpfs is most valuable when applied precisely to data that truly shouldn’t persist — sensitive secrets, genuine scratch space, disposable caches — rather than being used broadly as a general-purpose performance shortcut for data that might actually need to survive a restart.

Good pattern — always set an explicit size limit

Configuring a deliberate, appropriately-sized memory cap for every tmpfs mount used in a serious deployment prevents a single misbehaving process, or an unexpectedly large workload, from consuming far more host memory than intended.

No. The moment the container stops, its tmpfs mount and everything in it are immediately and completely discarded, with no intermediate lingering state.

No. Unlike named volumes, a tmpfs mount is scoped to a single container’s lifecycle and isn’t designed to be shared between multiple containers.

Under normal operation, yes. However, under memory pressure, host swap behavior can potentially cause that data to be written to disk-backed swap space, depending on configuration — worth understanding explicitly for especially sensitive data.

No, by default it grows and shrinks dynamically based on actual content, though it can be configured with an explicit maximum size to cap how much memory it’s allowed to consume.

Choose tmpfs specifically when data is genuinely meant to be temporary and disposable — sensitive short-lived secrets, scratch space, or high-frequency caches. Choose a volume whenever the data needs to persist beyond the container’s own lifecycle.

A tmpfs mount fills a specific, important gap left by Docker’s other storage mechanisms: a place for data that genuinely should never persist, offering memory-level speed and disappearing completely the instant a container stops. Unlike volumes or bind mounts, it’s scoped to a single container, backed entirely by host memory rather than disk, and requires deliberate size limits to avoid consuming more of that shared, finite resource than intended. Understanding its lifecycle, its performance characteristics, the important swap-space nuance for strict security needs, and the specific use cases it’s genuinely suited to — secrets, scratch space, disposable caches — is what allows it to be used precisely, as a deliberate design choice rather than a general-purpose shortcut.