The DataMind Installer ships no command, script or documented procedure for moving a deployment to a new host. The two migrations the product actually automates are the legacy bare-metal retirement and its own self-update; neither relocates a deployment. Everything on this page is operator guidance, not verified product behaviour. Treat it as a checklist to reason from, and back up before you touch anything.
If you need to move a deployment, you are really moving two independent Docker Compose projects and their data:
delamain, containers named delamain-*), andunistream).They share one Docker network and nothing else.
Copying these preserves identity: secrets keep signing and decrypting, and data keeps being the same data. Get the engine matches wrong and the platform starts from a different (or empty) dataset.
| Item | Where it lives | Why it must travel |
|---|---|---|
| Installer deployment directory | host ./deployment (bind-mounted at /usr/src/app/deployment) | Holds the downloaded docker-compose.yml and the generated .env the deploy engine reads. |
| Installer secrets volume | Docker volume delamain_secrets (mounted at /usr/src/app/secrets) | Holds jwt.secret, encr.key, pg.pass and curato.token. |
| Installer database volume | Docker volume pgdata (PostgreSQL data) | The configuration rows, users, deployment audit trail and system secrets — including the encrypted Azure client secret. |
Installer root .env | delamain/.env next to the compose file | Compose interpolation: VERSION, NEST_PORT, DOCKER_SOCK, database name and user. |
| DataMind OS project | Compose project unistream working directory and its volumes | The platform's own data (PostgreSQL, ClickHouse, object storage, Kettle repository, and the rest). |
| Optional compose override | deployment/docker-compose.override.yml | User-managed; if you have one, it is never written by the Installer and never backed up by it. |
encr.key is the one item you cannot substitute. The Installer encrypts stored system secrets (the Azure client secret) with this key; if it changes, decryption fails and the UI reports "Stored Azure client secret could not be decrypted (encryption key changed?). Re-enter it." — after which you must re-enter the secret by hand. Keep encr.key (and jwt.secret, and pg.pass) exactly as they were on the old host.
The freshest, most consistent way to copy a database volume is with the container stopped, or with a logical dump taken while the source is quiesced. Copying a live PostgreSQL data directory risks a torn copy.
Some things are host-specific and must be rebuilt on the destination — they are not data, they are plumbing.
The shared Docker network. It is declared external by both compose files and owned by neither, so it is never created for you. Create it once on the new host before the first docker compose up:
docker network create unistream
Without it, Compose fails with network unistream declared as external, but could not be found.
The compose bind-mount paths. The Installer expects the deployment directory, /var/tmp/delamain (its TMPDIR, which the self-update helper relies on being mounted at the same path on host and container), and /var/opt/delamain-style script paths to exist. Recreate the same directory layout the old host used, or adjust .env accordingly.
The Docker socket. Standard (rootful) installs use /var/run/docker.sock; a rootless engine needs DOCKER_SOCK pointed at the rootless socket (for example /run/user/1000/docker.sock). Set this on the new host before starting.
The old systemd units, if the destination ever ran the bare-metal platform. The new stack assumes the host is free of the legacy services. If the destination is itself an old install, run the legacy migration there first.
Registry access. The new host must be able to authenticate to the image registry and the artifact blob storage. Re-enter or carry over the Azure client secret, and verify it on the new host.
This sequence keeps a working copy on the old host until the new one is proven.
VERSION in use and the digest the running Installer reports, so the new host can start from the same build.delamain_secrets and pgdata volumes, the root .env, and the DataMind OS project and volumes.unistream network, and recreate the directory layout..env, and the secret and data volumes in place with the same container paths they had before.Do not run the old and new hosts against the same data volumes, ports, or network simultaneously. Two engines on one PostgreSQL data directory corrupts it, and this is exactly the hazard the legacy migration script neutralises on a single host.