# Kortix Rollback

How to roll Kortix PRODUCTION back to an older already-released version, the inverse...

- Repository: https://github.com/kortix-ai/suna (20345 stars)
- Category: Design
- License: see repository
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add kortix-ai/suna --skill kortix-rollback -g -a claude-code -y`
Codex: `npx skills add kortix-ai/suna --skill kortix-rollback -g -a codex -y`
Cursor: `npx skills add kortix-ai/suna --skill kortix-rollback -g -a cursor -y`
Gemini CLI: `npx skills add kortix-ai/suna --skill kortix-rollback -g -a gemini-cli -y`

## Description

How to roll Kortix PRODUCTION back to an older already-released version, the inverse of a release. Covers the one-dispatch rollback-prod.yml engine, the per-surface mechanics (API + gateway = ECS Fargate image-tag swap; frontend = Vercel promote), the all-important Vercel frontend behavior (why a backend-only push can 'clobber' a FE rollback, and the 'don't rebuild the FE for backend-only pushes' skip that fixes it), the DB/migration-drift safety check that is the real blocker, and how a later promote returns prod to latest. Load WHENEVER the user wants to roll back / revert / downgrade / 'go back a version' on prod, asks how the rollback or the frontend clobber/skip behavior works, or needs to run rollback-prod.yml. Pairs with kortix-release (the forward direction).

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Kortix Rollback

The inverse of **kortix-release**. A release moves prod FORWARD onto new code; a
rollback re-points prod at an OLDER already-released `vX.Y.Z`, reusing that
release's prebuilt artifacts (zero rebuild). Use it when a shipped version is
breaking and the move is "go back now, fix forward later." The next forward
release still comes from `staging`, not directly from `dev`.

> A rollback is **temporary, never sticky.** It only flips image tags + re-promotes
> an old frontend build; it never touches `VERSION` or the trunk. The next promote
> supersedes it and returns prod to latest (see §6). So rolling back never "wedges"
> the release pipeline.

## 1. The one command

```bash
gh workflow run rollback-prod.yml --repo kortix-ai/suna --ref prod \
  -f version=vX.Y.Z -f reason="<incident summary>" -f confirm="ROLLBACK PROD"
```

It rolls **frontend AND backend** and handles each surface independently:
- **Frontend** → promoted back to vX.Y.Z immediately (Vercel API, no rebuild).
- **Backend** (api, gateway) → re-tags the old `:vX.Y.Z` images as `:latest` and
  triggers an ECS Fargate rolling deploy via `ecs-deploy.sh`.

## 2. Per-surface mechanics

**Backend (API + gateway) runs Docker images on ECS Fargate.** Rollback = re-tag
the old, immutable, prebuilt `:vX.Y.Z` image as `:latest` and trigger an ECS
rolling update. The ECS deploy script (`infra/scripts/ecs-deploy.sh`) registers a
new task-def revision pointing at the old image and waits for `services-stable`.
Clean and exact, the image is frozen.

**Frontend is built by Vercel from the `prod` branch SOURCE.** Vercel is
git-connected: **every push to `prod` rebuilds the frontend from whatever
`apps/web` source is on the branch at that moment** and makes it live at
kortix.com. There is no "image tag" to point at. A FE rollback is instead a
**promote**: "take that old v0.9.68 build and make it the live one again." It does
NOT change the branch source, the branch still holds the newer FE code.

The rest: https://github.com/kortix-ai/suna/blob/HEAD/.agents/skills/kortix-rollback/SKILL.md