Phone or desktop client → WebSocket relay → daemon on your computer → Claude Code or Codex CLI. Content is end-to-end encrypted between client and daemon.
The four components
| Component | Where it runs | Responsibility |
|---|---|---|
| Client | Phone, tablet, or another computer | Shows sessions, sends input, and displays approval requests |
| Relay | Public server | Authenticates connections and routes encrypted frames |
| Daemon | Your coding computer | Maintains the encrypted endpoint and drives the local CLI |
| Coding agent | Your coding computer | Claude Code or Codex reads and edits the selected project |
Hosted relay or your relay?
The default service minimizes setup. Running your own relay gives you operational control over availability, logs, network policy, updates, and retained routing records. End-to-end encryption is still necessary in either case because the relay remains outside the trusted content endpoints.
Self-hosting does not eliminate metadata visible to the relay operator: source IPs, connection times, account-to-device routing, and ciphertext size and timing remain observable.
Deployment shape
The repository provides a Java 17 relay distribution, a hardened systemd unit, and a Caddy reverse-proxy example. The reference layout binds the Kotlin/Ktor relay to loopback, stores routing state in SQLite, and lets Caddy provide public TLS and WebSocket proxying.
- Build the relay distribution from the tagged source.
- Run it as a dedicated, unprivileged service account with a persistent SQLite directory.
- Place a TLS reverse proxy in front of the loopback listener.
- Point the daemon and client pairing flow at your
wss://relay URL. - Monitor the health endpoint, logs, certificate renewal, storage, and upgrade process.
Use the version-matched deployment files rather than copying commands from this overview.
What you become responsible for
- TLS certificates, DNS, WebSocket proxying, and public network exposure.
- Java and relay upgrades, backups of routing state, and service monitoring.
- Rate limits, logs, access to metadata, and incident response.
- Keeping daemon and client configurations pointed at the same relay.
Self-hosting is an infrastructure task. Incorrect TLS, database permissions, proxy timeouts, or upgrade procedures can cause outages. Review the deployment and security documents before exposing a relay publicly.