System requirements
One Linux server with Docker runs everything. This is the full list, and what changes when Trinium runs on more than one server.
| Operating system | Any Linux with Docker. macOS and Windows work for evaluation. |
| CPU architecture | x86_64 / amd64. Arm builds are not published yet; ask us if you need one. |
| Docker | Docker Engine 25 or newer, with Compose v2.20 or newer (docker compose, not docker-compose). Check with docker compose version. |
| Memory | 32 GB recommended, on every profile. On the default trinium profile the database runs on this machine too. It is allowed 2 GB, and Trinium takes 80% of what is left; on core (your own database) Trinium takes 80% of the machine. 32 GB is the size the engine is certified at: ten consecutive 10,000,000-row runs of a 24-node pipeline. A smaller machine also runs, with a smaller memory budget, but has not been tested. Pipelines that sort, join or aggregate large tables benefit from more: Trinium spills to disk rather than failing, but disk is slower than RAM. Settings → General shows exactly what this machine gave it. |
| Disk | 100 GB. A single large run can spill tens of gigabytes to the scratch volume (the certified 10,000,000-row pipeline writes ~23 GB of spill) and it is reclaimed when the run ends; run history and uploaded files grow on top of that. |
| PostgreSQL | Only if you bring your own database (every profile except trinium, which brings its own): PostgreSQL 14 or newer, and an empty database. Trinium creates its tables on first start. |
| Network | Outbound HTTPS to pull the images. After that Trinium needs only whatever your pipelines connect to. Inbound, open just the one port you set as TRINIUM_HTTP_PORT. |
| Credentials | A registry username + token, and a license key. Both arrive by email when you start a trial or buy a license. |
One Trinium instance per server. Trinium sizes its memory budget from the machine it can see, once, at startup. Two instances on one host would each claim most of that same memory. To run more pipelines at once, add servers: see Scaling out.
There is nothing to set. Trinium measures this machine, subtracts what the bundled database is allowed to take when it shares it, and keeps 80% of the rest. You can see the whole sum in the app under Settings → General → Engine memory, and it is printed in the log at startup. TRINIUM_MEMORY_BUDGET_MB exists only to override it.
Running on Docker Desktop (Windows or macOS)
Fine for evaluation, and there is one thing to know: your containers run inside a virtual machine, so the memory Trinium reports is the VM's, not your computer's. WSL2 takes 50% of host RAM by default, so on a 64 GB machine Trinium sees 32 GB. It says so on the Engine memory card when it detects this.
Raising TRINIUM_MEMORY_BUDGET_MB does not help here, and makes things worse: a budget larger than the VM stops Trinium spilling to disk and lets the kernel kill it instead. Give the VM more memory first:
Windows (WSL2 backend): put this in %UserProfile%\.wslconfig, creating the file if it is not there, then run wsl --shutdown and start Docker Desktop again.
[wsl2] memory=24GB
macOS, or Windows on the Hyper-V backend: Docker Desktop → Settings → Resources.
Reading from a Windows network share
The Network Share nodes read and write files on a Windows file server, a NAS, or anything else that speaks SMB 2 or 3, and a File Action wired to them copies or moves those files. Three things decide whether a connection works:
- The port. The server that runs pipelines must reach the file server on TCP port 445. With a separate controller and worker, that is the worker. Check it from that server before you add the connection, for example with
nc -vz fileserver 445. - The account. Trinium signs in with a user name and password: a local account on the file server, or a domain account with its domain. The account needs to read the folders a pipeline reads, and to write and delete where a pipeline writes, moves or deletes files. A domain that has turned NTLM off, so that only Kerberos is allowed, cannot be reached yet.
- Encryption. Every session is signed, as Windows signs it. A share that requires encryption is not supported yet, and the connection test says so by name.
A path copied from File Explorer (\\fileserver\share\folder) can be pasted into a node's folder field when it names the connection's own server and share.
Choosing an install option
The install page offers three ways to run Trinium. All three run the same images. They differ in where the database lives and whether pipelines run on the server that serves the web interface.
| Option | What runs where | When it fits |
|---|---|---|
| Demo | One server runs Trinium and its own PostgreSQL (COMPOSE_PROFILES=trinium). | A trial, or a first look. |
| Production (minimum) | One server runs Trinium. The database is a PostgreSQL server of yours, such as Amazon RDS (core). | Production on one server, with the database looked after like your other databases. |
| Production (recommended) | A smaller server serves the web interface, your schedules and backups (controller). A larger one runs every pipeline (worker). Both use your PostgreSQL. | Production where a long run should never slow the interface down. |
The memory and disk figures above are for the server that runs pipelines. In the recommended option that is the worker, and the controller can be smaller.
Sizing as you grow
- One pipeline at a time per server, at full speed. A server runs one production pipeline at a time, and every node in it runs at once, so one pipeline uses the whole machine. Beside it, each server runs one Test run in a small slice of memory of its own, so building never waits behind a long load.
- Every run records what it needed. A run's details show its Peak memory, how much it Spilled to disk, and how long it Waited in queue. Peak memory near the budget, or a lot of spill, says a bigger server would help. Runs waiting in the queue say another server would.
- More servers share one PostgreSQL and one file store. Before adding a second server, switch Settings → File storage to S3 or Azure Blob. Scaling out has the steps.
- Memory is measured, not configured. Trinium measures the machine when it starts, subtracts what the bundled database is allowed, and keeps 80% of the rest. Settings → General → Engine memory shows the sum.