Logs

The DataMind Installer writes almost everything to standard output, so container logs are the primary source. A structured audit trail and a persisted job-event history add the rest.

Know where each log lives

Container names are fixed in the Installer's compose file, so docker logs by name is the reliable way to reach them, whatever the compose project is called.

The one-shot delamain-backend-init service runs typeorm migration:run and exits; its log is the record of the schema migrations that ran on the last deploy or boot.

Read logs with docker

By container name:

docker logs --tail 200 -f delamain-backend
docker logs --tail 200 delamain-postgres
docker logs --tail 200 delamain-backend-init
docker logs --tail 200 delamain-self-updater

By compose service, from the directory that holds the Installer's docker-compose.yml. The backend compose service is named backend:

docker compose logs -f backend
docker compose logs -f postgres

The DataMind OS stack is its own compose project. Its containers carry the label com.docker.compose.project=unistream:

docker ps --filter label=com.docker.compose.project=unistream
docker compose -p unistream logs --tail 200

Follow an installation or update live

In the interface

The Installer's interface shows live output while a job runs: the raw docker compose output for the job, and each service's container log on its own panel. Under the hood these are server-sent event (SSE) endpoints:

The job stream replays from the beginning, or from ?after=<seq> or a Last-Event-ID header, so a reconnecting client does not lose output. It emits a heartbeat every 15 seconds.

curl -N "http://localhost:${NEST_PORT:-8000}/api/deployment/jobs/<jobId>/logs?after=0" \
  -H "Authorization: Bearer <token>"

curl -N "http://localhost:${NEST_PORT:-8000}/api/deployment/logs/clickhouse-server?tail=200" \
  -H "Authorization: Bearer <token>"

During an update

An update replaces the backend, so the API stops answering mid-way. Follow it on the host instead:

docker logs -f delamain-self-updater

The helper's log is the step-by-step record — pre-flight result, compose backup, install of the new compose file, the switch, and either ok, rolled-back or failed. See Update the DataMind Installer.

Read the deployment log stream and download it

For a plain, aggregated view of the DataMind OS containers over a time window, the Installer exposes a dedicated log controller. Both endpoints require the admin role.

The download returns text/plain as logs-<ISO timestamp>.txt, with every line prefixed by the container name it came from:

curl -s -OJ "http://localhost:${NEST_PORT:-8000}/api/deployment-log/download?since=2026-09-01T00:00:00Z" \
  -H "Authorization: Bearer <token>"

Read the audit trail

Every action the Installer takes is recorded in the database table deployment_actions, with its status, exit code, acting user and a free-text detail.

Statuses are started, completed and failed. Read the newest first:

curl -s "http://localhost:${NEST_PORT:-8000}/api/deployment/actions?limit=50" \
  -H "Authorization: Bearer <token>"

The acting user is resolved from the request; a call from the DataMind OS control plane is attributed to the user id it forwards, and falls back to curato.

Understand retention and rotation

Collect this before contacting support

1. Container state: docker ps -a and, from the Installer directory, docker compose ps.
2. Recent output of all four containers:
   bashCopy

   for c in delamain-backend delamain-postgres delamain-backend-init delamain-self-updater; do
     echo "===== $c ====="; docker logs --tail 500 "$c" 2>&1
   done

3. The running build and the last update outcome: GET /api/version and GET /api/system/self-update-check.
4. The deployment status: GET /api/deployment/status.
5. The audit trail: GET /api/deployment/actions?limit=50.
6. The aggregated log file: GET /api/deployment-log/download?since=<ISO>.
7. The update status file from the host: <work-dir>/.self-update-status.