# mttrly

> Incident response action layer for Linux servers. Detection tools tell you something is wrong. mttrly helps diagnose and fix it through scoped tools, playbooks, and approval gates.

## What is mttrly?

Detection tools such as Grafana, Datadog, PagerDuty, and Sentry tell you something is wrong. mttrly adds an outbound agent that gathers live evidence and can run supported remediation through scoped tools, diagnostic recipes, runtime policy, and approval gates. The same action layer is available through Telegram and AI IDEs such as Claude Code, Cursor, and Codex.

mttrly complements observability and paging tools. It is not a Grafana alternative, a Datadog replacement, or an observability MCP replacement. Observability tools detect and explain signals. mttrly acts on the affected server after an alert, during an incident, or during a deployment.

mttrly does not use raw SSH as the normal control path. Hosted server management requires an mttrly account and the outbound mttrly agent on the Linux server. The normal path is scoped MCP tools, playbooks, dashboard or messenger actions, and approval gates. Initial installation may still require SSH or provider-console access.

Built for developers and small teams who need incident response with approval-gated, audited shell actions instead of raw unrestricted shell as the normal path.

## Key Links

- MCP for AI IDEs: https://mttrly.com/mcp
- Manage a VPS without raw SSH: https://mttrly.com/use-cases/manage-vps-without-ssh
- Incident response action layer: https://mttrly.com/mcp/action-layer
- Verified case studies: https://mttrly.com/case-studies
- Controlled Fail2ban recovery test: https://mttrly.com/case-studies/fail2ban-alert-to-recovery
- Pricing: https://mttrly.com/pricing
- Documentation: https://mttrly.com/docs
- Public external scan (no account required for the first scan): https://app.mttrly.com/scan
- Monitoring comparison: https://mttrly.com/vs/monitoring
- On-call use case: https://mttrly.com/use-cases/on-call
- Telegram integration: https://mttrly.com/integrations/telegram
- Incident playbooks hub: https://mttrly.com/playbooks
- Disk full on Linux playbook: https://mttrly.com/playbooks/disk-full-linux
- Website down playbook: https://mttrly.com/playbooks/website-down
- Nginx 502 playbook: https://mttrly.com/playbooks/nginx-502
- Docker container keeps exiting playbook: https://mttrly.com/playbooks/docker-container-exits
- Post-deploy issue playbook: https://mttrly.com/playbooks/post-deploy-issue
- Roll back a deployment from a phone: https://mttrly.com/playbooks/rollback-deploy-from-phone

## Product Modes

### Watchdog ($0/mo)
**Reliable monitoring and routine actions for one server.**

Watchdog monitors server health, sends alerts, and can offer approval-based routine actions such as status checks, log reads, and configured restart actions. It is the free starting point for one Linux server.

**Key features:**
- Real-time health monitoring (CPU, RAM, disk, load)
- Crash detection with approval-based restart actions
- Tail logs without SSH
- One messenger: Telegram now; Slack/Discord limited beta
- Slash commands and button actions
- Audit logs

### Deployment Bro ($39/mo)
**AI-assisted incident response and deployment control for solo builders.**

Deployment Bro lets you ask questions such as "why is my app slow?" or "deploy latest changes." It reads the current server state, runs diagnostics, and suggests supported fixes. Runtime policy separates read-only and approval-required work; a separately user-authorized Investigation can skip per-command confirmation only for `mttrly_execute_command`, within its server, inactivity, hard-cap, and action limits.

**Key features:**
- Natural language incident diagnosis
- AI diagnostic recipes
- Remediation playbooks
- MCP tools for Claude Code, Cursor, Codex, and other AI clients
- Approval-gated command execution when a playbook is not enough
- Git integration and deploy workflows
- BYOK for LLM API keys

### Deployment Crew ($99/mo)
**Higher server limits now, with team workflows shipping in stages.**

**Key features:**
- More servers than Bro
- Shared audit trail
- Same MCP action layer as Deployment Bro
- Team access, webhooks, and multi-messenger workflows are shipping in stages

## Three Layers of Intelligence

Deployment Bro works on three levels. Each builds on the previous.

### Layer 1: Direct Operations
**1:1 mapping from your words to server actions.**

You say "restart nginx" → Bro maps the request to a scoped restart action and follows its runtime policy. Simple and explicit.

