Persistence and Volumes

ZenSailor builds compose stacks in a temporary folder, so anything that is not mounted from a permanent location is lost on the next deploy. There is one rule that keeps data alive:

Persistent volumes go through ${ZENSAILOR_DATA_PATH}.

YAML

# Persistent volume — survives every redeploy
services:
  db:
    image: postgres:16-alpine
    volumes:
      - ${ZENSAILOR_DATA_PATH}/pgdata:/var/lib/postgresql/data

${ZENSAILOR_DATA_PATH} resolves to the service's permanent directory on the node that holds its data — /opt/zensailor/volumes/<project>/<service> — and is also present inside the container as an environment variable.

Volume rewrite rules#

When a compose file lands, ZenSailor rewrites its volumes:

Compose volume	What happens
Named volume (`db-data:/var/lib/postgresql/data`)	Converted to a managed volume under the data path
Relative path (`./data:/data`)	Rewritten under the data path — otherwise the build folder wipe removes it
Absolute host path (`/srv/data:/data`)	Kept as-is; you are explicitly directing it
`:ro` mounts	Read-only flag preserved

The Persistence Manager#

For each service, the storage panel shows every mounted path and lets you:

manage the mount path and its optional host-path subfolder,
target a specific compose service of a multi-service stack when several services mount the same path,
see which node holds the data and when it was elected,
migrate the volume to another node (see Storage Across Nodes).

Service deletion removes its data directory. Project renames rename the volume directory to match. Platform pruning never touches managed bind mounts.