Compose Overrides

Compose overrides let you adjust the deployment of a single compose service — resources, commands, extra volumes — without editing the source file, and without diverting from the upstream project's updates.

The one rule for persistence#

ZenSailor builds compose stacks in a temporary folder, so relative paths like ./data are wiped on every redeploy. Persistent volumes must use the platform data path:

volumes:
  - ${ZENSAILOR_DATA_PATH}/pgdata:/var/lib/postgresql/data

${ZENSAILOR_DATA_PATH} resolves to the service's permanent directory (/opt/zensailor/volumes/<project>/<service>) on the node that holds the data, and is available inside the container as an environment variable. See Persistence and Volumes for the full rewrite rules.

Writing an override#

Overrides are keyed by compose service name and deep-merged over the base file (and over any other override). Platform-owned keys are rejected, so an override cannot hijack the routing, networking or persistence that ZenSailor manages.

# per-service override
services:
  web:
    environment:
      WORKERS: "4"
    deploy:
      resources:
        limits:
          cpus: "1.5"
          memory: 1G

Applying overrides#

From the dashboard (Service → Compose), the CLI:

# List services in the stack
zensailor service compose ls <service-id>

# Show current overrides
zensailor service compose overrides <service-id>

# Set overrides from a file (file replaces the override set)
zensailor service compose set-overrides <service-id> --file overrides.yaml

# Redeploy so the override takes effect

The same override surface is exposed through the API and MCP tools, so agents and scripts tune stacks with the same rules as the dashboard.