Releases and rollbacks

Every change is a release

Each change to an app is recorded as a numbered revision: deploys, configuration changes, rollbacks, promotions, builds and template deploys alike. A release snapshots what the app runs; the list shows each revision’s image, why it was made (create, deploy, config, rollback, promote, restart, build, …) and who made it.

• Console: open the app, Releases tab. The Deployments tab shows how each revision went out, phase by phase.
• API:

APP="$KUBEN_URL/api/v1/projects/shop/environments/production/apps/api"
curl -fsS "$APP/releases" -H "Authorization: Bearer $KUBEN_TOKEN"

The API lists the newest 50 revisions. Releases live in Kuben’s database, not on the cluster.

Roll back

Press Roll back next to any earlier revision, or:

curl -fsS -X POST "$APP/rollback" \
  -H "Authorization: Bearer $KUBEN_TOKEN" -H 'Content-Type: application/json' \
  -d '{"revision": 41}'

From a terminal, kuben rollback shop/production/api --to 41; without --to it returns to the revision before the current one.

A rollback is a new deployment like any other: a change freeze on the environment refuses it, and in a production environment it waits for approval. After a rollback, an app built from Git stops deploying new commits on its own, so a fix does not overwrite the rollback by surprise. Automatic image updates are not held: press Stop following first, or the next check moves the app forward again.

Emergency rollback

When it cannot wait, the Emergency rollback card on the Releases tab returns the app to the newest earlier release that ran successfully, right now: past approvals, a freeze, the vulnerability scan gate and a paused delivery. Press Roll back now…, say Why this cannot wait, and press Roll back now; the reason is kept on the deployment and in the audit log. It needs the right to approve deployments (admin or higher) and a signed-in person, never a token. The API is POST …/emergency-rollback.

What is restored, what is kept

Restored from the revision	Kept as they are today
image	domains
commands, ports and schedules	volumes and their contents
environment variables
health check
scaling (replicas and size)

Data never moves backwards: a rollback changes what runs, never what is stored. The rollback itself becomes a new revision, so the history stays linear and every rollback is visible in the audit log.

Secrets

A revision references secrets by name. Rolling back does not restore secret values; it uses the current values of the secrets it references. If a referenced secret was deleted in the meantime, the pods cannot start and the app’s Ready condition reports the rollout as failed.

Safe rollouts

Rollbacks use the same rollout machinery as deploys:

• New pods must pass their readiness check before old ones stop.
• Slow starters get up to 5 minutes through a startup probe.
• A rollout that makes no progress for 10 minutes is reported as RolloutFailed on the app’s Ready condition; the previous pods keep serving.

Apps with a volume run a single pod and use the Recreate strategy, so they see a few seconds of downtime on every rollout, including rollbacks.

Restart without a change

Restart on the app page (POST …/restart) rolls the pods with the same release and configuration, for example after a problem outside the app. It is audited. When the cluster agent delivers the app, the restart shows in the list as a restart revision of the same release.