Setup

Updating

Upgrade a Tyto deployment — version pinning, what happens on update, rollbacks and backups.

Releases are shipped as prebuilt images tagged by version; your .env pins the one you run via TYTO_VERSION. Updating is a two-line operation.

Version tags

Every release publishes an exact tag (1.0.10); stable releases additionally update their channel tags:

• 1.0.10 — exact pin. Reproducible, upgrades only when you edit .env. The recommendation when you want to know precisely what runs.
• 1.0 — minor channel. Follows the newest 1.0.x patch on every pull; never crosses into 1.1. Convenient once you’re on a stable line — patch upgrades are always migration-safe within a minor.
• 1 / latest — major channel / newest stable. Both can jump across breaking upgrades on an ordinary pull; avoid them in production.

Pre-releases (1.0.0-beta.2) only ever get their exact tag — channel tags never move to a pre-release.

Channel tags update nothing by themselves: the running stack changes only when you pull and up -d.

In the single-stack bundle the client image follows TYTO_VERSION by default; set CLIENT_VERSION in .env to pin it independently when the two parts release at different paces.

Update

# edit .env: bump TYTO_VERSION to the new release
docker compose pull && docker compose up -d

Running the single-stack bundle? Pass both files, as always:

docker compose -f compose.yaml -f compose.bundle.yaml pull
docker compose -f compose.yaml -f compose.bundle.yaml up -d

Separate client stack: repeat the same two lines in its directory. The client versions independently of core — releases note the core version they need.

What happens on update

• Database migrations run automatically before the API starts serving.
• Background workers restart gracefully — each finishes its current job, then respawns on the new code.
• On the single-stack bundle, the web client’s files are replaced in place — the old build is cleared, then the new one copied over it. There’s a brief window during that copy where a page load can 404; a reload once it finishes serves the new build. A separate client stack instead recreates the whole container from the new image, with no such window.
• Verify with https://<SERVER_DOMAIN>/api/health — {"status":"ok"} — or the admin panel’s health page, which also probes the database, cache, search and realtime hub.

Rollback

Set the previous tag in .env and run the same two lines.

Backups

Back up the database, media and secrets before updating — see Backups & restore for what’s stateful and the exact commands.