The relay helps your phone find your computer. It handles pairing, encrypted WebRTC signaling, fallback and notifications. Once a direct connection is established, terminal traffic flows between the devices. The relay stays available when it’s needed.
Reads your terminal.
Encrypts screen updates.
Accepts authenticated input.
Decrypts screen updates.
Renders the terminal.
Encrypts your replies.
Once WebRTC connects, screens, history and input travel directly between your devices. The relay stays connected for pairing, encrypted signaling, revocation and push.
If the direct connection is blocked or drops, encrypted terminal traffic uses the relay. Shellbell retries WebRTC while you’re using the app.
Your terminal content stays encrypted on both routes. Transport details
Encryption protects your terminal content. The relay still needs some metadata to connect devices and deliver notifications.
Run independently of the project’s hosted relay. The same shared core handles authentication, pairing, revocation, limits, and notification policy in both runtimes.
The relay source is free and open source. Your hosting resources, quotas, domain, and notification credentials are your responsibility. Another runtime can use the relay adapter contracts, with its own validation.
Organizations can control the relay hostname, hosting account, metadata, backups, and operational policies without sending terminal content to a third-party relay operator.
Choose an organization-owned WSS endpoint that your computers and phones can reach. Set access to the hosting account, retention, backup protection, monitoring, and upgrade procedures around your requirements.
Organization operations guideThe relay authenticates paired devices. It does not add organization SSO, centralized enrollment, administrator accounts, or read-only terminal roles. Pairing grants control over the sessions exposed by that computer’s OS user.
Use Relay address in the Mac app, or save the address with the CLI below. Restart the computer service to apply it. A new pairing QR includes that address; existing phone records also have a Relay URL setting.
❯ shellbell config set relay wss://relay.example.comBoth endpoints must use the same relay. Moving to an empty relay can require pairing again; metadata is not automatically migrated.
Self-hosting does not remove every external dependency. Background notifications use Apple APNs or Google FCM. Your own relay needs matching app identities, builds, and provider credentials for push. The stock app can use your relay for terminal access without that push configuration.
The details matter when you’re choosing where your connections should go.
No. Terminal content is encrypted between your paired phone and computer. The relay does not receive the keys needed to decrypt it. It can see the connection and routing metadata described above.
No. It does not persist terminal transcripts or queue terminal screens for offline replay. History comes from the computer while it is reachable. Pending private notification ciphertext can be held temporarily, within a bounded notification job.
No. WebRTC carries screens, history and input between the paired devices once the direct connection is established. Both relay WebSockets stay open for coordination, and encrypted terminal traffic returns to the relay if the direct route fails. Shellbell retries the direct connection while the app is open. See the connection guide.
No. It gives you control over relay hosting and metadata. It does not establish an independent security audit, regulatory certification, or protection from a compromised paired device. Assess your device software, administrator access, network policy, and deployment against your organization’s requirements.
Measure your own connection counts, traffic, fallback bursts, storage, and notification behavior. There is no universal users-per-server guarantee. The capacity guide and operations guide cover planning, rollout, backups, and recovery.
Free to use. Pair once, then return to the sessions you already have.