Docker tmpfs Mounts and In-Memory Storage

Docker offers three types of mounts: volumes, bind mounts, and tmpfs. Volumes and bind mounts write to the host filesystem. tmpfs mounts store data exclusively in the host’s memory. When the container stops, the data disappears. This makes tmpfs ideal for sensitive data that should never touch disk and for scratch space that benefits from memory speed.

How tmpfs Differs from Volumes and Bind Mounts

Feature	Volume	Bind mount	tmpfs
Storage location	Docker-managed directory	Host path you specify	Host RAM
Persists after container stops	Yes	Yes	No
Shareable between containers	Yes	Yes	No
Appears in image layers	No	No	No
Performance	Disk speed	Disk speed	RAM speed

The key property of tmpfs is ephemerality. Nothing written to a tmpfs mount survives a container restart. This is a feature, not a limitation, for the right use cases.

Basic Usage

Use the --tmpfs flag with docker run:

docker run -d \
  --name myapp \
  --tmpfs /tmp \
  myapp:latest

This mounts a tmpfs filesystem at /tmp inside the container. Any file written to /tmp lives in memory and disappears when the container stops.

For more control, use the --mount flag:

docker run -d \
  --name myapp \
  --mount type=tmpfs,destination=/tmp,tmpfs-size=100m,tmpfs-mode=1777 \
  myapp:latest

The --mount syntax lets you set the maximum size and file permissions.

Configuration Options

Size Limits

By default, a tmpfs mount can grow up to 50% of the host’s RAM. In production, you should always set an explicit limit to prevent a runaway process from consuming all available memory:

docker run -d \
  --mount type=tmpfs,destination=/tmp,tmpfs-size=67108864 \
  myapp:latest

The tmpfs-size value is in bytes. The example above sets a 64 MB limit. You can also use human-readable values in Docker Compose.

Permissions

The tmpfs-mode option sets the file mode in octal. The default is 1777 (world-writable with sticky bit), which matches the standard /tmp behavior on Linux:

docker run -d \
  --mount type=tmpfs,destination=/app/secrets,tmpfs-mode=0700 \
  myapp:latest

Setting 0700 restricts access to the container’s root user, which is appropriate for sensitive data.

tmpfs in Docker Compose

Docker Compose supports tmpfs mounts in two forms. The short syntax:

services:
  app:
    image: myapp:latest
    tmpfs:
      - /tmp
      - /run

And the long syntax with options:

services:
  app:
    image: myapp:latest
    volumes:
      - type: tmpfs
        target: /tmp
        tmpfs:
          size: 67108864
          mode: 1777
      - type: tmpfs
        target: /app/cache
        tmpfs:
          size: 134217728

The long syntax is necessary when you need to set size limits or custom permissions.

Use Case: Sensitive Data That Should Never Touch Disk

Applications that handle encryption keys, session tokens, or temporary credentials can write them to a tmpfs mount. If the host is compromised, there are no files on disk to recover. If the container is stopped, the data is gone from memory.

services:
  app:
    image: myapp:latest
    volumes:
      - type: tmpfs
        target: /app/secrets
        tmpfs:
          size: 10485760
          mode: 0700
    environment:
      SECRETS_DIR: /app/secrets

The application writes decrypted secrets to /app/secrets at runtime. They exist only in memory, never in a Docker layer, volume, or host file.

Use Case: High-Performance Scratch Space

Applications that do heavy I/O on temporary files, such as image processing, video transcoding, or sorting large datasets, benefit from tmpfs speed. Memory throughput is orders of magnitude faster than even NVMe SSDs.

docker run -d \
  --mount type=tmpfs,destination=/scratch,tmpfs-size=536870912 \
  --name transcoder \
  transcoder:latest

This gives the transcoder 512 MB of RAM-backed scratch space. Intermediate files never hit disk, reducing both latency and disk wear.

Use Case: Read-Only Containers with Writable tmp

Running containers with a read-only root filesystem is a security best practice. Many applications need a writable /tmp or /run directory. tmpfs provides this without breaking the read-only guarantee:

docker run -d \
  --read-only \
  --tmpfs /tmp \
  --tmpfs /run \
  myapp:latest

In Compose:

services:
  app:
    image: myapp:latest
    read_only: true
    tmpfs:
      - /tmp
      - /run

The root filesystem is immutable, but the application can still write temporary files. This significantly reduces the attack surface.

Use Case: Test Databases

Running a database in a test suite where you need speed but not persistence:

services:
  test-db:
    image: postgres:16
    tmpfs:
      - /var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD: testonly
      POSTGRES_DB: testdb

PostgreSQL runs entirely in memory. Tests that insert and query data run significantly faster, and there is no cleanup needed between test runs since restarting the container wipes everything.

Limitations

tmpfs mounts have constraints you should understand before using them:

• Not shareable. A tmpfs mount belongs to exactly one container. You cannot share it between containers the way you can with named volumes.
• Not swappable by default. If the host runs low on memory, tmpfs data competes with application memory. Set explicit size limits.
• Lost on restart. Any container restart, whether from a crash, scaling event, or deployment, wipes the data. Do not store anything you cannot regenerate.
• Linux only. tmpfs mounts work on Linux hosts. On Docker Desktop for macOS or Windows, they work inside the Linux VM but do not provide the same security guarantees since the VM itself writes to a disk image.

Practical Recommendations

Use tmpfs for /tmp and /run in every production container, especially when combined with read_only: true. Set explicit size limits to prevent memory exhaustion. For sensitive runtime data like decrypted credentials, tmpfs keeps it off disk entirely. For performance-critical scratch space, the speed improvement over disk is substantial. Just remember that anything in tmpfs is gone when the container stops, so never use it for data that needs to survive restarts.