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.

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 — keep the client on the same release as core.

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.
The web client’s files are swapped atomically; browsers pick the new build on their next load.
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.

Warning

Migrations are not automatically reverted — if the release you’re leaving introduced schema changes, restore the database from the backup taken before the update instead of rolling the schema forward-and-back.

Backups

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