This page lists what the repository actually states about the host. Where a number is not in the source, this page says so rather than guessing: an administrator needs to know which limits the product enforces and which are yours to choose.
| Requirement | What the repository states |
|---|---|
| Linux host | The Installer computes the deployment's memory limits from /proc/meminfo. If that file is unreadable it reports the host as unsupported — "this host is not the Linux VM the limits describe" — and emits no memory limits at all. |
| Docker Engine | Required. The Installer drives the host's Docker daemon through a mounted Docker socket. |
| Docker Compose v2 plugin | Required on the host's Docker CLI. The deployment engine shells out to docker compose for every action. The Installer's own image installs docker-cli and docker-cli-compose from Alpine, and the image also supplies nsenter for the host-migration feature. |
| Compose 2.19.1 or newer | The shared network design assumes newer Compose semantics: "Compose 2.19.1+ rejects a network that exists without its own project labels". |
| Docker socket reachable | Standard rootful hosts use /var/run/docker.sock. Rootless hosts point DOCKER_SOCK at the rootless socket, for example /run/user/1000/docker.sock (id -u gives the UID). |
Started by docker compose | The self-update feature reads the compose project name, working directory and compose-file path from the running container's labels. A container started any other way "carries no compose project labels, so its install directory cannot be found". |
systemd and bash | Needed only for the bare-metal host migration. The migration script refuses to run without systemctl: "ERROR: not a systemd host." |
| CPU, RAM and disk minimums | Not stated in the repository. No minimum core count, memory figure or disk figure appears in README.md, docker-compose.yml, the Dockerfile or the pipelines. |
| Required kernel settings | Not stated in the repository. No sysctl, ulimit or kernel-module requirement is documented. |
| Node.js on the host | Not needed for the container path. The Installer runs from images. README.md lists Node.js >= 18 and npm for the source path (running the backend and frontend from a checkout). |
The Installer does not carry fixed memory numbers for the DataMind OS services. It reads the host's
total memory, picks a host class from the published environment schema, and computes a limit and a
reservation for each service. The budget rules below are in the Installer's code; the host-class
thresholds themselves live in the published env.schema.json, not in the Installer repository.
| Rule | Default |
|---|---|
| Host memory reserved for the OS, before the budget | host_reserved_pct — 0 |
| Reservation budget as a share of available memory | reservation_budget_pct — 75 |
| Reservation as a share of each computed limit | default_reservation_ratio — 0.75 |
| Tolerance before reservations are scaled down | 2% over budget |
| Floor for a scaled-down reservation | 16 MB |
| Limits used if the host class is unknown | none — the whole computation is reported as unavailable |
The result is written into the deployment .env as a managed block
(# >>> unistream memory limits (generated by delamain; do not edit) >>>) and rewritten on every
environment generation. Hand-edited values are kept and marked as not recalculated.
The managed block is also how POST /api/deployment/deploy refuses to start the stack on a host
whose memory limits cannot be computed: the request fails with
Memory limits could not be computed: <reason> instead of deploying an unsized stack.
The Installer and the host's Docker daemon must reach the following. All Installer-side HTTP calls carry a 60-second timeout.
| Destination | Used for |
|---|---|
https://login.microsoftonline.com/<AZURE_TENANT_ID>/oauth2/v2.0/token | Azure AD client-credentials token, the basis of every registry and storage call |
https://unistream.azurecr.io/oauth2/exchange and /oauth2/token | Exchanging the Azure AD token for a registry refresh token and a scoped access token |
https://unistream.azurecr.io/v2/... | Repository catalogue, tag listing, manifest and digest lookups |
https://unistream.blob.core.windows.net/docker/env.schema.json | The DataMind OS environment schema, which seeds the configuration and the service catalog |
https://unistream.blob.core.windows.net/docker/docker-compose.yml | The DataMind OS stack's compose file |
https://unistream.blob.core.windows.net/delamain/docker-compose.yml | The Installer's own compose file, fetched during self-update |
https://auth.docker.io/token | Anonymous Docker Hub tokens, for any image in the stack that is not served from the registry cache |
| The registries named in the DataMind OS compose file | The Docker daemon's own image pulls (layers are fetched by the daemon, not by the Installer) |
Two details worth knowing when you write firewall rules:
unistream.azurecr.io/docker-hub/... are rewritten to their Docker Hub
coordinates before the pull, while the token still comes from Azure Container Registry. Both
unistream.azurecr.io and Docker Hub must therefore be reachable.BLOB_ARTIFACT_VARIANT switches between the production pair and the dev pair;
it is deliberately independent of NEST_NODE_ENV, and the example file warns: "never set this on
a client host".| Requirement | Detail |
|---|---|
| Azure tenant and application IDs | Baked into the Installer's compose file: AZURE_TENANT_ID and AZURE_CLIENT_ID. They are supplied by the product, not chosen by the operator. |
| Azure client secret | You supply it. It is not an environment variable: an administrator enters it in the Installer UI, which stores it encrypted in the Installer's own database (PUT /api/system-secrets/azure). The Installer uses it to authenticate to Azure Container Registry and to Blob Storage. |
| Azure role for that application | The secret must belong to an application that can pull from unistream.azurecr.io and read the blob containers. The repository does not state which roles to assign. |
| Host-level registry credentials for the Installer's own images | Not documented in the repository. docker compose pull/up of the Installer's own unistream.azurecr.io/delamain:<tag> image and of its PostgreSQL image is done by Docker Compose on the host, which needs its own credentials for the registry. No docker login step, credential helper or documentation of it exists in the source. |
Only relevant if you build the image yourself or run the project from source.
| Tool | Version | Where it comes from |
|---|---|---|
| Node.js | 22 for the image build and CI; >= 18 for the source path | Dockerfile base image node:22-alpine; pr-validation.yml uses UseNode@1 with 22.x; README.md states >= 18 |
| pnpm | 11.6.0 | Root package.json "packageManager": "pnpm@11.6.0"; pr-validation.yml runs corepack prepare pnpm@11.6.0 --activate |
| TypeScript | ^5.4.5 (backend), ^5.6.3 (shared package) | apps/backend/package.json, MONOREPO_MIGRATION_PLAN.md |
| PostgreSQL | 16 | docker-compose.yml image tag |
| Port | Who uses it | Published on the host? |
|---|---|---|
NEST_PORT, default 8000 | The Installer's own API and UI | Yes: '${NEST_PORT:-8000}:${NEST_PORT:-8000}' |
5432 | The Installer's PostgreSQL | No. The production compose file only exposes it on the internal network. The development compose file publishes ${POSTGRES_PORT:-5432} — do not use that file on a customer host. |
| The DataMind OS stack's own ports | The product | Not stated in this repository; they belong to the published stack compose file. |
Next: Prepare the host.