Environment Variables and Secrets

Environment variables are managed at project, environment and service level and resolved downward at deploy time: a service value overrides the environment value, which overrides the project value. The service's resolved set is what its containers get.

Scope#

Scope	Visible from	Example
Project	Every environment and service in the project	`LOG_LEVEL=info`
Environment	Every service in that environment	`SPRING_PROFILES_ACTIVE=prod`
Service	Only that service, plus its preview copies	`DATABASE_URL`, `SECRET_KEY`

A preview environment clones its service's variables, so a pull request sees the same configuration as the branch it builds.

Injection methods#

When you add a variable you choose how it reaches the container:

Process env — injected as an environment variable.
Env file — written to an env file mounted into the container.
Docker secret — delivered through Docker's secret mechanism, ideal for credentials that must not appear in docker inspect output.

Secrets#

Values marked as secrets are delivered at deploy time and never stored in plain rows — the platform keeps them encrypted and hands them to the container through the vault-lite delivery path. Secrets are not readable back through the dashboard API after creation.

Platform variables: every service can use ${ZENSAILOR_DATA_PATH} (its permanent data directory), ${ZENSAILOR_SERVICE_ID} and ${ZENSAILOR_PROJECT_NAME}. Template variables can declare prompts and persisted defaults — see Templates and Managed Databases.

CLI#

BASH

# List variables for a service (scoped)
zensailor env-var list --service <service-id>

# Set values
zensailor env-var set KEY1=value1 KEY2=value2