How do I host a container app with persistent storage?

To host a container app with persistent storage, you need a storage layer that lives outside the container filesystem. Containers are ephemeral: if the container is replaced, any data stored inside it is lost unless you mount persistent storage.

Common approaches

1) Use a Docker volume (local host / single machine)

Best for:

• local development
• one server deployments
• simple stateful apps

Example:

docker run -d \
  --name myapp \
  -p 8080:8080 \
  -v mydata:/var/lib/myapp \
  myimage:latest

• mydata is a Docker-managed volume
• /var/lib/myapp is the path inside the container where the app stores data

If your app writes files there, they persist even if the container is recreated.

---

2) Bind mount a host directory

Best for:

• development
• explicit control over files on the host

Example:

docker run -d \
  --name myapp \
  -p 8080:8080 \
  -v /opt/myapp-data:/var/lib/myapp \
  myimage:latest

Pros:

• easy to inspect/edit data on the host

Cons:

• less portable
• permissions can be tricky

---

3) Use cloud block/file storage for production

Best for:

• production container apps
• Kubernetes, ECS, Azure Container Apps, etc.

Examples:

• AWS EBS / EFS
• Azure Managed Disks / Azure Files
• GCP Persistent Disk / Filestore
• Kubernetes PersistentVolume + PersistentVolumeClaim

This is usually the right choice if you need:

• durable storage
• scaling/restarts without data loss
• multiple replicas
• backup/snapshot support

---

If you’re using Kubernetes

You typically define:

• a PersistentVolumeClaim (PVC)
• mount it into the container at the path your app uses

Example:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-data
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: myimage:latest
          volumeMounts:
            - name: data
              mountPath: /var/lib/myapp
      volumes:
        - name: data
          persistentVolumeClaim:
            claimName: app-data

---

Key design rules

Put mutable data in a dedicated path

Examples:

• /var/lib/myapp
• /data
• /app/storage

Don’t rely on the container image filesystem for data.

Ensure the app writes there

Your app should be configured to store:

• uploads
• database files
• caches you want preserved
• user-generated content

Set permissions correctly

The container user must be able to read/write the mounted path.

Use backups

Persistent storage is durable, but not a backup. Back it up separately.

---

Choose the right pattern

• Simple app on one server → Docker volume
• Dev/test → bind mount
• Production cloud app → managed persistent volume/file share
• Kubernetes → PVC/PV
• Database → use a managed database if possible instead of container storage

---

If you tell me where you’re deploying (Docker Compose, Kubernetes, AWS, Azure, GCP, etc.), I can give you the exact setup and configuration.