Configuration
A fresh install needs one value, your license key. This page covers the rest: the master key Trinium makes for you, the built-in admin account, and the four ways to split Trinium across servers.
Configure
Open .env (the install page's step 2 wrote it). There is one thing to fill in:
| Setting | What to put |
|---|---|
LICENSE_KEY | Your license key, all on one line. |
Everything else in that file ships ready to use. TRINIUM_VERSION is already set to the version the page installed, and is also how you upgrade later.
Your master key: Trinium makes one for you
You do not have to create anything. On its first start Trinium generates a master key and writes it to secrets/master.key, beside your compose.yaml, and says so in the log.
If you would rather supply your own, because you are joining this server to an existing Trinium install or because your keys come from somewhere central, write it into that exact file before the first start and Trinium will use it instead of generating one. The folder belongs to uid 10001 (step 2), so the file goes in with sudo tee and is then handed over:
printf '%s\n' 'your-existing-master-key' | sudo tee secrets/master.key > /dev/null sudo chown 10001:10001 secrets/master.key && sudo chmod 600 secrets/master.key
If you are running against your own PostgreSQL (the core, controller or worker profile), the connection string goes in the same folder, as secrets/db.key, the same way: printf '%s' 'postgres://user:pass@host:5432/trinium' | sudo tee secrets/db.key > /dev/null, then sudo chown 10001:10001 secrets/db.key && sudo chmod 600 secrets/db.key. That is the only place it goes; there is no .env setting for it. The default trinium profile bundles its own database and needs no such file.
Three things worth reading twice
Back up your master key, somewhere off this server. It encrypts the database credentials, API keys and cloud secrets you save inside Trinium, and it encrypts your backups. Lose it and those credentials are unreadable by anyone, including us, and only a portable backup can still be restored (see Backups).
The file is:
secrets/master.key
…in the folder holding your compose.yaml. Copy the file itself, however you normally move files off this machine. Trinium shows a reminder in the app until an administrator confirms this is done.
If you ever move this instance to a new server, put that file back at the same path before the first start there. Trinium will refuse to start against a database it did not encrypt rather than generate a second key over your data, so a forgotten key is a clear message and not a silent loss.
Writing into secrets/ needs elevation, and a plain sudo will not do it. The folder belongs to uid 10001, so > secrets/master.key fails with Permission denied, and sudo printf … > secrets/master.key fails the same way, because your shell performs the redirect before sudo runs. Use tee, then give the file to uid 10001 as above: a file you wrote at mode 600 as yourself is one Trinium cannot read, and it refuses to start saying so.
Sign in as admin / admin, then change it immediately. A fresh install seeds the built-in admin account with the password admin, so you can get straight in. That account is the super admin and it is the one account that can never be locked out of this instance, even by a misconfigured single sign-on provider. It is also the first thing anyone scanning the internet will try. Change its password under your profile before you do anything else, and create a normal account for your own day-to-day use.
ADMIN_DEFAULT_PASS is a safety net, not a setup step. Leave it blank. You only ever need it if you are locked out: put a password in it, restart, and the admin account's password is reset to that value on every start while it has a value, which is the guaranteed way back in. Blank it again and restart once you are back, so the live password is no longer sitting in a plaintext file.
Choose what runs
.env ships with COMPOSE_PROFILES=trinium, which runs everything: the database and Trinium. If that is what you want, skip to the next section.
COMPOSE_PROFILES | What runs | Where the connection string goes |
|---|---|---|
trinium | Database + Trinium | Nowhere: it brings its own |
core | Trinium only (web + engine, one process) | secrets/db.key |
controller | The web tier only. Runs no pipelines | secrets/db.key |
worker | The execution tier only. Serves no web | secrets/db.key |
Every profile except trinium reads secrets/db.key: one file, beside the master key, pointed at your Postgres (14 or newer, an empty database; Trinium creates its own tables on first start). See Configure for the one command that writes it. Forget it and Trinium refuses to start, naming the file it went looking for.
There is deliberately no .env setting for the connection string. It holds a database password, and anything in .env is handed to the container as an environment variable, where docker inspect, /proc/<pid>/environ and any support bundle can read it back out. The file is not a stronger permission boundary, but it keeps the password out of everything that routinely captures an environment.
Splitting web from execution on one server means running both: COMPOSE_PROFILES=controller,worker. A heavy run then cannot disturb the UI. Both read the same secrets/db.key, because only the trinium profile bundles a database.
The controller sets the database up: it creates the tables and the master key on first start, and applies the changes an upgrade brings. The worker only reads them, so on a first start it may stop once, saying what it is waiting for, and start by itself as soon as the controller has.