Skip to main content
Security is taken extremely seriously at RelayCloud. This page describes how RelayCloud applies controls at the organization, token, resource, and transport layers. The exact permissions available to an account can depend on enabled organization features and subscription state.

​
Authentication

  • Web sessions support password authentication, email verification, password confirmation for sensitive flows, and passkeys.
  • Assistant relay authorization uses a short-lived RS256 JWT scoped to the specific server and assistant the user is authorized to connect to.
  • Orchestrator daemon authentication uses the OAuth client-credentials flow. Each server gets its own dedicated client credentials.

​
Authorization and tenant isolation

  • Every request is associated with an organization and checked against your membership.
  • Organization membership is checked before access is granted.
  • Resources are isolated by organization. A global scope on all queries enforces this isolation at the database layer.

​
MCP protection

The MCP endpoint requires an authenticated access token with the correct scopes. Each request is checked against the selected organization and any resource restrictions on the token before a tool runs. Tool actions also require the appropriate permission.

​
Device and provisioning security

  • The device installer downloads over HTTPS and verifies the selected binary with SHA-256 before installation. A failed checksum leaves the existing installation untouched.
  • The installer uses a temporary directory and installs the binary atomically into ${XDG_BIN_HOME:-$HOME/.local/bin}/relaycloud.
  • Device authentication is stored under ${XDG_DATA_HOME:-$HOME/.local/share}/relaycloud/auth.json with an owner-only directory and file mode 0600.
  • OpenCode credentials are stored separately from local assistant registrations, with owner-only file permissions, and are not printed by the TUI.
  • Server provisioning callbacks use signed URLs.
  • Generated server provisioning logs are written with restrictive permissions.

​
Server hardening

Every managed server that RelayCloud provisions is hardened automatically:
  • RelayCloud issues a unique SSH key for each server and connects as root only when managing or updating the server on your behalf.
  • UFW is configured to block incoming traffic by default, then explicitly open only ports 22, 80, and 443.
  • Automated security updates are enabled using Ubuntu’s unattended-upgrades.
  • Password-based SSH authentication is disabled.
  • The Orchestrator daemon runs under a dedicated relaycloud user, since it does not need full root privileges.
  • Each Unix user a workspace is deployed to gets a VCS Agent running as that user, which allows the daemon to run an allowlisted set of commands as that Unix user. All commands are git, with these subcommands supported: status, diff, stage, unstage, commit, log, push, pull, checkout, and branches.
    • This lets RelayCloud run git commands as the workspace’s user without giving the relaycloud user full filesystem access. The daemon and VCS Agent communicate over an authenticated local socket, and each Unix user gets its own randomly generated token for authentication.

​
Network and browser protections

  • Browser responses use Content Security Policy headers, including script nonces and explicit connection policies.
  • Session cookies are HTTP-only.
  • The relay only receives the short-lived assistant token needed for the selected resource.
  • OpenCode discovery probes loopback endpoints only. It does not scan arbitrary network hosts or ports.

​
Operational boundaries

Self-managed servers remain under your control. On macOS, the user-level LaunchAgent runs in the GUI login session. On Linux, the Orchestrator enables lingering for your user if possible so the service keeps running after you log out.