Volumes, Binds, tmpfs

In one sentence: Anything written to the container's overlay dies with the container, so the engine offers three escape hatches — engine-managed volumes, host-path bind mounts, and RAM-backed tmpfs — mounted over chosen paths.

Three hatches, three owners

Each mount type answers "who owns this data?" differently. A volume is a directory the engine owns in its own storage area — created, listed, and removed via the API, portable across hosts because nothing about the host's layout leaks into the container config. Best default for databases and anything precious. A bind mount maps an exact host path the user owns — perfect for live-editing source code in development, but host-specific and a security door (the container sees real host files). tmpfs lives in RAM, owned by nobody: gone at stop, ideal for secrets and scratch space that must never touch disk. All three bypass the overlay entirely — native write speed, no copy-up.

flowchart LR
  subgraph C["container filesystem view"]
    P1["/var/lib/db"]
    P2["/src"]
    P3["/run/secrets"]
    P4["everything else
(overlay, dies with container)"]
  end
  V[("volume 'dbdata'
engine-managed area")] --> P1
  H["/home/user/project
(exact host path)"] --> P2
  T["tmpfs (RAM only)"] --> P3
  style V fill:#eaf1fe,stroke:#1d63ed
  style P4 fill:#fff8ec,stroke:#f2ddb0
    

Choosing in three questions

flowchart TB
  Q1{"must the data
survive the container?"}
  Q1 -- no --> Q2{"must it never
touch disk?"}
  Q2 -- yes --> T["tmpfs"]
  Q2 -- no --> O["overlay is fine
(no mount needed)"]
  Q1 -- yes --> Q3{"does a specific HOST path
matter to you?"}
  Q3 -- "yes (dev loop, host config)" --> B["bind mount"]
  Q3 -- "no — engine may place it" --> VOL["volume (default choice)"]
  style VOL fill:#eaf1fe,stroke:#1d63ed