Hosted service

roder-hosted runs Roder as a multi-tenant gateway. Many tenants share one process, but each tenant gets its own runtime, thread store, artifact store, automation database, and notification stream.

Remote modes compared

• Trusted LAN remote: one user, one bearer token, trusted network.
• Agent node: machine-to-machine mTLS with pinned certificates.
• Hosted service: multi-tenant credentials, per-request authorization, and tenant-scoped runtimes.

Configuration sketch

listen = "127.0.0.1:7900"
data_root = "/var/lib/roder-hosted"
allow_local_workspaces = false
idle_ttl_secs = 900

[[tenants]]
id = "acme"
display_name = "Acme"

[[static_keys]]
token_env = "RODER_HOSTED_KEY_ACME_ADMIN"
tenant = "acme"
user = "ops"
role = "tenant_admin"
scopes = ["read", "write", "admin"]

The gateway authenticates before dispatch, authorizes every request by scope and role, records redacted audit JSONL, and supports tenant webhooks with HMAC signatures, retries, circuit breakers, and dead-letter records.

Request security

• Browser WebSockets authenticate with the roder.remote.v1 and bearer.<token> subprotocols; native clients can use bearer headers.
• Open sockets revalidate credentials before dispatch and while idle, so expiry or service-account revocation stops requests and notifications.
• Deployment request policy can rewrite or deny JSON-RPC calls before runtime dispatch, while health probes remain open for schedulers.
• Externally resolved tenant ids use collision-resistant data directories; existing lowercase slug tenants keep their current paths.