Network exposure

The DataMind Installer exposes a single HTTP port and serves both its web UI and its API on it. Nothing in the Installer's own compose files terminates TLS or sits behind a proxy. Plan the network accordingly: the Installer belongs on a management network, reachable by administrators only.

Ports the Installer exposes

Service	Published on the host	Contents	Notes
`backend`	`${NEST_PORT:-8000}`	The web UI, the `/api` API, and optionally Swagger at `/api/docs`	The one port administrators reach
`postgres`	Not published	The Installer's private database	`expose: 5432` only — internal to the compose network
`backend-init`	None	One-shot migration container (`migration:run`)	Exits after applying migrations

The UI and API are served from the same origin by design: the backend serves the built front end and mounts the API under /api, so the default configuration needs no CORS allowlist. NEST_ORIGINS only matters if you deliberately point the UI at a backend on another origin.

Swagger/OpenAPI is off in the shipped production environment (SWAGGER_ENABLED=false). If it is turned on, /api/docs is served on the same port and is just as privileged as the UI.

The development stack (docker-compose.dev.yml) also publishes the database as ${POSTGRES_PORT:-5432}:5432. That is a development convenience; do not run the dev stack, or publish the database port, on a production host.

What should reach the Installer, and from where

Management network only. Administrators reach the Installer UI/API over a private management network or a VPN. The port must not be reachable from the public internet.
Not for end users. No DataMind OS application user needs to reach the Installer. They use the DataMind OS product, which is a different deployment on a different port surface.
The DataMind OS stack reaches it internally. The Installer and the DataMind OS stack it deploys both attach to a shared Docker network named unistream, created once out of band:
bash
```
docker network create unistream
```
The Installer joins it under the pinned alias delamain-backend, which is how the DataMind OS side resolves the Installer's internal URL. This traffic never touches the host's published ports.
Protect the login. The Installer has no second factor and no login rate limiting of its own, so if the UI must cross an untrusted network, put MFA and rate limiting in the network layer in front of it.

TLS and the reverse proxy

The Installer repository contains no reverse proxy and no certificate handling. It listens for plain HTTP on NEST_PORT and relies on a TLS-terminating front end if you need HTTPS. If you place one in front, make sure it forwards X-Forwarded-Proto: https, because that header is what makes the Installer mark its session cookies secure.

There is one edge detail in the code worth knowing: on a production host, when a request arrives with an Origin header whose host differs from the request host, the Installer scopes its auth cookies to the registrable domain of the request host. Keep the UI and API on one hostname to avoid depending on that behaviour.

The DataMind OS stack's ports

The ports the deployed DataMind OS stack exposes are not defined in the Installer repository. The Installer downloads that stack's docker-compose.yml from Azure Blob Storage at deploy time and runs it; the published ports for DataMind OS services live in that downloaded file, not here. Inspect the deployment's compose file on the host, or the running containers, to see them — the verification commands below include the deploy directory and the container port mapping.

Verify what is actually listening

Run these on the host. ss shows the host's listening sockets and the owning process; the Docker commands show the container port mappings and the shared network.

bash

# Every listening TCP socket, with the owning process (needs root for process names)
sudo ss -ltnp

# Container port mappings, including the Installer and the deployed stack
docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'

# The shared network the Installer and the deployment both attach to
docker network inspect unistream

# The deployment's compose file and its published ports (installer host path)
grep -n 'ports:' -A2 ./deployment/docker-compose.yml

Expect the Installer to appear with ${NEST_PORT:-8000} published on the host, and PostgreSQL to appear without a published port (internal only). If PostgreSQL shows a host port in production, or if the Installer's port is reachable from outside the management network, fix the exposure before continuing.