tmpfs Mounts for Sensitive Data in Docker Explained

1. Why some data must never touch the disk

By default, every file a container writes into its writable layer or a volume eventually ends up on the Docker host's disk. For most application data this is exactly right, since it should survive a container restart. For decrypted secrets, temporary session tokens, or intermediate keys for encryption operations, however, this very persistence is a security risk, because they remain in plaintext on a storage medium that could be read out in the event of disk theft or forensic access.

tmpfs mounts for sensitive data solve this problem by providing a filesystem that exists exclusively in memory and vanishes without a trace when the container stops. An attacker who later gains access to the disk finds no trace there of data that was once stored in the tmpfs, because it never reached the storage medium at all. The following sections show how tmpfs works technically, how it is set up in Docker, and where the limits of this security mechanism lie.

Compliance requirements such as GDPR or PCI DSS in many cases explicitly demand that certain categories of data must not be stored longer than necessary, and in some interpretations even that highly sensitive data such as credit card intermediate values should never be persisted at all. tmpfs mounts for sensitive data offer a technical proof here that certain data categories never leave the container in persistent form, which can significantly simplify audits and certifications.

2. How tmpfs works technically

tmpfs is a filesystem type implemented directly in the Linux kernel that keeps data exclusively in memory and optionally in the swap area, but never permanently on a block device. From the perspective of the application inside the container, a tmpfs mount for sensitive data behaves like a completely normal directory that can be read from and written to. The decisive difference lies in what the kernel does in the background: instead of writing pages to disk, they remain in memory pages that get freed and overwritten when unmounted or when the container stops.

This property not only makes tmpfs fast, since no disk I/O occurs, but also volatile in the best sense of the word: a host restart or a container stop completely and irretrievably erases the content. For tmpfs mounts for sensitive data, this very volatility is exactly the desired behavior, whereas for normal application data it would be a disqualifying property. Anyone who accidentally puts database data files into a tmpfs loses all data irrevocably on every container restart.

3. Setting up tmpfs mounts in Docker run and Compose

Setting up a tmpfs mount for sensitive data in docker run happens via the --tmpfs parameter, followed by the target path inside the container and optional mount options. In Docker Compose, the same thing happens declaratively via the tmpfs key in the service definition, either as a simple list of paths or as a more elaborate mount syntax with additional parameters such as size and permission mode. Both variants lead to the same result: an in memory filesystem that is empty again on the next container start.

A common use case for tmpfs mounts for sensitive data is storing decrypted configuration files that an application decrypts from an encrypted secret store at startup and then keeps only in the tmpfs afterward. This way, the decrypted plaintext never permanently touches the disk, even if the application itself does not implement any special in memory handling for secrets.

#!/usr/bin/env bash
# tmpfs-run.sh — mounting a tmpfs for decrypted secrets
set -euo pipefail

docker run -d --name app \
  --tmpfs /run/secrets-decrypted:rw,noexec,nosuid,size=64m,mode=0700 \
  mironsoft/app:latest

# Verify the mount is tmpfs, not a regular volume
docker exec app mount | grep secrets-decrypted
# tmpfs on /run/secrets-decrypted type tmpfs (rw,nosuid,noexec,size=65536k,mode=700)

# docker-compose.yml — declarative tmpfs mount for sensitive session data
services:
  app:
    image: mironsoft/app:latest
    tmpfs:
      - /run/secrets-decrypted:rw,noexec,nosuid,size=64m,mode=0700
      - /tmp/sessions:rw,size=128m,mode=1700
    environment:
      SECRET_DECRYPT_TARGET: /run/secrets-decrypted/config.json

4. Controlling size limits and memory usage

Without an explicit size limit, a tmpfs mount for sensitive data can theoretically grow up to half of the available memory, which on a host with multiple containers can quickly lead to memory pressure and, in the worst case, the kernel's out of memory killer. The size= parameter caps the maximum memory a mount can occupy and should be explicitly set for every production tmpfs usage, adjusted to the actually expected data volume.

A limit set too tightly causes write operations to fail with ENOSPC once the boundary is reached, exactly like a full disk. A limit set too generously, on the other hand, takes away the operating system's room to maneuver if several containers claim memory at the same time. For tmpfs mounts for sensitive data such as decrypted configuration files or session tokens, a few megabytes up to low double digit megabyte ranges are usually sufficient in practice, while larger intermediate results require correspondingly higher limits.

#!/usr/bin/env bash
# monitor-tmpfs-usage.sh — check current tmpfs memory consumption
set -euo pipefail

CONTAINER="app"

# Show tmpfs mount usage from inside the container
docker exec "$CONTAINER" df -h /run/secrets-decrypted

# Cross-check against the size= limit configured for the mount
docker inspect "$CONTAINER" \
  --format '{{ range .Mounts }}{{ if eq .Type "tmpfs" }}{{ .Destination }} -> {{ .RW }}{{ end }}{{ end }}'

echo "[INFO] Compare 'Used' column against the configured size= limit"

5. Permissions and mount options for sensitive data

