Roll back production
rollback_commitAffects the live site and can destroy data. STARTS a rollback of a storage commit v2 project's canonical (production) pointer to an earlier commit (by job_id) and returns at once with a rollback_id: the reply means the rollback was accepted, never that it finished. A rollback takes a few minutes. get_rollback_status with that rollback_id reports its progress and its end: status done means production runs the target commit and, in restore_data mode, the app is running on the restored data; status failed carries the reason and says what changed. Until then list_deployments and get_app_status can already show the target commit as canonical and running while the data is not restored yet: only status done means the rollback is finished. mode=keep_data (the SAFE default): switch the pointer back, storage untouched — the outgoing canonical keeps running on its own clone. mode=restore_data: ALSO restore that commit's data snapshot onto the main volume, permanently destroying everything the app has written to storage since that snapshot was taken — irreversible from the app's side, everything written since is lost; the app or its database is stopped while the data is copied back. The one way back is the safety copy the platform takes just before the restore (safety_point_id in get_rollback_status; only the newest few are kept), restored in turn. Refuses projects that are not on storage commit v2 (the dashboard rollback flow owns those). keep_data refuses the canonical commit (the app is already on it); restore_data on the canonical commit moves no code and restores the data in place, which is how a failed data restore is retried and how a restore is undone. One rollback runs per project at a time. A refusal means nothing was started and nothing was changed. Requires a read-write token.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | mode: "keep_data" | "restore_data". keep_data (the safe default): switch the canonical pointer back to this commit and leave storage untouched. restore_data: ALSO restore this commit's data snapshot onto the main volume, permanently destroying everything the app has written to storage since that snapshot was taken — confirm with the user first; keep_data is the safe choice | |
| job_id | Yes | the deployment job id to roll the project's canonical (production) pointer back TO (from list_deployments); must belong to a storage commit v2 project. With mode=keep_data it must not be the current canonical commit; with mode=restore_data it may be, and the data is then restored in place | |
| point_id | No | optional restore point to bring the data back from, only meaningful with mode=restore_data; omit it to use this commit's own newest restore point, which is the default. A point id that no longer exists is refused rather than silently falling back to the default |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ok | Yes | true when the rollback was STARTED (or parked for approval). It never means the rollback finished | |
| status | No | present, and always "pending_approval", only when this call was parked instead of run immediately because the project's (or kad-back's own) plan-mode setting requires a human to approve it first | |
| message | Yes | ||
| plan_id | No | poll get_plan_status with this id for the eventual outcome | |
| approve_at | No | the kad.dev dashboard URL a human approves or rejects this plan from | |
| rollback_id | No | pass this to get_rollback_status to follow the rollback to its end | |
| expires_in_s | No | the plan can no longer be approved after this many seconds | |
| retry_after_s | No | wait at least this many seconds before the first get_rollback_status call, unless it is called with wait_s | |
| rollback_status | No | running: the rollback was accepted and is in progress. The final status (done or failed) comes from get_rollback_status |