Updates Self-hosted

Updating is pulling the release repository, pulling the new images, and recreating the containers. Your data directory and your .env are never touched.

Run the update

scripts/management/truetask-update.sh

The script does four things in order.

1. Prints the version you are on, read from the VERSION file in the repository.
2. Runs git pull --ff-only. The new checkout is what carries the new image tag, because docker-compose.yml pins the release version as its default. It prints the old and new version when they differ.
3. Runs docker compose pull to fetch the new images.
4. Runs docker compose up -d, which recreates only the containers whose image changed, and prints your access URL.

The same thing by hand:

git pull && docker compose pull && docker compose up -d

The pull must fast-forward

git pull --ff-only fails if you have edited a tracked file in the release repository. The script prints git's own output and stops rather than guessing. Stash or revert your change and run it again. Keep your configuration in .env, which is git-ignored, not in edits to the shipped files.

If the directory is not a git checkout at all, the script says so and skips the pull. In that case pin the version yourself by setting TRUETASK_VERSION in .env, or re-clone the repository.

What happens on the way up

PocketBase runs pocketbase migrate up before it starts serving. If a migration fails the container refuses to start, on purpose, so an inconsistent schema never takes traffic. Automatic schema migration is off; only the migration files shipped in the image run.

Nothing else moves. DATA_DIR keeps pointing at the same directory, and the database, uploads, logs and MCP config in it are reused as they are.

Check the version you are on

Settings > Site > Health shows three numbers at the top: how many of the three checked services are up, the Truetask Version, and the PocketBase version under Database. It also lists PocketBase, the API server and the MCP server individually with a Refresh button.

From the command line:

scripts/management/truetask-status.sh

That prints the version, the git checkout, every container's state, a health probe, the size of your data directory, how many backups exist with the newest one's name, and the free disk.

No automatic updates

Truetask never checks for a new version on its own and never contacts an external server about your instance. Updating is always a command you run.

The only scheduled jobs that talk to the Truetask portal are gated to Cloud workspaces and return immediately on a self-hosted instance. The daily license job runs locally: it reads the key already stored in your database and sends mail to your own admins. See Network policy for everything else that could leave the box, and what it takes to allow it.

Updates and your license

Your license is perpetual, but new versions are only included until the date on the key. Settings > Site > License shows it as Updates included until.

Past that date the instance keeps running exactly as it is. Pulling a newer image is what stops being covered. License covers the renewal reminder and the Renew Updates flow.

Rolling back

There is no rollback command, and downgrading an image is not safe on its own. The container only ever runs migrations forward, so an older image can meet a newer schema and refuse to start.

To go back to an earlier version, restore the state that matched it:

1. Stop the stack with scripts/management/truetask-stop.sh.
2. Restore the pb_data directory from a backup taken on the old version. Backups has the procedure.
3. Check out the old release tag in the repository, or pin TRUETASK_VERSION in .env to the old tag.
4. Start it again with scripts/management/truetask-start.sh.

Back up before you update

Take a backup first, every time. It costs a minute and it is the only rollback you have.

Related

• Backups
• Install
• License
• Audit, sessions and logs