DEV Community

Javier Leandro Arancibia
Javier Leandro Arancibia

Posted on

rcmd: I replaced SSH with a relay — now my AI agents manage my servers

#ssh #devops #saas #productivity

I run a small infrastructure. A few VPS, some Proxmox boxes, a Raspberry Pi. Every time I needed to run a command on a remote machine, it was the same ritual: SSH key, port, firewall, VPN if the box is behind NAT. And my AI agents? They couldn't do any of it without me handing them SSH keys or setting up tunnels.

So I built rcmd — a zero-config remote command execution tool. No SSH keys, no open ports, no VPN. A WebSocket relay brokers connections between your machine and remote targets. The daemon on the target connects outbound. You run the CLI. The relay routes the command.

You ──wss──► relay ──wss──► target daemon (runs your command, returns output)
Enter fullscreen mode Exit fullscreen mode

What shipped this week

Scheduled commands (cron) 

rcmd cron add --target prod --schedule "0 3 * * *" --cmd "docker restart app"
rcmd cron list
rcmd cron logs --id <job-id>
Enter fullscreen mode Exit fullscreen mode

The relay runs a scheduler goroutine. When a job fires, it forwards the command to the target daemon. If the target is offline, the run is logged as "skipped" — no retry queue, the next tick tries again. History persists across relay restarts.

This replaces the crontab + SSH + monitoring script combo with one command.

Port forwarding (tunnel) 

rcmd tunnel --target db --local 5432 --remote 127.0.0.1:5432
Enter fullscreen mode Exit fullscreen mode

Forwards a local port to a remote address through the target daemon. Replaces ssh -L. Useful for reaching a database or service that's only listening on localhost on the remote machine.

Team access

This is the one I'm most excited about. The problem: one token = full access to all targets. If you want a teammate or an AI agent to run commands, you either share your master token (security nightmare) or set up a separate account (no shared targets).

Now you generate scoped sub-tokens:

# Give an operator access to prod + staging
rcmd team token --role operator --targets prod,staging --label "Bob" --expires 24h

# Bob runs:
rcmd login tok_operator_abc123...
# His access is scoped — he can only touch prod + staging, all audited
Enter fullscreen mode Exit fullscreen mode

Three roles: admin (everything except billing), operator (exec, copy, tunnel, cron on assigned targets), viewer (read-only — list targets, check health, view cron logs).

Every command execution is recorded in the audit log:

rcmd team audit --target prod --since 24h
Enter fullscreen mode Exit fullscreen mode

Email invites 

rcmd team invite --email bob@company.com --role operator --targets prod,staging --label "Bob"
Enter fullscreen mode Exit fullscreen mode

Sends an HTML email with a 7-day invite code. Bob clicks the link, sees a page with the accept command and a copy-to-clipboard button, runs:

rcmd team accept inv_5b97e6eeb72d
Enter fullscreen mode Exit fullscreen mode

Gets a scoped sub-token. Done.

Agent-first discovery

This is the part that matters if you're building tools for AI agents. rcmd is designed to be operated by agents, not just humans. So I added three discovery surfaces:

  • /llms.txt — a short breadcrumb at rcmd.intrane.fr/llms.txt. An AI assistant that only knows the domain fetches this and gets oriented.
  • /guide — the full operator reference. Every command, every flag, cron scheduling, tunnels, team access, JSON output format, exit codes, gotchas.
  • rcmd guide — CLI subcommand that prints the same guide locally. An agent on a machine with rcmd installed runs this to learn the full feature surface.

The pattern: an agent finds itself on a machine with rcmd → runs rcmd guide → learns everything. An agent that only knows the domain → fetches /llms.txt → gets pointed to /guide.

Why no SSH?

SSH is designed for humans typing into terminals. It's not designed for:

  • Agents that need to run commands programmatically and parse output
  • NAT traversal — if the target is behind NAT, you need a VPN or a jump host
  • Scoped access — SSH keys grant full shell access; there's no easy way to say "this agent can only restart this one service on this one server"
  • Audit trails — SSH logs connections, not commands (unless you set up auditd or similar)

rcmd solves these by moving the routing to a relay. The daemon connects outbound (no firewall changes). Tokens are scoped (admin/operator/viewer, target-restricted). Every command is audited. And the CLI is designed for agents — JSON output, semantic exit codes, a guide command that teaches the agent everything it can do.

The stack

  • Go binary, single file, ~7MB stripped
  • WebSocket relay (runs on a VPS, behind Traefik + Let's Encrypt)
  • JSON file storage (no database — teams, cron jobs, audit logs, customers)
  • Resend for transactional email (team invites)
  • Stripe for billing (Pro tier)
  • 21 unit tests, all passing

Try it 

curl -fsSL https://rcmd.intrane.fr/install.sh | sh
rcmd signup --email you@example.com
Enter fullscreen mode Exit fullscreen mode

The free tier gives you the relay. Pro adds scheduled commands, tunnels, and team access.

Full reference: rcmd guide or https://rcmd.intrane.fr/guide

GitHub: https://github.com/javimosch/remotecmd-cloud

Built by Javier Leandro Arancibia — making infrastructure agent-first, one tool at a time.

Top comments (1)

Collapse
 
fromzerotoship profile image
FromZeroToShip •

"SSH is designed for humans typing into terminals, not for agents that need to run commands programmatically." I arrived at the exact same wall from the low-tech end, and your framing is the cleanest statement of it I've seen.

I'm a non-developer building tools for a hospital with AI, and my AI assistant can't SSH into our NAS at all — for good security reasons I agree with. So we built the world's dumbest version of your relay: the agent writes a command, I run it with a one-character wrapper that redirects output to a file on a share both sides can see, and the agent reads the result from there. No ports, no keys handed to the model, output flows back through a plain file channel. It's crude next to a WebSocket broker with scoped tokens, but the shape is identical — an outbound-only path and a relay surface instead of the agent holding SSH itself.

What your writeup makes me want is the part I skipped: the audit log. My file-relay has no record of what ran, and "every command execution is recorded" is exactly the guardrail that turns "the agent can touch prod" from scary into accountable. An agent with server access without an audit trail is a nice day until the one day it isn't. Adding a command log to my relay this week.

The "agent runs rcmd guide and learns everything" discovery surface is also smart — self-documenting infra is the difference between a tool an agent can use and one it can only fumble. Great build.