Upgrade

Standard upgrade (build path)

The stack’s images are built from your checkout, so upgrading is git pull followed by docker compose up -d --build.

git pull
docker compose up -d --build

The images build first; then Compose recreates the containers whose image or configuration changed. User-visible impact: a short blip on /api/* while those containers restart.

up skips every service behind a profile you do not name. If you started the multi-broker or db profile, pass the same --profile flags to up, for example docker compose --profile multi-broker up -d --build. Without them the second broker keeps running its old image, while the default broker, built from the same Dockerfile under the same tag, runs the new one.

up pulls the image of an image-only service (Traefik, Kafka and Postgres) only when that tag is not on the host yet. It does not refresh a tag that is already there, such as traefik:v3.6; to get the newest image behind it, pull before up:

docker compose pull pipebase-traefik
docker compose --profile db pull pipebase-postgres   # with the db profile

Coolify-managed upgrade (build path)

Push the newer commit to the branch the Coolify application deploys from (if the application deploys on push, its webhook rebuilds the stack), or press Deploy in the Coolify UI.

Rollback

To roll back, check out the previous commit and run docker compose up -d --build.

git checkout <previous-commit>
docker compose up -d --build

Volume data persists across version changes — no migration is needed to roll back. Exception: if a release introduces a forwards-only schema change to flows.json or _runtimes.json, the rollback target needs to be the version that wrote the format. There are no published releases yet: look for such a change in the upgrade notes in CHANGELOG.md at the root of the repository before you roll back.

Pre-upgrade checklist (production)

For non-trivial bumps, before pulling:

1. Backup volumes — see Backup
2. Read the upgrade notes in CHANGELOG.md at the root of the repository
3. Note the commit you are on (git rev-parse HEAD) so you can roll back to it
4. Test on a staging environment first if you have one configured

Image tags

Of the stack’s images, only the runtime is published (for Pipes), as :latest, :<version> such as 0.7.12, and :sha-<commit>; the other images are built locally with the tags set in docker-compose.yml.