By default a container's filesystem is ephemeral — a redeploy or restart starts from a clean image. Volumes give a service durable storage that survives both: a database's data directory, a search engine's index, an upload bucket.
How volumes work
A volume is a named mount with a path inside the container. Flicker provisions a persistent volume and mounts it at that path. The data lives independently of the container, so a new deploy attaches the same volume and picks up right where the last one left off.
One-click service templates declare their volumes for you. Meilisearch, for
instance, mounts a 5 Gi volume at /meili_data; ClickHouse
mounts /var/lib/clickhouse. Deploy the template and the storage
is provisioned automatically.
name: data path: /meili_data size: 5Gi
Live usage
A service's Volumes tab shows each volume's mount path, requested size, and live usage, so you can see how full a data directory is before it becomes a problem. Usage is read from the running workload, not estimated.
Volumes across a branch
A volume is tied to the app or service that owns it. When you branch a project, what happens to that volume follows a per-service branch policy:
- Clone the data — a copy-on-write clone of the parent's volume, so the branch starts with the same data (a Meilisearch index, for instance, carries over). Fast and cheap, like a database branch.
- Fresh volume — its own empty volume, for scratch or cache data that shouldn't carry over.
- No volume — a stateless app (a plain web server) gets new compute and no volume at all.
- Shared — the branch keeps using the parent's volume instead of getting its own.
A forked volume is isolated from the parent's — write to it or drop data and the parent is untouched — and it reaps with the branch. Deleting the app releases its volumes per the retention policy.