Besides size, tmpfs mounts for sensitive data should also be given restrictive permissions and mount options. The mode=0700 option ensures that only the owner of the directory may read and write, while noexec prevents files in the tmpfs from being started as executable programs, an important safeguard against certain attack patterns where an attacker tries to write malicious code into a writable area and then execute it.

The nosuid option complements this protection by preventing SUID or SGID bits on files in the tmpfs from being honored during execution, even if noexec cannot be set for some reason. This combination of restrictive permissions and mount options makes a tmpfs mount for sensitive data not only volatile but also hardened against typical exploitation attempts, should an attacker already have achieved code execution inside the container.

#!/usr/bin/env bash
# verify-tmpfs-hardening.sh — confirm restrictive mount options are active
set -euo pipefail

docker run --rm \
  --tmpfs /secure:rw,noexec,nosuid,nodev,size=32m,mode=0700 \
  alpine sh -c '
    mount | grep /secure
    touch /secure/test.sh
    echo "echo pwned" > /secure/test.sh
    chmod +x /secure/test.sh
    /secure/test.sh || echo "[OK] Execution blocked by noexec"
  '

6. Common use cases: secrets, sessions, intermediate results

The most classic use case for tmpfs mounts for sensitive data is briefly storing decrypted secrets that an application fetches from a vault or KMS system at startup. Instead of setting the decrypted values directly as environment variables, which can become visible in process lists and debug output, the application writes them into a file inside the tmpfs and reads them from there, significantly reducing the risk of accidental disclosure.

A second common use case is session data in web applications that, for performance reasons, should not be kept in an external session database but locally in the container, while simultaneously must not end up on disk because it contains personal data. Temporary intermediate results of cryptographic operations, such as decrypted certificate keys for TLS termination, also benefit from tmpfs mounts for sensitive data, since they only need to exist for the runtime of the container and should then vanish without a trace.

Another, less obvious use case is temporarily buffering uploads during processing before they move encrypted into permanent storage. An application that first virus scans uploaded documents and then stores them encrypted can keep the unencrypted intermediate version in a tmpfs mount for sensitive data, so that at no point does an unencrypted copy permanently sit on disk.

7. Limits of tmpfs: what it does not solve

As useful as tmpfs mounts for sensitive data are, they do not solve every security problem around secrets. An attacker who has already achieved code execution in a running container can read the contents of a tmpfs just as easily as any other writable area, because the operating system inside the container makes no distinction between tmpfs and a regular directory, except when it comes to where the data ultimately gets written. tmpfs protects against offline attacks on the disk, not against attacks on an already running, compromised process.

Furthermore, tmpfs does not solve problems around securely transferring secrets into the container in the first place. If a secret enters the container via an unencrypted environment variable or a file outside the tmpfs before it gets stored there, the original transfer remains a potential risk. tmpfs mounts for sensitive data are one building block in a more comprehensive secrets management strategy, not a replacement for Docker Secrets, vault integrations, or encrypted transfer channels.

8. Swap behavior and the limits of volatility

An often overlooked aspect of tmpfs mounts for sensitive data is that under memory pressure the Linux kernel can swap out tmpfs pages to the swap area, if swap is enabled on the host. Once that happens, the supposedly volatile data does end up on a block device after all, namely the swap partition or swap file, and could potentially be recovered there after a restart or during a forensic examination.

For production environments with particularly high security requirements for tmpfs mounts for sensitive data, it is therefore advisable to either disable swap on the host entirely or set up encrypted swap that transparently encrypts data potentially swapped out. Alternatively, a sufficiently sized size= limit helps keep memory pressure low from the outset, so the kernel needs to resort to swapping less often.

A simple test for whether swap is active on the Docker host can be performed with swapon --show. If the command returns output, at least one swap area is active, and the volatility guarantee of a tmpfs mount for sensitive data is no longer fully intact. In Kubernetes environments, swap is disabled by default anyway, which makes tmpfs inherently a more robust choice there than on a classic Docker host with active swap.

9. tmpfs compared to other mount types

To better understand the role of tmpfs mounts for sensitive data, a direct comparison with the other common mount types in Docker is worthwhile.

The table makes clear that tmpfs is the only mount type among the four that fundamentally never writes data to disk. For all data where exactly this property is required, tmpfs mounts for sensitive data remain the right, simple solution, without needing to set up additional encryption software or external secret stores for purely runtime state.

In practice, most production setups combine several mount types at once: a named volume for the actual application data, a tmpfs for decrypted secrets and sessions, and occasionally a bind mount for configuration files that come from the repository. This combination uses the appropriate mount type for each data category, instead of forcing a single solution to cover every requirement.

10. Summary

tmpfs mounts for sensitive data provide in memory filesystems that are never written to the Docker host's disk and vanish without a trace when the container stops. They are excellent for decrypted secrets, session tokens, and temporary cryptographic intermediate results, but should always be given size limits, restrictive permissions, and the noexec and nosuid options.

It is important to know the limits of this mechanism: tmpfs protects against offline attacks on the disk, not against an already compromised running process, and can be swapped out under memory pressure if swap is enabled. tmpfs mounts for sensitive data are an important building block, but not a complete replacement for a comprehensive secrets management strategy.

11. FAQ: tmpfs Mounts for Sensitive Data