Upgrading

Most VibeXP releases upgrade in place: pull the new image, restart, done. This page lists the exceptions.

Versioning and support

VibeXP publishes one image, ghcr.io/vibexp/vibexp, tagged X.Y.Z per release.

Tag	Points at
X.Y.Z	that exact release, immutable
latest	the highest published version, not the most recent build: a backport patch on an older line never moves it

The bundled docker-compose.yml tracks latest. Pin to X.Y.Z instead if you want upgrades to be a deliberate step:

image: ghcr.io/vibexp/vibexp:0.10.0

Patch releases are supported on the newest minor line only. Now that 0.10.0 has shipped, fixes go to 0.10.x, not 0.9.x. To stay on a supported version, follow the newest minor.

A patch release (0.10.0 to 0.10.1) contains bug fixes and security fixes only. It never adds a database migration and never changes the API, so it is always a straight image bump with no action on your side. Anything that needs a schema or API change ships as a minor release and appears below if it requires action.

Everything below needs action when you upgrade, either before the new image will start or immediately after. Entries are newest first: if you are skipping several releases, work upwards from the version you are on and apply every one in between.

Breaking changes

Bundled Postgres upgraded from 16 to 17 (v0.10.0)

The Postgres image shipped in the combined-image docker-compose.yml moved from pgvector/pgvector:pg16 to pgvector/pgvector:pg17. Postgres data files are not compatible across major versions, so a Postgres 17 image started on a data directory created by Postgres 16 refuses to start. If you run the bundled Postgres with a populated data volume, you must dump-and-restore (or pg_upgrade) the volume once before pulling the new image. Managed / external Postgres is unaffected: the pin only governs the bundled container.

→ Upgrading Postgres to 17

Cookie consent removed, GTM now loads on the container ID alone (v0.10.0)

VITE_GTM_ENABLED no longer exists. Google Tag Manager loads whenever VITE_GTM_ID is set, with no separate on/off flag. If you had a GTM ID set but the flag off, GTM will now load. Unset VITE_GTM_ID before you upgrade if you do not want that.

Remove VITE_GTM_ENABLED from your environment. The backend ignores it, so leaving it in place is harmless but misleading.

The cookie-consent banner is gone too, along with the Consent Mode v2 bootstrap and the login-time auto-grant. A self-hosted deployment should not inherit the maintainer’s compliance model, so consent is now yours to configure inside your own tag container. Consent decisions stored in browsers are evicted on next load, not migrated.

GitHub App configuration moved to per-team settings (v0.9.0)

GitHub App credentials used to be instance-wide: one App in config.yaml, shared by every team. They are now registered per team and stored encrypted in the database. You must delete the top-level github: section from your config.yaml or the backend refuses to start, drop the GITHUB_APP_* / GITHUB_WEBHOOK_* environment variables, and re-register the App on each team that uses the integration.

This does not affect auth.github, the GitHub web-login OAuth client.

→ Migrating to per-team GitHub Apps