Volumes
Named Docker volumes for the data your application has to keep across deployments.
A deployment replaces containers. Anything written inside a container's filesystem is gone with it. A named volume is how state survives.
Adding one
A volume has two fields:
| Field | Rule |
|---|---|
| Name | ^[a-zA-Z0-9][a-zA-Z0-9_.-]*$, 1–64 characters. Docker's own rule for a volume name, checked here so a rejection happens in the portal rather than halfway through a deployment. |
| Mount path | Absolute, up to 255 characters, with no .. segments. Where the volume appears inside the container. |
Why the mount path must be absolute
A relative mount path is resolved against the container's working directory,
which the platform does not know. .. segments make the destination
unreviewable — and a mount path is exactly the kind of thing that has to stay
reviewable.
Volumes are mounted on the exposed service. A multi-service compose file that needs a volume on a different service should declare it in the file itself, as a named volume Compose manages.
What a volume is not
- Not a bind mount. The sanitiser rejects a bind mount of any host path outside the application's own workspace, because mounting a host path into a container reads anything on the box.
- Not backed up by the platform. Managed services have scheduled backups; an application's volume does not. Back it up from inside the application, or use a managed service for anything you would regret losing.
Removing one
Removing a volume detaches it. The Docker volume itself is left alone: it holds data somebody asked the platform to keep, and deleting it as a side effect of an edit is not recoverable.
The volume is destroyed with the application, where the confirmation names what is being destroyed.