Environment variables

The DataMind Installer reads two different environment files, and confusing them is the most common configuration mistake. Keep them apart:

• The installer's own environment file. This is the .env next to the installer's docker-compose.yml on the host. Docker Compose reads it for variable interpolation and passes it into the installer's own containers. This page documents it fully.
• The deployed stack's environment file. The installer generates this file (at deployment/.env inside its container) from a published schema and writes it for the DataMind OS services it deploys. Its variable list is defined outside this repository; see The deployed stack's environment file.

Installer runtime variables

Every variable below is present in .env.example, injected by the compose file, or read directly by the backend. Default is the value shipped in .env.example or the fallback in code.

Image and version

VERSION is the single knob for which build of the DataMind Installer runs. The compose file defaults it to prod-latest when unset, while .env.example ships latest; pin a concrete tag for production hosts so a restart cannot silently move the running build.

DELAMAIN_IMAGE is derived from the same tag and is used whenever the installer has to start a sibling container: the self-update helper (a detached container built from the new image) and the host-migration helper. DELAMAIN_CONTAINER_NAME must match the container the installer actually runs in, because version reporting and self-update resolve the running build by inspecting that container, not by reading the tag.

BLOB_ARTIFACT_VARIANT selects which published artifact pair the installer downloads — the production schema and compose, or the dev pair. It is deliberately independent of NEST_NODE_ENV, so raising log verbosity can never switch a host onto dev artifacts. Leave it empty on any client host.

Docker access

DOCKER_SOCK is the host path of the Docker socket bind-mounted into the backend. The deploy engine drives docker compose through this socket, so access to it is equivalent to host root. Standard (rootful) Docker uses /var/run/docker.sock. For rootless Docker, point it at the rootless socket, for example /run/user/1000/docker.sock (find the UID with id -u).

Server and API

NEST_PORT controls the port the backend listens on and the host port compose publishes; both come from the same variable, so changing it moves the UI and API together. In the default setup the installer serves the SPA and the API from the same origin, which is why NEST_ORIGINS is described as irrelevant unless you repoint the UI at the backend from a different origin.

NEST_NODE_ENV selects log verbosity: prod restricts the logger to error, warn, log and fatal; dev adds debug and verbose. It also gates production cookie behaviour. SWAGGER_ENABLED serves the OpenAPI UI at /api/docs.

Database

POSTGRES_HOST and POSTGRES_PORT are injected by the compose file (the postgres service name on the compose network) rather than set in .env, because the backend and the init job must reach the database over the compose network. POSTGRES_USER and POSTGRES_DATABASE_NAME are interpolated into both the Postgres container and the backend, so the two stay in step. The password is never in .env — see Secrets.

Sessions

JWT_ACCESS_EXPIRY and JWT_REFRESH_EXPIRY set token lifetimes. Both are read once when the auth service starts, so a change applies to tokens issued after the next restart. JWT_SECRET is not an .env value: it is generated into the secrets volume on first boot and loaded at runtime.

Azure integration

AZURE_TENANT_ID and AZURE_CLIENT_ID are the only two variables the backend validates as mandatory: the application throws on startup if either is empty. They identify the Azure AD application used to authenticate to the container registry and blob storage. The matching client secret is stored encrypted in the database, not in .env.

Deployment paths and mounts

DEPLOYMENT_DIR is the container path of the directory that holds the deployed stack's compose file and generated .env; compose bind-mounts the host ./deployment there, so the files survive a container recreate. TMPDIR must be bind-mounted at the same path host and container — the self-update helper deliberately relies on that identity to receive staged files. MIGRATE_HOST_DIR and MIGRATE_HOST_SCRIPT_PATH locate the host-migration script, and JENKINS_HOME exposes the existing Jenkins configuration read-only for the migration-time import.

Variables the installer generates

These four values never appear in .env. They are generated on first boot and stored in the delamain_secrets volume:

• JWT_SECRET — a 64-byte hex value, written to jwt.secret, injected as JWT_SECRET.
• NEST_ENCR_KEY — a 32-byte base64 value, written to encr.key, injected as NEST_ENCR_KEY.
• POSTGRES_PASS — a random hex value written to pg.pass by the Postgres container itself, then read by the backend.
• CURATO_SERVICE_TOKEN — a 48-character alphanumeric value, written to curato.token, injected as CURATO_SERVICE_TOKEN, and additionally written into the deployed stack's .env.

Their creation, storage and rotation are covered in Secrets and Rotating values.

The deployed stack's environment file

The installer generates a second environment file for the DataMind OS services it deploys. It is written from the rows stored in the installer's own database, which are seeded from a published schema template (.env.unified.template, downloaded from blob storage). The concrete variable names in that file — PLATFORM_URL, the per-service memory and port variables, and the rest — are defined by that published schema and are not enumerated in this repository. This page therefore does not list them. Behaviour that is defined in this repository:

• Editable in the UI. The Advanced configuration screen lets an administrator edit these rows; the value is stored in the database and the file is rewritten on every generation. Sensitive rows are masked for non-administrators.
• CURATO_SERVICE_TOKEN is appended to the file from the generated token, not from a database row, so no operator edit can drift it away from the value the installer compares against.
• <USER> substitution. Any value containing the literal <USER> is replaced with the stored VM user when the file is written.
• ${PLATFORM_URL} interpolation. Values that reference ${PLATFORM_URL} are placed after the plain values so Docker Compose resolves them in read order.
• Computed memory rows. A generated block between marker comments holds per-service memory limits computed from the host's total memory and the schema's class rules. It is rewritten on every generation and carries a header naming the host and class.
• Derived rows. A row whose generator is ed25519-pub:<CODE> is the Ed25519 public key of the seed held by another row; it is recomputed whenever that seed changes.

For the service names and groups these rows attach to, see Service catalog.