Rollback

Every successful apply records the applied revision on the App status — the ledger rollback uses. POST /rollback writes a spec.operation {kind: Rollback, revision} and the operator applies that revision instead of HEAD.

How Sync History Works

status:
  revision: "a1b2c3d4e5f6..."          # last APPLIED — the rollback marker
  observedRevision: "f6e5d4c3b2a1..."  # newest seen upstream
  previousRevisions:
    - "f6e5d4c3b2a1..."
    - "1234567890ab..."
    - "fedcba098765..."

previousRevisions accumulates applied shas — newest first. For image-source apps, "revisions" are digests, and rollback also rewrites spec.source.image.tag so the next resync doesn't undo it.

Rolling Back

Via the UI

Open the app → History → pick a revision → Rollback.

Via the API

# Get the revision ledger
curl -b cookies.txt http://localhost:8080/api/v1/apps/default/my-app/history
# {"name":"my-app","revision":"a1b2c3…","previous_revisions":["f6e5d4…","123456…"],"last_sync_at":"…"}

# Roll back to a sha from previous_revisions
curl -X POST http://localhost:8080/api/v1/apps/default/my-app/rollback \
  -b cookies.txt -H "Content-Type: application/json" \
  -d '{ "revision": "f6e5d4c3b2a1..." }'
# {"message":"rollback requested","revision":"f6e5d4c3b2a1…","operation_id":"…"}

409 while another operation is pending. The op's triggeredBy stamps the caller — visible in status.operationState and the audit log.

There is no wardn app rollback CLI command — rollback is API/UI only.

Tutorial: Roll Back a Bad Deployment

Step 1: Identify the Problem

curl -b cookies.txt http://localhost:8080/api/v1/apps/default/my-app/status | jq '{sync_status, health, health_reason}'

{ "sync_status": "Synced", "health": "Degraded", "health_reason": "Deployment api: 0/3 ready" }

Step 2: Review Sync History

curl -b cookies.txt http://localhost:8080/api/v1/apps/default/my-app/history

Pick the last healthy applied sha from previous_revisions.

Step 3: Rollback

curl -X POST http://localhost:8080/api/v1/apps/default/my-app/rollback \
  -b cookies.txt -H "Content-Type: application/json" \
  -d '{"revision": "d4c3b2a1f0e9"}'

Step 4: Verify Recovery

curl -b cookies.txt "http://localhost:8080/api/v1/apps/default/my-app/status?wait=60s" \
  | jq '{sync_status, health, revision}'

Important Caveats

Rollback doesn't change the source. For git apps, the operator applies operation.revision once — the next automated resync sees observedRevision still ahead and re-syncs to HEAD, undoing the rollback. Revert the commit in Git to make it permanent.

For image-source apps it's stickier: rollback writes the older tag back into spec.source.image.tag, so resyncs hold the rolled-back image until you bump it again.

Making rollbacks persistent (git sources)

git revert <bad-commit-sha>
git push

Rollback with prune enabled

If prune: true, rolling back deletes resources that were added in the newer revision — usually what you want, but be aware.

Limitations

Applied-revision ledger — previousRevisions holds applied shas only; a failed sync never makes the list
No pinned-depth guarantee — the list is unbounded in code but practical history depends on how often the app synced
Git source must still clone — rollback re-renders from git history; if the repo becomes unreachable the rollback op fails

Sync Policies — how the revision ledger is maintained
Applications API — /history + /rollback + /status references
Diff View Guide — inspect changes before syncing (planned)

Rollback

On this page