Kortix Rollback
How to roll Kortix PRODUCTION back to an older already-released version, the inverse...
Install
npx skills add kortix-ai/suna --skill kortix-rollback -g -a claude-code -y- Repository
- kortix-ai/suna20.3k
- Category
- Design
- Updated
- 3d ago
- License
- See repository
- Context cost
- Mediumabout 2,133 tokens
- Runs scripts
- No, instructions only
What it does
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).
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
VERSIONor 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
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.Zimages as:latestand triggers an ECS Fargate rolling deploy viaecs-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.
