Storage

Named volumes are great for keeping data alive across container restarts. The default behavior mounts the entire volume root at the container target. Sometimes you want to mount only a sub-directory — for instance, a single service among many sharing the same named volume, each scoped to its own directory. The subpath option does exactly that. The basic shape services: app: image: myapp volumes: - type: volume source: shared-data target: /app/data volume: subpath: app volumes: shared-data: The named volume shared-data exists once on the host. The app container sees only the app/ directory of it mounted at /app/data. Other directories in shared-data are invisible to app. ...

Compose volumes default to local disk on the host running the container. When you need storage shared across hosts, a volume driver does the job. The built-in local driver already supports NFS through its options. Basic NFS mount Declare a volume that points to an NFS export: volumes: shared: driver: local driver_opts: type: nfs o: "addr=nfs-server.example.com,rw,nfsvers=4" device: ":/exports/shared" services: app: image: myapp volumes: - shared:/data The app service mounts /exports/shared from the NFS server at /data inside the container. Multiple containers (or even multiple Compose stacks on different hosts) can mount the same volume to share data. ...

Speed up I/O operations and enhance security by using tmpfs for temporary data. RAM-based storage that vanishes on restart! What is tmpfs? Tmpfs is a temporary filesystem that resides in memory: ⚡ Ultra-fast (RAM speed) 🔒 Secure (data doesn’t persist) 🧹 Self-cleaning (cleared on restart) Basic tmpfs usage Simple tmpfs mount: services: app: image: myapp tmpfs: - /tmp - /app/cache - /var/run With size limits: services: app: image: myapp tmpfs: - /tmp:size=100M - /app/cache:size=500M - /var/run:size=10M Advanced tmpfs options Fine-tuned configuration: ...