Updating Tico

The server

Click Update now on the new-version notice. Tico takes a database snapshot, then updates the server and its updater. The server switches in about 20 seconds, and computers with automatic updates enabled follow when idle, usually within a few minutes. Pinned or offline computers stay on their current release until you update or reconnect them. If the server doesn’t come back healthy, it rolls back and restores the snapshot.

A browser tab left open through an update shows New version · Reload. It never reloads on its own.

Tico checks for new releases every 6 hours. To check now, open Settings → Health → Version and click Check for updates.

Manual updates and pinned installs

docker compose pull only refreshes the configured tag. If TICO_TAG pins an older release, pulling it leaves you on that release. To upgrade, choose a published target from GitHub Releases and run its installer from your existing install directory (/opt/tico on Linux, ~/tico on a Mac):

curl -fsSL https://github.com/ticoteam/tico/releases/download/vX.Y.Z/install.sh -o install.sh
sh install.sh --version vX.Y.Z --dir "$PWD"

Replace vX.Y.Z with the target release. For a local install, add --local --owner-email you@example.com, using your existing owner email. The installer verifies and refreshes the release bundle, changes TICO_TAG, and keeps your other settings and data. Use Update now for the health check and automatic rollback described above.

Update order

Update the server first, then the computers. Old computers may remain connected while updates roll out. In Settings → Computers and Settings → Health, check each computer’s installed and wanted release and last update error. A computer older than the server’s supported minimum pauses its bots until updated; its queued work waits.

Linux and Docker computers

Computers added with the Add computer command follow your server’s release automatically when idle. A pinned computer shows Needs update (pinned). To let it follow again, remove TICO_RUNNER_PINNED=1 from that computer’s .env, then run docker compose -f runner.compose.yaml up -d in its install directory.

For a manual update, use the matching server release’s installer with the Settings → Computers → Add computer command on that computer, keeping its existing install directory and runner-home volume. A computer added with an older plain docker run command has no updater sidecar; the installer migrates it to Compose and keeps its model logins, bot repos and enrollment. See the full Updates guide for pinning and legacy installations.

Macs and Linux checkouts

A supervised runner follows the server’s release when idle. If it is pinned, has local changes, or lacks a supervisor, Health says what needs fixing. For a manual update, update that computer’s Tico checkout to the server’s release and re-run the commands from Add computer. Preserve its existing config and model logins. The Updates guide covers checkout pinning, background jobs and recovery.

Employee and Tico change feeds

Each employee template has its own changelog and JSON Feed. Read the default instructions, settings and changed files for that role, with links to the exact source commits.

• Default employee settings — all templates, or choose a single employee’s feed from its changelog page.
• Tico updates — changelog, MCP and tool source changes.
• Tico MCP and tool changes only.

The feeds refresh daily from public source history, without AI calls. Scheduled refreshes can be delayed; each feed records its actual source revision. Source changes can precede a release. Use GitHub Releases to check what has shipped and compare with the version installed on your team.

Subscribe to updates — Coming soon

A planned Subscribe to updates setting on each bot lets you choose which changes it receives. Select Default employee settings for its employee template, Tico updates for product and MCP/tool changes, both, or neither. You can change the selection or unsubscribe later.

Updates should give the bot a short summary and a source or version link so it can decide whether its instructions, settings or tools need adapting. Subscribing informs the bot; applying an employee-template update remains a separate action that preserves your custom instructions and settings.

Subscriptions and wake frequency are separate choices. The planned Token saver and Performance wake presets control how readily a bot starts a turn. Update notifications should be deduplicated and batched through that policy, with no model turn when nothing changed.