Roll back a bad release from chat: rollbacks, restored variables and cancelled deploys

At 18:04 a release goes out. At 18:06 checkout starts returning 500s. Every minute you spend finding the previous release ID in a dashboard is revenue. With Railyard connected to Claude, the recovery is one sentence:

> Checkout is broken since the last deploy. Roll the shop back to the previous release.

This tutorial covers what happens behind that sentence, the choices you can make, and the related tools for the moments around a rollback.

What you’ll need

• Railyard connected to Claude (Customize → Connectors → Railyard → Connect), or to Claude Code with claude mcp add --transport http railyard https://app.railyard.run/api/mcp.
• A connection with deploy access. Rolling back, cancelling and maintenance mode are deploy actions, so deployers can do them, not just admins.

Step 1: Pick the release to go back to

Claude starts with list_deploys for the app, filtered to status: succeeded:

#1231  succeeded  git_push  9d1f0b7  18:04   ← the bad one
#1224  succeeded  git_push  4be27aa  15:41
#1219  succeeded  git_push  c30a2d1  11:12

“The previous release” is #1224. If you’re unsure, ask Claude to compare them with get_deploy on each, which shows the commit, the trigger and who started it. “Go back to this morning’s release” works too; it’ll pick #1219.

Only successful deploys with a commit can be rollback targets. Asking to roll back to a failed deploy gets a clear refusal and a pointer to list the succeeded ones.

Step 2: Roll back

{ "name": "rollback_app", "arguments": { "app": "shop", "deploy_id": 1224 } }

rollback_app is marked destructive (it replaces the running release), so Claude asks you to confirm. Then:

Rolling shop back to #1224 (code and variables) as deploy #1232.

Three details matter here.

It restores the variables too, by default

A release is code plus configuration. If the bad deploy came with a variable change (a new PAYMENTS_API_URL, a removed flag), rolling back only the code leaves you half-reverted. Railyard records the variables each successful deploy ran with, and rollback_app restores them along with the code. The deploy log notes exactly what changed back:

Rolling back to 4be27aa with its variables — PAYMENTS_API_URL changed back

To keep today’s variables and only revert code, say so (“roll back the code only”). Claude passes restore_config: false.

It’s a normal deploy

The rollback goes through the same pipeline as any deploy: health checks, zero-downtime switch, logs. If the app requires deploy approval, the rollback waits for an admin like any other deploy, and the agent says so:

Rollback #1232 of shop to #1224 (code and variables) is waiting for an admin to approve it.

Rollbacks skip the deploy-window restriction, though. A rollback is how you get out of trouble, so it isn’t held until business hours.

It’s in the history

The rollback shows in the deploy list marked as a rollback, and in the activity log as an MCP action with the token that made it. The post-mortem timeline writes itself.

Step 3: Confirm recovery

> Is checkout healthy again?

Claude follows deploy #1232 with get_deploy and deploy_logs, then checks app_traffic (range live) for the 5xx rate and app_logs at level error. You want to see the error rate fall back to its earlier level, and no new errors since the switch.

The tools around a rollback

Cancel a deploy that’s still going

If you catch the bad release before it finishes, there’s no need to roll back. Stop it:

> Cancel the deploy that's running on shop.

cancel_deploy stops a deploy that’s queued, scheduled or still running. Finished deploys can’t be cancelled, and the agent is told so, with the status, so it can suggest a rollback instead.

Put up the maintenance page

When the fix needs a few minutes and errors are worse than a clear message:

> Put shop in maintenance mode while I fix the migration.

set_maintenance with on: true redeploys the current release with Railyard’s maintenance page in front. on: false takes it down. It’s idempotent: asking twice changes nothing.

Deploy an exact known-good commit

Sometimes the right target isn’t a previous deploy but a specific commit or tag:

> Deploy shop at tag v2.14.3.

deploy_app with ref builds and deploys exactly that commit, tag or branch, through the normal pipeline.

Why rollbacks don’t need approval but restores do

Railyard sends five MCP actions to a human approval queue: deleting an app, removing a variable or domain, restoring a database backup, and rebooting a server. Rollbacks aren’t on that list, on purpose:

• A rollback is reversible. If #1224 turns out worse, roll forward to #1231 again. Nothing is lost.
• Speed matters most during an incident. An approval step at 18:06 costs real money.
• The guard rail is the scope. Rollbacks need deploy access, which only deployers, admins and owners can grant.

A database restore is different. It replaces today’s data with an older copy, and that can’t be undone by deploying again. So restore_backup always waits for an admin, even during an incident.

A rollback playbook to keep

1. “What changed in the last deploy of shop, and is it what’s failing?” (get_deploy, deploy_logs, app_logs)
2. “Roll shop back to the previous release.” (rollback_app)
3. “Is it healthy now?” (app_traffic, list_processes)
4. “Show me the activity for shop today.” (list_activity, for the incident note)
5. Fix forward in code, then “deploy shop at main” (deploy_app).

More in debug a failed deploy with Claude, and the full tool reference in the MCP docs.