Rollback a deployment from your phone — without a blind shell command
Use the deployment pipeline and its captured snapshot, review the exact target, approve from Telegram, then verify production after the restore.
Direct answer
The safest way to roll back a failed deployment from a phone is to use the same deployment pipeline that captured the previous revision, not to type a destructive Git command into a mobile terminal. In mttrly, a natural-language rollback request is routed to the deploy pipeline, which checks for a configured deploy profile and a saved snapshot, shows the target revision, and creates a pending action. The rollback starts only after explicit human approval from Telegram, the dashboard, or an IDE confirmation flow.
What you see
A rollback is appropriate when the evidence points to the release itself and restoring the last known-good version is safer than debugging live. Common signals:
The health endpoint started failing immediately after the latest deployment
The new process crashes on startup while the previous release was stable
A sharp increase in 5xx responses aligns with the deployment timestamp
Recent logs show a regression introduced by the new application revision
The deploy completed, but post-deploy verification reports an unhealthy service
You are away from a laptop and need a controlled recovery path with a visible approval preview
How to roll back safely by hand
Do the read-only checks first. A rollback changes production state, so identify the exact release and its dependencies before restoring anything.
Confirm the regression began with the deployment
Check the public health endpoint and incident timeline. A coincidental provider, DNS, or database failure will not be fixed by rolling back application code.
curl -fsS https://your-app.example.com/health || true
Identify the current and last known-good revisions
Review recent commits or deployment records. Do not assume HEAD~1 is safe when several commits or deployments were bundled together.
git -C /var/www/your-app log --oneline -5
Read the post-deploy logs before changing state
Capture the failure evidence first so you can verify that the rollback addresses the actual regression.
journalctl -u your-app --since "15 minutes ago" --no-pager
Check migrations and external side effects
A code rollback does not automatically reverse a database migration, queue message, schema change, or external API side effect. Confirm backward compatibility before restoring the application.
git -C /var/www/your-app diff --name-only <known-good>..HEAD
Restore through the deployment system
Promote the known-good artifact or use the snapshot recorded by your deploy pipeline. Avoid an improvised git reset on a live checkout.
Verify the restored release
Check the health endpoint, service state, error logs, and the revision now serving traffic. A successful command is not the same as a healthy application.
curl -fsS https://your-app.example.com/health systemctl status your-app --no-pager journalctl -u your-app -n 100 --no-pager
Do not run git reset --hard HEAD~1 blindly in production. It may select the wrong revision, discard uncommitted state, and leave code incompatible with database changes. Capture the current state and confirm the rollback target first.
How mttrly handles it
mttrly treats a normal “rollback” request as a deployment action. Product intent routing deliberately prefers the configured deploy pipeline and its saved snapshot over the lower-level rollback_release playbook or an arbitrary raw shell command.
Ask for the rollback from Telegram
Name the affected server. The same request can originate from another connected mttrly control surface, but Telegram gives you the phone-first review and approval path.
Intent routing selects deploy_action: rollback
The product classifier explicitly routes rollback requests to the deployment flow, not directly to rollback_release. This keeps the action inside the configured pipeline.
The pipeline checks its deploy profile and snapshot
mttrly needs a configured deploy profile and a captured previous snapshot. If no snapshot exists, it stops and says there is no rollback target instead of guessing.
You review the target revision
The approval preview shows the server and saved revision. The rollback remains pending until a human explicitly approves it.
The deploy adapter restores what it knows
For a bare Linux deployment, the pipeline can restore the captured Git revision. Docker Compose uses its snapshot-aware rollback adapter. Exact behavior depends on the configured deployment mode and snapshot data.
Run post-deploy verification
After the rollback, the read-only post-deploy-verification recipe checks server health and recent application logs. Confirm the application endpoint separately when it is not represented by those signals.
Example workflow
A realistic phone-first flow with a configured deploy profile (revision values illustrative):
You -> Telegram:
"Rollback prod-web-01. The release that just went out is returning 500s."
mttrly:
- routes the request to deploy_action { action: "rollback" }
- finds the deploy profile for prod-web-01
- finds the captured previous snapshot at revision a13f6c2
- shows: "Rollback prod-web-01 to a13f6c2?"
- creates a pending deploy_rollback approval
You: review the target and tap Approve
mttrly deploy pipeline:
- restores the snapshot through the configured deploy adapter
- reports whether the restore succeeded
- records the approval and result in the audit trail
You -> mttrly:
"Verify production after the rollback."
mttrly:
- runs post-deploy-verification (healthcheck + recent app logs)
- reports the current server-health and log signals after the restoreRemediation under runtime policy
Configured deploy pipeline — the preferred rollback path. It uses the deployment profile and captured snapshot, then starts only after a deploy_rollback approval is confirmed by a human.
rollback_release playbook — a lower-level, approve-required Git operation that creates a backup branch, reverts the latest commit, and can run a validated restart command. It is not the default product intent and is not a universal rollback mechanism.
post-deploy-verification recipe — a read-only server-health and recent-log pass after the restore. Pair it with the application endpoint when needed instead of relying on a successful exit code.
Diagnostics are read-only. Risky fixes follow runtime policy.
- +mttrly investigates on its own: diagnostic recipes and read-only playbooks inspect the server without changing anything.
- +Approval-required fixes create a pending action for confirmation from Telegram, the dashboard, or the IDE. Runtime policy — not the AI — decides the action class.
- +A separately authorized Investigation session can let mttrly_execute_command skip per-action approval only within its server, time, and action limits. That bounded exception is visible and auditable.
- +mttrly does not give an AI client an unrestricted production shell. Diagnostics, configured preauthorization, approval gates, and bounded sessions remain explicit.
These incident guides use the same scoped MCP action layer and can route approval decisions through the Telegram mobile workflow.
Detection tools tell you something is wrong. mttrly is the agent on your server that diagnoses the incident and prepares the fix — through scoped MCP tools, diagnostic recipes, and remediation playbooks. Approval-required actions normally wait for a human; any narrowly configured preauthorization remains bounded and audited. It complements monitoring like Grafana, Datadog, or UptimeRobot; it does not replace it.
When a rollback is not enough
A deployment snapshot can restore only the state represented by that deployment mode. Important boundaries:
- -No deploy profile or saved snapshot means mttrly has no trustworthy rollback target. Use your deployment provider, repository, or a controlled SSH session to recover.
- -Database migrations and data writes are not automatically reversed by a code rollback. Use an application-specific migration recovery plan.
- -The rollback_release playbook operates on a Git checkout and reverts the latest commit; it cannot represent every artifact, platform, or multi-release strategy.
- -Docker Compose rollback behavior depends on the captured image snapshot and deploy configuration. Do not assume every image tag can be restored universally.
- -If the agent is offline, an on-server rollback cannot run until connectivity is restored through the provider console or another recovery path.
Frequently asked questions
Can I roll back a deployment from Telegram?
Yes, when the server has a configured mttrly deploy profile and a captured previous snapshot. The request shows the target revision and creates a pending approval. Nothing rolls back until you explicitly approve it.
Does mttrly ever roll back production without approval?
A standalone rollback request always requires explicit human approval. A configured deploy pipeline may restore its captured snapshot when its post-deploy healthcheck fails, but that restore is part of the deployment operation you already approved; it is not an unrelated autonomous rollback.
Is rollback_release the normal rollback path?
No. Natural-language rollback intent is deliberately routed to the deploy pipeline. rollback_release still exists as an approve-required, lower-level Git playbook, but it reverts the latest commit in a specified application directory and is not safe to present as a universal rollback.
What happens if there is no saved snapshot?
mttrly stops and reports that there is no snapshot to restore. It does not guess a commit or run a raw rollback command. You need to select a known-good release through your deployment system, provider, repository, or a controlled recovery session.
Related
Put a reviewed rollback path on your phone
Connect a server, configure its deploy profile, and keep rollback behind a visible human approval instead of an improvised mobile shell command.