The DataMind Installer owns a small set of files on the host. Knowing which ones it rewrites — and which one it never touches — decides where your local edits survive an update and where they do not.
There are two compose projects. The installer's own compose file starts the installer itself; the deployed stack's compose file describes the DataMind OS services the installer deploys. They are separate files, in separate directories, and they are overwritten at different times.
| Host path (relative to the install directory) | Written by | Rewritten by an update? | Safe for local edits? |
|---|---|---|---|
docker-compose.yml | The published installer compose, downloaded from blob storage | Yes — replaced by self-update; the previous copy is kept as docker-compose.yml.pre-update | No — local edits are lost (the backup is your only copy) |
.env | The operator, copied from .env.example | No — the operator's file is left in place | Yes — this is the installer's own environment; see Environment variables |
deployment/docker-compose.yml | Downloaded from blob storage on every deploy and on boot-time restore | Yes — replaced on every deploy | No |
deployment/.env.unified.template | Downloaded from blob storage (the published schema) | Yes — replaced on every deploy | No |
deployment/.env | Generated from the installer's stored configuration | Yes — rewritten on every generation | No — edit values in the UI, not in this file |
deployment/docker-compose.override.yml | The operator | No — the installer never writes or deletes it; it is merged into compose commands only when present | Yes — this is the supported place for local compose changes |
Everything above deployment/ belongs to the installer; everything inside deployment/ belongs to
the deployed stack.
The installer runs as a compose project whose compose file is published to blob storage on every push to the main branch, so it is the canonical copy of the file that runs the installer itself. During a self-update the helper container:
docker-compose.yml.pre-update;Any local edit to the installer's own docker-compose.yml is overwritten by the next update. The
backup at docker-compose.yml.pre-update is the only surviving copy. If you need to add services or
change mounts, do it in the deployed stack's override file, not in either compose file the installer
overwrites.
The installer's own .env is never rewritten by an update, so values you set there persist.
Inside deployment/ the installer manages three files:
docker-compose.yml — the DataMind OS service definitions. Downloaded fresh and overwritten
whenever a deploy runs and whenever the files are missing at boot..env.unified.template — the published schema. Downloaded alongside the compose file as a
matched pair, so a schema and a compose file from different variants can never be mixed..env — the environment file for the deployed services, generated from the installer's stored
configuration. It is rewritten every time configuration is saved, applied or deployed, and carries
a generated memory-limits block bracketed by marker comments.The override file is the deliberate exception: the installer merges deployment/docker-compose.override.yml
into its compose commands when it exists, but it never creates, modifies or removes it. Put local
compose changes — extra volumes, resource tweaks, additional ports — there.
If any of the three managed files is missing at boot, the installer restores it: the compose file and
the template are re-downloaded, and .env is regenerated. Restoration is skipped until the Azure
client secret has been set, because the downloads authenticate with it.
Beyond the compose backup, a self-update leaves two artefacts on the host:
| Path | Purpose |
|---|---|
docker-compose.yml.pre-update | The compose file as it was before the switch; used for the automated one-shot rollback |
.self-update-status (in the compose project's working directory) | A one-word breadcrumb written by the updater helper — ok, rolled-back or failed — for a human reading the host. The installer does not read it back; it reconciles the outcome by comparing image digests instead |
The updater also stages the newly downloaded compose file under the temp directory
(/var/tmp/delamain/self-update/docker-compose.yml in the default setup). That directory is bind-mounted
at the same path on host and container deliberately: it is the one place the backend can hand a file
to the helper container.
The self-update rollback is deliberately a single attempt with no retry loop and no down-migrations.
If both the switch and the rollback fail, the helper stops and prints the manual recovery commands;
its log remains available with docker logs delamain-self-updater.
The host-migration path writes a few files as side effects of retiring the old bare-metal platform.
They are the migration script itself, copied to the configured MIGRATE_HOST_SCRIPT_PATH
(/opt/delamain/migrate-host.sh by default); a timestamped log under /var/log; backups of any
systemd unit files it moved aside, under /root/disabled-units by default; and a timestamped backup
of /etc/exports before it removes the old export lines. The migration runbook covers these; they are
listed here only so the file inventory is complete.