Upgrading
Three steps. Your pipelines, history and settings stay where they are, and any database changes apply when the web server starts.
Three steps, and the first one is easy to skip. Don't.
- Paste step 3 of the install page again, in this folder. It overwrites your
compose.yamlwith the current release's, which is what the page always holds. - Change
TRINIUM_VERSIONin.envto the new version (step 2 of the page shows it). Step 1 does not touch.env, so every setting you filled in is safe. - Pull the new images and restart:
docker compose pull docker compose up -d
Why step 1 matters. compose.yaml and the Trinium image are a matched pair. New versions sometimes add things that live in the compose file rather than in the image: a volume, a setting, a resource limit. Upgrading the image while keeping an old compose file starts fine and then behaves subtly differently: most often, temporary working files stop going where they should and start filling up the disk your database is on. Pasting it again takes a second and removes the whole class of problem.
Your data, pipelines and history live in Docker volumes and are untouched. Any database changes the new version needs are applied automatically when the server that serves the web (trinium, core or controller) starts; a worker never changes the database. On more than one server, upgrade the web server first: a worker that starts on the new version before it refuses to start, saying why, until the web server has been upgraded. Take a backup first (see Backups). That advice is not specific to Trinium, but it is still good advice.
Changing license tier or renewing is the same shape: paste the new key into LICENSE_KEY and run docker compose up -d. There is no second image and no migration.