Manage your VPS from Claude Code, Cursor, or Codex without raw SSH
Use mttrly as the incident response action layer between AI IDEs and your Linux servers.
Direct answer
Yes. mttrly lets Claude Code, Cursor, and Codex manage a VPS without opening raw SSH as the normal control path. An outbound agent runs on your Linux server, exposes scoped MCP tools, and returns status, logs, diagnostics, playbooks, pending approvals, and audit history. Read-only checks can run directly; risky remediation creates an approval request that a human must confirm before execution from the AI IDE or Telegram.
The problem with raw SSH for AI assistants
SSH is still the right emergency tool for operators, but it is a poor default interface for an AI assistant. The assistant receives a terminal-shaped surface, the operator must add safety policy around it, and routine incident work becomes harder to audit as a workflow.
- -An SSH MCP server gives an AI assistant a broad terminal-shaped interface unless you add your own guardrails.
- -A raw session makes it harder to separate read-only inspection from risky state changes.
- -Audit trails often depend on shell history, bastion logs, or cloud-specific tooling instead of the incident workflow itself.
- -Mobile remediation is awkward when the fallback is a terminal session from a phone.
How mttrly works instead
Outbound agent on the server
The mttrly agent runs on your Linux server and connects outbound, so the normal path does not require exposing an inbound SSH control surface to the AI client.
MCP endpoint for AI IDEs
Claude Code, Cursor, and Codex connect to mttrly through an MCP endpoint, then discover available servers, tools, limits, and approval requirements.
Scoped tools before shell access
The assistant uses scoped tools for status, alerts, diagnostics, playbooks, pending approvals, and audit history. One-off command execution, when enabled, is still approval-gated and audited.
Approval gates and audit log
Risky remediation creates a pending action. A human reviews the details, approves or rejects it, and the result is recorded in the audit log.
Telegram and mobile control path
The same action layer can be controlled from Telegram, so you can respond from a phone when an alert fires away from your laptop.
Start with the mttrly MCP server, then check the MCP setup docs for client configuration and approval behavior. For mobile approval, connect the Telegram integration.
Raw SSH vs cloud command runners vs mttrly
| Capability | Raw SSH | AWS SSM / cloud run command | GitHub Actions | mttrly |
|---|---|---|---|---|
| Requires cloud control plane | No | Yes | Requires GitHub CI runner path | No; uses outbound agent |
| Works on bare VPS / Hetzner / DigitalOcean / Linode | Yes | Only if enrolled in a supported cloud path | Indirectly, if workflows can reach the host | Yes |
| Normal control path avoids raw SSH | No | Yes, but still command-centric | Yes, through workflows | Yes, through scoped MCP tools |
| Human approval before risky action | Manual discipline | Possible with cloud controls | Possible with environments | Built into approval gates |
| Audit trail | Depends on host and bastion setup | Cloud audit logs | Workflow logs | Approval and action audit log |
| Can diagnose logs/status | Yes, manually | Yes, command-based | Limited to scripted checks | Yes, with diagnostics and server tools |
| Can remediate from phone/AI IDE | Possible, but terminal-heavy | Cloud console or CLI | Workflow dispatch if prepared | Telegram or Claude Code / Cursor / Codex |
Restart nginx from Claude Code without SSH
A realistic flow starts with discovery, reads before writes, prefers a playbook, and only executes after explicit confirmation.
mttrly_get_capabilitiesCheck what the current plan and session can do
The assistant starts by reading available tools, restricted tools, and plan limits before attempting any action.
mttrly_list_serversFind the target server
It lists connected servers and selects the VPS you named, such as prod-web-01.
mttrly_get_server_statusRead current health
It checks CPU, RAM, disk, active alerts, and basic service reality before assuming nginx is the only issue.
mttrly_run_diagnosticRun a targeted diagnostic
For "nginx is down", the diagnostic can inspect status, logs, ports, and likely failure points through mttrly tools.
mttrly_list_playbooksLook for a bounded remediation
The assistant prefers a restart-nginx or nginx-reload playbook over a free-form command when one is available.
mttrly_run_playbookCreate the pending action
If the playbook changes server state, mttrly returns a pending action with details instead of silently restarting the service.
mttrly_approve_actionExecute only after explicit human confirmation
The assistant may call this tool only after you review the pending action and explicitly approve or reject it.
mttrly_get_audit_logReview what happened
Afterward, the assistant can retrieve the audit trail showing the request, approval decision, execution, and result.
When mttrly does not replace SSH
mttrly is the normal incident response action layer, not a promise that SSH disappears from infrastructure forever.
- -Initial agent installation may require SSH or another bootstrap path.
- -If the agent is offline or outbound connectivity is blocked, mttrly cannot reach the server until connectivity is restored.
- -Kernel, bootloader, firewall lockout, and rescue-mode emergencies may still require provider console or SSH-level access.
- -Deep forensics and arbitrary interactive shell work remain better suited to a controlled SSH session.
- -First-time infrastructure provisioning may still happen through Terraform, cloud consoles, SSH, or provider-specific tools.
Where monitoring fits
Grafana, Datadog, Sentry, PagerDuty, and similar systems detect symptoms, visualize telemetry, or wake someone up. mttrly acts after the alert: it helps the operator diagnose the server, choose a scoped remediation, approve risky steps, and leave an audit trail.
mttrly is not an observability replacement. It is closer to an incident response action layer that pairs well with an existing monitoring stack and with on-call response workflows.
FAQ
Can Claude Code manage my VPS without SSH?
Yes. Claude Code can use mttrly through MCP to inspect server status, run diagnostics, list playbooks, request remediation, and review audit logs without opening a raw SSH session as the normal control path. State-changing actions still require the appropriate approval flow.
Does mttrly replace SSH completely?
No. mttrly reduces the need to use SSH for routine incident response, diagnostics, and prepared remediation. SSH may still be needed for initial installation, offline agent recovery, deep forensics, provider rescue mode, and first-time infrastructure provisioning.
Is this safer than an SSH MCP server?
It is safer for common production operations when you want an AI assistant to work through scoped tools instead of a broad terminal interface. mttrly separates read-only diagnostics from approval-gated actions and records activity in an audit log. It does not remove the need for careful access control.
Does it work on Hetzner/DigitalOcean/Linode?
Yes, mttrly is designed for ordinary Linux servers and VPS hosts, including bare VPS environments such as Hetzner, DigitalOcean, and Linode. The server needs the mttrly agent installed and outbound connectivity to the mttrly service.
What happens if the mttrly agent is offline?
If the agent is offline, mttrly cannot run live diagnostics or remediation on that server. You can still see cached or previously recorded data where available, but restoring the agent or server connectivity may require SSH, a provider console, or a bootstrap recovery path.
Can I approve fixes from Telegram?
Yes. Telegram is a supported control path for mttrly. Risky actions can be routed through human approval so you can review and approve or reject a fix from your phone instead of opening an SSH client.
Can I disable command execution and use only playbooks?
Yes, where your plan, MCP client, or workspace policy restricts the tools exposed to the assistant. mttrly can operate through read-only diagnostics and prepared playbooks, with playbooks still approval-gated when they change server state. If mttrly_execute_command is enabled, treat it as a restricted, audited fallback rather than the default path.
Put an action layer behind your AI IDE
Start with read-only MCP tools, then add approval-gated playbooks when you want mttrly to help remediate production incidents.