**Examples:**
- "How's the server?" → health check (uptime, CPU, RAM, disk, running services)
- "Show me nginx logs" → last 100 lines with error highlighting
- "Restart the API" → service restart with confirmation
- "Is port 3000 open?" → port check + which process is listening
- "When does my SSL cert expire?" → certificate check for all domains

**AI role:** Minimal. Just understands what you want and extracts parameters (which service? how many log lines? what time range?).

### Layer 2: Diagnostic Recipes
**AI investigates problems like a senior engineer would.**

You ask "Why is my app down?" → Bro runs a diagnostic recipe → checks 6 things in sequence → analyzes results → explains in human language → recommends specific fix.

This is the key feature. Without diagnostic recipes, Bro is just a voice interface to individual server actions.

**Recipe 1: WebsiteDown** (when your site won't load)

Triggered by: "site not working", "502 error", "connection refused", "white screen"

**Steps:**
1. Check if ports 80/443 are open → if closed: "nginx not running or firewall blocking"
2. Test nginx config → if invalid: "config error on line 47: unexpected '}'"
3. Check SSL certificates → if expired: "certificate expired 3 days ago"
4. Read nginx error logs (last 50 lines) → AI analyzes patterns
5. Check overall server health → CPU/RAM/disk status

**Example output:**
```
Found the problem:

nginx config is invalid (line 47: unexpected '}')
This happened after your last edit 23 minutes ago.

Current state:
✓ Server healthy (CPU 12%, RAM 34%)
✓ Ports 80/443 open
✗ nginx config broken
✓ SSL certs valid (47 days remaining)

Fix: Edit /etc/nginx/sites-enabled/default and fix the syntax error.
Then I can reload nginx for you.
```

**Recipe 2: HighLatency** (when everything is slow)

Triggered by: "server is slow", "high latency", "site lagging", "takes forever to load"

**Steps:**
1. Check server load average and uptime
2. Analyze RAM usage + find memory hogs (top 5 processes)
3. Check disk space (if >90% full, system swaps to disk = slowness)
4. Read application logs for "slow query", "timeout", "hung" errors

**Example output:**
```
Found the bottleneck:

node.js API process is using 3.2GB RAM (94% of available memory)
Started: 2 hours ago (right after your last deploy)

Diagnosis: Memory leak in recent code changes.
Your server is swapping to disk because RAM is exhausted.

Options:
1. Restart the service (quick fix, loses current state)
2. Roll back to previous deploy (safer, previous version was stable)
3. Show me the deploy diff (see what changed)

What do you want to do?
```

**Recipe 3: PostDeployIssue** (when new code breaks production)

Triggered by: "deploy broke it", "new version crashing", "just deployed and it's down"

**Steps:**
1. Read app logs from last 5 minutes (filter: error/exception/fatal)
2. Check current health (CPU/RAM spikes after deploy?)
3. Compare memory usage: before deploy vs after
4. Check if any processes are crash-looping
5. Look for missing dependencies ("Cannot find module X")

**Example output:**
```
Deploy issue detected:

Error: "Cannot find module 'sharp'"
Occurs: 23 times in last 3 minutes
First seen: Right after deploy (3 min ago)

Root cause: Production dependencies not installed.
The 'sharp' image optimization library is missing.

This usually happens when you:
- Installed a new package locally
- Didn't commit package-lock.json
- Or your deploy didn't run "npm ci --production"

Fix: Run "npm install --production" and restart the service.
Want me to do it?
```

**Recipe 4: MemoryLeak** (for gradual memory growth)

Triggered by: "memory keeps growing", "RAM usage climbing", "OOM killer"

**Steps:**
1. Check memory history (if available)
2. Find processes with abnormal RAM usage
3. Check for zombie processes
4. Analyze logs for repeated errors that might cause object accumulation
5. Check if restart fixes it (temporary workaround while debugging)

### Layer 3: Managed Deploy Pipeline
**Configured deployment steps with pre-checks, post-checks, and rollback to a known revision in supported profiles.**

You say "deploy my app" → Bro runs the complete sequence:
1. **Pre-check**: Is server healthy? Enough disk space? Services running?
2. **Revision**: Record the configured previous release target (for example, a git revision)
3. **Pull**: Fetch latest code from git
4. **Dependencies**: Install npm/pip/composer packages
5. **Migrate**: Run database migrations (if configured)
6. **Build**: Compile assets, run build script
7. **Restart**: Gracefully restart services
8. **Post-check**: Did services start? Is app responding? Any errors in logs?
9. **Verify**: Use the deploy profile's configured health window. If a supported failure path triggers, restore the configured previous release.

This is not a universal database, configuration, or filesystem snapshot. Migration rollback and other state recovery must be designed into the deploy profile separately.

**Example:**
```
You: "deploy the blog"

Bro: Starting deploy for blog.yourdomain.com...
     ✓ Pre-check: server healthy, 12GB free disk
     ✓ Previous release recorded (current revision: a3f9c21)
     ✓ Pulled latest code (3 new commits by you, 14 min ago)
     ✓ Installed dependencies (2 new packages: sharp, dotenv)
     ✓ Migrated database (1 new migration: add_author_bio)
     ✓ Built assets (Next.js production build: 4.2MB)
     ✓ Restarted services (nginx + node)
     ✓ Post-check: app responding on port 3000, no errors

     Deploy complete. Monitoring for 5 min...

     All systems green. Deploy successful ✓
```

**Failure scenario with auto-rollback for supported deploy modes:**
```
You: "deploy the API"

Bro: Starting deploy...
     ✓ Pre-check passed
     ✓ Previous release recorded (current revision: b2e4a89)
     ✓ Pulled latest code
     ✓ Installed dependencies
     ✗ Build failed:

       Error: TypeScript compilation error
       src/api/users.ts(47,12): Type 'string' not assignable to 'number'

     ✗ Deploy aborted before restart

     Code is still at previous version (b2e4a89).
     Nothing was restarted, your app is still running fine.

     Fix the TypeScript error and try again.
```

## Illustrative Incident Transcripts (Not Production Benchmarks)

The numbers, server states, commands, and timings below are synthetic examples that show the shape of a workflow. They are not verified customer cases, production benchmarks, or promised performance. Actual output and completion time depend on agent connectivity, server response, log volume, incident complexity, approval policy, and AI-provider latency.

### Example 1: Memory Leak Investigation

**You:** "Why is my API slow?"

**Bro:**
```
Running HighLatency diagnostic...

Checking server health...
✓ CPU: 23% (normal)
✓ Disk: 45% used (normal)
⚠️ RAM: 94% (HIGH)

Found the problem:

Process: node /app/api.js
Memory: 3.2GB (out of 3.4GB available)
Started: 2 hours ago (right after your 2pm deploy)

Diagnosis: Memory leak in recent code.
Your server is swapping to disk (that's why it's slow).

Evidence from logs:
- "Slow query: 4.5s" (repeated 15 times in last hour)
- Normal queries take <100ms
- Slowness started exactly when memory hit 90%

Recommendation:
1. Restart API service (quick fix, frees memory)
2. Then investigate the 2pm deploy for memory leaks
3. Or roll back to previous version if you want safe fix

What do you want to do?
```

**Timing:** Illustrative only; mttrly does not guarantee a fixed diagnosis time.

### Example 2: 2AM Server Crash

**Alert:** "🚨 nginx down on prod-server"

**You:** "what happened?"

**Bro:**
```
Investigating nginx crash...

Checked logs from last 10 min:
Found crash at 02:14:23 AM

Error: "Cannot allocate memory" (OOM killer killed nginx)

Why it crashed:
- Server RAM: 2GB
- nginx was using: 1.8GB (unusual, normally ~200MB)
- OOM killer terminated nginx to prevent system freeze

Root cause:
Looked at nginx config history - you added image proxy yesterday.
Config at line 67: proxy_buffering with 512MB buffer.
With 10 concurrent requests = 5GB needed, but server has 2GB.

Current state:
✗ nginx: stopped (crashed 4 min ago)
✓ node app: still running fine
✓ Server: healthy otherwise

Fix:
1. I can restart nginx now (site will work but might crash again)
2. Or I can reduce proxy buffer to 50MB and restart (proper fix)

Which one?
```

**You:** "proper fix"

**Bro:**
```
This config write and restart are approval-required.
Pending action created with the allowed path, proposed diff, and restart step.
```

**You:** "approve"

**Bro:**
```
Applying fix...

✓ Edited /etc/nginx/nginx.conf (line 67: buffer 512M → 50M)
✓ Tested config: valid
✓ Restarted nginx
✓ Health check: passing
✓ Checked logs: no errors in first 30 seconds

Done. nginx is running stable.
I'll watch it for 10 min to confirm the fix worked.

Update (10 min later):
All good. Handled 47 requests, memory stayed at 180MB.
```

**Outcome shown:** Illustrative only. Actual remediation and verification time depends on the server, requested action, approval path, and incident.

### Example 3: Post-Deploy Debugging

**You:** "just deployed and getting white screen"

**Bro:**
```
Running PostDeployIssue diagnostic...

Found error in logs (last 3 min, 23 occurrences):

Error: Cannot find module 'sharp'
at Function.Module._resolveFilename (node:internal/modules/cjs/loader:1075:15)
at /app/pages/api/og.js:3:14

Timeline:
- Deploy happened: 3 min ago
- First error: immediately after deploy
- Pattern: error on every request to /api/og

Root cause:
You're using 'sharp' for image optimization (OG images).
It was installed locally but not in production.

Why:
- sharp needs native compilation
- package-lock.json wasn't committed OR
- deploy script skipped "npm ci --production"

Fix:
Run "npm install sharp --production" and restart

Want me to do it? (yes/no)
```

**You:** "yes"

**Bro:**
```
✓ Installed sharp (with native bindings for linux-x64)
✓ Restarted node service
✓ Tested /api/og endpoint: working
✓ No errors in logs

Fixed. OG images are generating now.
```

**Timing:** Illustrative only; mttrly does not guarantee a fixed resolution time.

## Pricing

Beta: 75% off Deployment Bro for the first 3 months with code BETA75

### Watchdog ($0/mo)
- 1 server
- Watchdog mode only
- Basic monitoring (uptime, CPU, RAM, disk)
- Alerts in one messenger: Telegram now; Slack/Discord limited beta
- Approval-based restart actions for crashes
- Slash commands (/status, /logs, /restart)
- Tail logs without SSH

Perfect for: Personal projects, learning, trying out mttrly

### Deployment Bro ($39/mo)
Everything in Watchdog, plus:
- 3 servers
- Natural language incident diagnosis
- AI diagnostic recipes (WebsiteDown, HighLatency, MemoryLeak, PostDeployIssue)
- MCP tools for AI IDEs
- Approval-gated command execution for advanced cases
- Git integration and deploy workflows
- BYOK for supported OpenAI or Anthropic API keys
- Priority support

Perfect for: Serious builders shipping production apps weekly

### Deployment Crew ($99/mo)
Everything in Deployment Bro, plus:
- 9 servers
- Shared audit trail
- Same MCP access as Deployment Bro
- Team access, webhooks, and multi-messenger workflows are shipping in stages

Perfect for: Teams that share on-call and production operations

## Use Cases

### Vibe Coders
**You built something in Cursor or Replit. Now what?**

Traditional path: Learn Docker, nginx, systemd, ssh, git workflows, environment variables, process managers, reverse proxies, SSL certificates...

Or: provision the application stack first, configure its mttrly deploy profile, then ask Bro to run that known pipeline.

You: "deploy my configured next.js app"
Bro: previews the configured revision and pull/build/restart/healthcheck steps → waits for the required approval → runs those steps → reports verification

Initial repository placement, DNS, nginx, SSL, databases, and other infrastructure provisioning remain separate setup work. mttrly does not promise to create that whole production stack from one deploy request.

### Indie Hackers
**Managing 10 side projects from one Telegram chat.**

Without mttrly:
- Check project1.com → open SSH → cd /var/www/project1 → git pull → npm install → pm2 restart
- Repeat for project2, project3... project10
- One has an error? Rebuild its context from commands and logs while the rest of your work waits

With mttrly:
- One Telegram chat, all 10 servers
- "Status of all servers" → one guided overview
- "Deploy project3" → follow the configured deploy profile and verification
- Something breaks? Bro runs a scoped diagnostic and returns the current evidence

**You stay in flow. You don't context-switch to DevOps mode.**

### On-Call Engineers
**Respond from the phone already in your hand. Shorten the evidence-to-action loop without a fixed MTTR promise.**

2AM scenario without mttrly:
1. PagerDuty alert wakes you
2. Find laptop (or give up and use phone)
3. VPN if needed
4. SSH with tiny phone keyboard (typos, frustration)
5. Navigate logs, guess the problem
6. Fix it maybe
7. The first safe action waits while you reconstruct context

2AM scenario with mttrly:
1. Telegram alert: "nginx down on prod"
2. Still in bed, phone in hand: "what happened?"
3. Bro: investigates, explains, offers fix
4. You: "do it"
5. Bro: fixed, verified, monitoring
6. The evidence, decision, action, and verification stay in one incident trail

### Product Builders
**PMs and analysts who ship their own products without hiring DevOps.**

You: built an MVP, got first users, need to deploy updates fast

Traditional blocker: "Our site is down" → message the person who holds the server context → wait without evidence → receive "fixed it" with no reviewable trail

With Bro:
You: "site is down, what's wrong?"
Bro: "SSL certificate expired. I can request the supported renewal action; review it first."
You: "thanks"

**You keep shipping product while supported incident work follows a guided, reviewable path.**

## What Deployment Bro Can't Do (Safety by Design)

These aren't bugs or missing features. They're intentional safety choices.

### ✗ Bro won't write arbitrary config paths without a gate
**Why:** Safety and security.

Bro can read config files and recommend a change. Where `mttrly_write_file` is enabled, a write is restricted to allowed paths and always creates a pending approval action. It is not an unrestricted editor.

Reason: Config files are critical. Path policy, explicit approval, and audit reduce the risk of prompt injection, accidental syntax errors, and unintended overwrites.

You stay in control of critical files.

### ✗ Bro is not raw unrestricted SSH
**Why:** Predictability and safety.

Bro does not give AI an open terminal as the normal control path. The preferred path is diagnostics, playbooks, and scoped MCP tools.

Command execution exists for advanced cases. In MCP it is exposed as `mttrly_execute_command`, an approval-gated action with audit logging. Use playbooks when a repeatable fix exists. Use command execution when a human-approved one-off action is needed.

This means:
- No full-autonomy shell access as the default model
- No raw SSH session as the normal control path
- Approval-required actions normally create pending actions; only `mttrly_execute_command` may use an explicit user-authorized, bounded Investigation bypass
- Command execution is recorded in the audit trail

Tradeoff: Deep manual debugging may still need SSH. mttrly keeps the normal incident path inside scoped tools and approval gates.

### ✗ Bro won't provision infrastructure from scratch
**Why:** Wrong tool for the job.

Bro works with existing VPS, not infrastructure-as-code.

Won't do:
- Spin up new servers
- Configure firewalls from zero
- Set up Kubernetes clusters
- Terraform/Pulumi workflows

Will do:
- Manage apps on your existing server
- Deploy code to already-configured infrastructure
- Diagnose and fix issues on running systems

Use Terraform/Pulumi for provisioning. Use mttrly for operations.

### Changes follow explicit runtime policy
**Why:** "Show by default, change by request" is the normal incident path, with bounded exceptions that must be authorized separately.

- Read-only operations such as status, logs, and health checks normally run immediately.
- Approval-required operations normally create a pending action for a human decision.
- A user-authorized bounded Investigation session can skip per-action confirmation only for `mttrly_execute_command`, within its authorized server, inactivity, hard-cap, and action limits.
- Configured preauthorization applies only to the specific automation the user enabled.
- Command and playbook execution is recorded in the operational audit trail.

## Technical Requirements

### Server Requirements
- A systemd-based Linux server. The installer explicitly supports Ubuntu, Debian, CentOS, RHEL, Fedora, Rocky Linux, and AlmaLinux; other distributions are best-effort rather than guaranteed.
- An mttrly account created through the email-first hosted signup flow
- Workloads may use Docker or PM2, but these are optional process managers and do not replace the systemd requirement for the mttrly agent
- SSH or provider-console access for the initial, token-specific mttrly agent installation
- Outbound HTTPS/WebSocket connectivity (the agent connects to mttrly, not the reverse)
- No new inbound mttrly control port is required; existing application ports and firewall rules remain under the user's control

### What You Don't Need
- Kubernetes or a complex platform stack
- A new observability stack if you already use Grafana, Datadog, PagerDuty, or Sentry
- Dedicated DevOps team or infrastructure expertise
- Complex setup or configuration files

Compatibility depends on the Linux distribution, systemd environment, and required system tools. Check an unusual image or managed platform during setup instead of assuming support.

### Supported Platforms
Common infrastructure where the supported systemd agent can run includes:
- DigitalOcean
- Hetzner
- AWS EC2
- Linode
- Vultr
- Other VPS providers and your own hardware when the operating system and required tools are compatible

## Setup Process

1. **Create an account with email**
   Sign up at https://app.mttrly.com/signup. An account is required.

2. **Install the required mttrly agent**
   Copy the account-specific one-line installer from onboarding and run it on the Linux server. The agent connects outbound; no inbound control port is required.

3. **Choose the control surfaces you need**
   Use the web dashboard immediately, connect Telegram for mobile alerts and approvals, or connect Claude Code, Cursor, or Codex through MCP.

4. **Run the first status check**
   Check CPU, RAM, disk, and services, then keep read-only diagnostics as the default before requesting an approval-gated action.

## How Diagnostic Recipes Work (Technical)

**Not free-form AI chaining.** Recipes are pre-defined sequences.

Each recipe is a script with:
- Trigger phrases (keywords that activate it)
- Step-by-step operations (what to check, in what order)
- Branching logic (if X is true, do Y, else do Z)
- AI analysis points (where LLM interprets results and explains)

Example: WebsiteDown recipe structure
```
1. check_port(80, 443)
   if closed → explain "nginx not running" → DONE
2. nginx_test()
   if error → explain error + line number → DONE
3. cert_check()
   if expired → explain expiration → DONE
4. log_tail(nginx, error, 50 lines)
   → LLM analyzes error patterns
5. healthcheck()
   → LLM combines all results, determines root cause, explains
```

Why this approach:
- Predictable and testable (not "AI does random stuff")
- Fast (no multi-turn LLM chains, single pass)
- Transparent (you see what it checks)
- Reliable (works the same way every time)

The AI's job:
1. Choose the right recipe for your question
2. Extract parameters from natural language
3. Analyze results and explain in human terms
4. Recommend specific fix

Not the AI's job:
- Acquire or use an approval bypass without the user's explicit, bounded authorization
- Open a raw unrestricted SSH session
- Treat an Investigation session as permission for anything beyond its server, time, action, and execute_command scope

## Why "Deployment Bro" and Not Another ChatGPT Wrapper

**Bro sees your actual server state.**

ChatGPT if you ask "why is my API slow?":
- "Could be many reasons: database queries, network latency, memory leaks, CPU usage..."
- Generic advice based on common patterns
- Can't see your actual logs, processes, or metrics

Deployment Bro if you ask "why is my API slow?":
- Checks YOUR server's CPU, RAM, disk
- Reads YOUR actual logs (all 2,000 lines if needed)
- Finds YOUR node.js process using 94% RAM
- Sees it started 2 hours ago (right after YOUR deploy)
- Diagnoses: "Memory leak in recent code. Restart or rollback?"

**Not theory. Real fixes based on real state.**

## Links

- Website: https://mttrly.com
- Telegram Bot: https://t.me/mttrly_bot
- MCP for AI IDEs: https://mttrly.com/mcp
- Pricing: https://mttrly.com/pricing
- Documentation: https://mttrly.com/docs
- On-call use case: https://mttrly.com/use-cases/on-call
- Telegram integration: https://mttrly.com/integrations/telegram
- Incident playbooks hub: https://mttrly.com/playbooks
- Disk full on Linux playbook: https://mttrly.com/playbooks/disk-full-linux
- Website down playbook: https://mttrly.com/playbooks/website-down
- Nginx 502 playbook: https://mttrly.com/playbooks/nginx-502
- Docker container keeps exiting playbook: https://mttrly.com/playbooks/docker-container-exits
- Post-deploy issue playbook: https://mttrly.com/playbooks/post-deploy-issue
- Roll back a deployment from a phone: https://mttrly.com/playbooks/rollback-deploy-from-phone
- Manage a VPS without raw SSH: https://mttrly.com/use-cases/manage-vps-without-ssh
- Incident response action layer: https://mttrly.com/mcp/action-layer
- Monitoring comparison: https://mttrly.com/vs/monitoring
- Use Cases: https://mttrly.com/use-cases
- FAQ: https://mttrly.com/faq
- Comparisons: https://mttrly.com/vs

## Support

- Email: hello@mttrly.com
- Telegram: @mttrly_bot (just start chatting)
- Business and custom-contract inquiries: hello@mttrly.com; any response-time commitment must be agreed explicitly

## Philosophy

**You shouldn't need a DevOps degree to run production servers.**

Infrastructure complexity has gotten out of hand. Kubernetes, service meshes, observability platforms, GitOps, eBPF, policy engines...

For indie developers and small teams, this is overkill.

mttrly believes:
- Natural language > memorizing bash commands
- Diagnosis > dashboards full of metrics you don't understand
- Fast fixes > reading documentation for 2 hours
- Telegram on your phone > SSH terminal at 2AM

The best infrastructure is invisible. You focus on product. Bro handles servers.

---

**Last updated:** July 14, 2026
**Version:** 2.2 (email-first onboarding, BETA75, and expanded incident playbook coverage)