Who should have access

The DataMind Installer is the component that installs and manages a DataMind OS deployment on a customer server. It is not an application that end users sign in to. It is an infrastructure control plane, and whoever can sign in to it can act on the whole deployment.

An Installer account is therefore not a "normal" application account. Grant it the way you grant root on the host: to a small number of named system administrators, and to nobody else.

What an Installer account can do

Every action below is a real endpoint in the Installer backend, and every one of them runs against the host through the Docker socket. The role column is the role the endpoint requires.

Action	Endpoint	Role required
Restart, stop, or kill services	`POST /api/deployment/restart`, `/stop`, `/kill`	`admin`
Deploy (pull images, then `docker compose up`)	`POST /api/deployment/deploy`	`admin`
Pull images, or run compose-up on their own	`POST /api/deployment/pull`, `/compose-up`	`admin`
Apply configuration changes (recreate services in dependency tiers)	`POST /api/deployment/apply-config`	`admin`
Cancel a running job	`DELETE /api/deployment/jobs/:jobId`	`admin`
Edit deployment configuration values and regenerate the deployment `.env`	`PATCH /api/configs/values`, `POST /api/configs/generate`	`admin`
Import configuration from a legacy Jenkins `config.xml`	`POST /api/configs/import/jenkins`	`admin`
Set the Azure client secret used to pull images	`PUT /api/system-secrets/azure`	`admin`
Set the VM user for `.env` substitution and run the host migration	`POST /api/migrate/vm-user`, `POST /api/migrate/run-host`	`admin`
Create, disable, delete users and change roles	`POST /api/user/register`, `PATCH /api/user/:id`, `DELETE /api/user/:id`	`admin`
Read the deployment audit trail	`GET /api/deployment/actions`	`admin`
Stream container logs	`GET /api/deployment-log`, `/api/deployment/logs`	`admin` for `/deployment-log`; authentication only for `/deployment/logs`
Update the Installer itself	`POST /api/system/self-update`	authentication only — see below
Read deployment status, service groups, stale services, jobs and update checks	`GET /api/deployment/status`, `/groups`, `/stale-services`, `/jobs`, `/update-check`	authentication only

Warning

Two capabilities are not gated to admin: the self-update endpoint and the read-only deployment endpoints require only a valid login — any active Installer account, including one with the plain user role, can trigger the Installer's own update and can stream aggregated container logs. Do not create user-role accounts for people whom you would not trust with admin.

Why this is host-level privilege

The Installer drives the host's Docker daemon through the mounted Docker socket. Anything that can reach the Docker socket can start a container that mounts the host filesystem as root or joins the host's PID namespace. That makes a composed "restart services" call and a "run host migration" call the same privilege class as shell access on the host.

The migration action goes one step further in the code: it spawns an ephemeral container with --privileged --pid=host and runs the retirement script inside the host's namespaces with nsenter -t 1 -a. It stops and permanently masks the legacy systemd units on the host.

Host privilege and the Docker socket covers the mechanics. What matters for access decisions is the conclusion: an Installer sign-in is equivalent to root on the server. Treat it as such.

Who should hold an account

A small number of named administrators — the same people who hold sudo on the host. Two to four is typical; every extra account is another path to host root.
No shared accounts. Use one named account per administrator. A shared account destroys the attribution in the deployment audit trail, which is the only record of who changed what.
Accounts belong to a real, current employee or contractor with an accountable identity, not to a team, a ticket queue, or a service.

Operating rules

Put an authentication gate in front of the UI. The Installer has no second factor of its own. If administrators reach it over an untrusted network, require MFA at the network layer (a VPN or an authenticating reverse proxy). See Network exposure.
Do not expose the Installer UI to the public internet. It belongs on a management network.
Remove access when a person leaves. Disable the account (isActive = false) and let it be, or delete it; either way their refresh tokens are invalidated at once. See Identity and users.
Keep the count of administrators visible. Review the user list on every access review. The Installer shows all accounts on its User Management screen and lists them through GET /api/user.
Review the audit trail. GET /api/deployment/actions returns every deployment and migration action ever taken, newest first, with the acting user resolved. Read it during incident response and on a schedule.
Protect the deployment secrets. The Azure client secret, the VM user, and the deployment .env are all editable by an admin and all reach the host. An administrator's departure is a rotation event, not just an account event.

What the Installer does not provide

So that you plan the compensating control instead of assuming a feature exists:

No per-deployment scoping. There is one Installer per host and it manages that host's whole DataMind OS deployment. There is no way to give an account authority over part of it.
No second factor inside the product. Authentication is email and password only; no TOTP, no WebAuthn and no SSO/OIDC provider was found in the code.
No login rate limiting. The Installer implements no throttler on the login endpoint, despite the general guidance in the repository. Protect the login with the network-layer gate above.
No approval or four-eyes workflow. An action an admin requests runs immediately.
No built-in session list or "revoke other sessions" screen. Invalidating a user's sessions is done by changing or resetting their password, which revokes all their refresh tokens.