The relay
Sometimes neither your local network nor a tailnet connects you to your host — a hotel network, a locked-down office, cellular behind carrier NAT. The relay is the path that works anyway.
It is optional, switchable per host, and deliberately built so that switching it on does not require trusting us with your work.
What it is
Section titled “What it is”A thin pipe. Both your device and your host make an outbound connection to it on port 443, and it forwards bytes between them.
That is the whole job. It does not terminate your session, does not run anything, and does not store your work.
What runs inside it
Section titled “What runs inside it”Unmodified SSH. The relay carries an SSH connection between your device and your host’s agent, exactly the same connection that runs over your local network — the transport underneath is the only thing that changed.
So the relay sees SSH ciphertext. It cannot read your terminal, your prompts, your code or your keys, because it never holds the keys that would decrypt them.
Your clients additionally pin the host key. A compromised relay could not impersonate your host even if it tried: the pin would not match and the client would refuse.
What it can see
Section titled “What it can see”Being precise about this is more useful than reassurance:
| Can see | Cannot see |
|---|---|
| That a pairing connected, and when | Anything inside the session |
| How many bytes flowed | What those bytes are |
| The IP addresses of both ends | Your code, prompts, output or credentials |
The realistic worst case for a compromised relay is denial of service and connection metadata — never content.
No open port on your host
Section titled “No open port on your host”Because both sides dial out, your host does not need an inbound port. sshd
stays unreachable from the internet, your router needs no forwarding rule, and
there is no public endpoint to find or attack.
Switching it off
Section titled “Switching it off”Per host, in the host’s settings. With the relay off, that host is reachable on your local network and over Tailscale only — everything else works unchanged, including pairing.
Details
Section titled “Details”- Implementation: Cloudflare Workers plus one Durable Object per pairing
(
idFromName(pairingId)), acting as a byte pipe with a small buffer for whichever side arrives first. - Access requires pairing authentication — challenge/response against the Ed25519 device keys your devices already use, with the registry in the Durable Object’s storage. An unknown device cannot open a pipe.
- Latency through the relay is roughly 90 ms in a worst-case measurement with both ends on the same machine (four legs). Real phone-to-Mac paths tend to be better. The connection pill shows the real number.
- The relay is transport-neutral by design — the protocol is trivial enough that moving it onto our own servers later would change nothing for your clients.
- Push notifications are a separate channel (Firebase) and, unlike the relay, not end-to-end blind: they carry readable text — the session and workspace names — because a lock screen has to display it. Never session content. See Notifications.
- Offsite runs no analytics SDK and no crash reporter. See Security and privacy.