Upgrade

Standard upgrade (registry path)

If you’re using the docker-compose.prod.yml override (pull images from GHCR rather than build locally):

# 1. Pin the new version
sed -i 's/^PIPEBASE_VERSION=.*/PIPEBASE_VERSION=v0.5.0/' .env

# 2. Pull new images + restart with rolling cutover
docker compose -f docker-compose.yml -f docker-compose.prod.yml pull
docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d

Wall-clock: ~30 sec (pull) + ~10 sec (restart). User-visible impact: short blip on /api/* while containers swap.

Coolify-managed upgrade (build path)

If you’re on the Hetzner Coolify deploy: just push to main.

git pull origin main
git push origin main          # triggers Coolify webhook → rebuild

Wall-clock: ~3-5 min for a runtime + designer rebuild.

Rollback

Pin to a previous version:

sed -i 's/^PIPEBASE_VERSION=.*/PIPEBASE_VERSION=v0.4.1/' .env
docker compose -f docker-compose.yml -f docker-compose.prod.yml pull
docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d

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. We tag those releases with a BREAKING label in the GitHub Release notes.

Pre-upgrade checklist (production)

For non-trivial bumps, before pulling:

1. Backup volumes — see Backup
2. Read the release notes at https://github.com/jobu279/ipaas/releases
3. Pin a specific version in .env, not :latest — :latest moves under your feet
4. Test on a staging environment first if you have one configured

Image tag strategy

• :latest — moves to the most recent stable release. Convenient for dev / non-production.
• :vX.Y.Z — immutable, exact release. Use this in production.
• :X.Y / :X — float on the minor / major track. Useful for “auto-update inside this major”

:edge is built from every push to main and explicitly unstable — never use it on a production host.