Skip to content
Slipwaydocs

Upgrades

Version policy

Section titled “Version policy”

Slipway uses semantic versioning. The control plane, runner and CLI share a version. A runner is compatible with a control plane one minor version older or newer, so you can upgrade the control plane first and roll runners afterwards. Read the changelog before upgrading; breaking changes and required actions are called out there.

Before you start

Section titled “Before you start”
  1. Back up Postgres and confirm you can restore it. Migrations are forward-only.
  2. Confirm the master key backup exists. See Backups.
  3. Read the release notes for the versions between yours and the target. Upgrade one minor version at a time unless the notes say otherwise.
  4. Pick a quiet window: running jobs on runners continue, but the scheduler is briefly unavailable.

Helm

Section titled “Helm”
Terminal window
helm upgrade slipway oci://ghcr.io/slipway-systems/charts/slipway --version <new> -n slipway -f values.yaml

The migration Job runs as a pre-upgrade hook before any new pod starts. Server, scheduler and worker then roll with maxUnavailable: 0, so there is always a ready replica and live log streams drain during the 60-second grace period. Watch it:

Terminal window
kubectl -n slipway rollout status deploy/slipway-server
kubectl -n slipway get jobs

Compose

Section titled “Compose”
Terminal window
git pull
podman compose -f deploy/compose/compose.yaml --profile app build slipway
podman compose -f deploy/compose/compose.yaml --profile app up -d slipway

Migrations run at start (database.migrate, default true).

Binary installs

Section titled “Binary installs”
Terminal window
slipway migrate up           # as the schema owner (SLIPWAY_DATABASE_MIGRATE_URL)
# then restart server, scheduler and worker, in any order

Runners

Section titled “Runners”

Upgrade runners after the control plane. They can self-update from the stable channel (self_update.check), or you roll the image or package. On SIGTERM a runner stops taking jobs and waits up to its drain timeout for running ones.

Rolling back

Section titled “Rolling back”

Because migrations are forward-only, rolling back the application across a schema change is not supported by simply deploying the old image. To roll back across a migration, restore the database from the backup you took and deploy the old version. Within a version that has no migration, roll the image back normally (helm rollback).

Verifying

Section titled “Verifying”
  • /readyz returns OK on every pod.
  • A trivial pipeline runs end to end and logs stream live.
  • The environment board and approvals inbox load.
  • Check /metrics for elevated error rates for a few minutes after the roll.