The relayyour fleet runs on
cmdop server is the agent relay hub — the foundation a fleet of machines connects to. Agents dial out (no inbound ports, NAT-friendly); clients reach them over REST and WebSocket. Multi-tenant by design, and yours to self-host.
Six processes, one relay
The relay is a handful of focused processes you run together. Agents speak gRPC; clients speak REST and WebSocket; everything is fleet-scoped and audited.
api_serverThe client-facing REST surface — auth, presence, machine and fleet reads, the control plane your apps and SDK call.
grpc_serverThe agent transport. Machines dial out and hold a bidirectional stream — terminal, exec and file ops flow here.
ws_gatewayThe push channel. Streams live output, presence and events to connected clients over WebSocket.
tunnel_serverSecure tunnels to services behind a machine — reach a private port without opening one to the internet.
workerThe background worker — schedules, deferred jobs and housekeeping run off the request path.
jarvis_serverA server-side AI agent that joins the relay as a virtual machine and coordinates the fleet.
The gRPC contract lives in proto/ (cmdop.agent.v1) and is the single source of truth — the Go agent stubs are generated from it.
See the relayfrom the inside
Every screenshot below is the real cmdop server admin console — the operator surface you get when you self-host the relay.
One console for the whole plane
System health for all six processes, machines, active sessions, LLM spend and errors — the whole relay at a glance.
Your fleet, as a table
Every connected machine with presence, OS and last-seen — including Jarvis as an always-on server-side agent.
Live gRPC metrics
Active streams, RPC totals, latency percentiles and success/error rates — streamed live over WebSocket.
The LLM gateway
The OpenAI-compatible /v1 gateway: providers, keys, models and per-fleet spend, all governed in one place.
A server-side fleet agent
Jarvis joins the relay as a virtual machine and coordinates the fleet — ask it to run commands or check logs across every machine.
Issue and revoke access
Mint the relay CLI tokens machines connect with, and revoke them the moment a machine should drop off the network.
Agents dial out.No inbound ports.
Every machine opens an outbound gRPC stream to the relay and stays reachable through it — there is no listening port to expose, no firewall hole, no NAT traversal to babysit. The relay routes messages between agents and clients; the machines never accept inbound connections.
Multi-tenantby design
Fleets are isolated at the database, not just in app code. Postgres row-level security partitions every table by fleet_id, so one relay can host many fleets with hard tenant boundaries — presence, audit and history never cross fleets.
A coordinatorthat lives in the relay
Jarvis is a server-side AI agent that joins the relay as a virtual machine peer. Fleet-scoped and always on, it can reach the other agents — ask one, broadcast to many — and coordinate work across the fleet without anything running on your own box.
An OpenAI-compatiblegateway at /v1
The relay exposes inference at /v1 — chat completions, embeddings and models — speaking the OpenAI wire format. The server holds the provider keys and routes per fleet with spend and quota, so agents get one bearer-authenticated endpoint instead of a pile of vendor credentials.
Run your own backbone
cmdop server ships as a self-hostable product. Bring it up with the Docker compose relay group, or run it on Kubernetes — you own the data, the keys and the fleet. No machine ever leaves your network unless you route it there.
Production runs the relay compose group (api · grpc · ws · tunnel · worker · jarvis) behind a single edge; the same processes deploy to Kubernetes when you want autoscaling and rolling upgrades.
Run the fleetbackbone yourself
Spin up the relay, point your agents at it, and own the whole plane end to end.