The machine is behind a firewall. You still get a root shell.

Who it is for

One operator, N machines that live in awkward places.

A Windows server in an office behind a consumer router. A Mac mini at a colleague's house. A Linux box on a carrier-grade NAT mobile connection. A kiosk in a shop with an ISP router nobody has the password for.

The conventional answers all need infrastructure you then own: a jump host, a VPN concentrator, a coordination server, or an inbound port forward that someone has to configure and keep secure. RelayKey needs none of them, and deliberately does not try to be a fleet-management platform: there is no org directory and no RBAC. It is a tool for one person who has to get into their own machines.

How it works

The wire, annotated.

Three parties, and only outbound connections. Below each one is what it can actually observe — including the part most tools leave out.

Then the channel upgrades

Relays are fine for “run this and show me the output” and hopeless for a screen: every message is a signed, double-encrypted envelope that round-trips through a relay. So for anything interactive, the relay channel carries only the WebRTC offer, answer and ICE candidates, and the session itself moves onto a data channel — directly between the two machines wherever the network allows it.

What you get

A console, then real sockets.

Why no backend matters

Nothing to breach, nothing to bill, nothing to switch off.

“No backend” is not a slogan here, it is a property with three consequences a technical buyer can check.

There is no account database, so there is nothing of yours to leak. Your identity is an account key generated on your device by the OS random source. We do not have it, cannot reset it, and cannot be compelled to hand over a list of your machines, because no such list exists outside your own client.

The rendezvous layer is interchangeable. The message relays are public, accept messages from any account without registration, and there are dozens of them. If one disappears or blocks you, you change a config line. If you would rather not use public ones at all, point the agent at a private one you run.

Nobody's hosting bill is between you and your machines. The one place we do spend money is the shared TURN relay used when a direct connection is impossible, which is why that path is rate-limited and best-effort — and why bringing your own relay is a documented, first-class setting rather than an enterprise upsell.

Download · v0.4.1

Two roles. Pick both.

An agent runs on a machine you want to control. A client is what you drive it from. Assets are named relaykey-<role>-<interface>-<os>-<arch>, where gui is a double-click app and cli is headless — for servers and services.

Security, stated plainly

This grants remote SYSTEM over the public internet.

The honest framing, and the one used in RelayKey's own security document, is that this is a remote access tool with the operator's consent, and it deserves to be designed like one — including being clear about what it does not protect against. If you are evaluating it, read this section before the feature list.

What is protected

Command and output confidentiality against relay operators and network observers. Authorisation: only paired peers can execute anything, and that mutual knowledge of each other's public key is the entire authorisation model. And the pairing moment, which is the only point where a secret crosses an untrusted path.

The sharp edge: the pair code

The pair code is 8 characters — short because it has to be typed, pasted into an install command, and sometimes read aloud. Anyone who obtains it while it is live can pair with the machine and thereby gain SYSTEM. That is inherent to having no server to authenticate against, not an oversight, and it is bounded by six layered controls: single use, a one-hour expiry, proof-of-work on the enrolment beacon, a 20-attempt budget after which the agent burns the code and logs loudly, handshake HMACs proving both sides hold the code, and the six-digit string you compare by eye.

Proof-of-work is a cost multiplier, not a wall — someone with a hundred machines gets a hundred times the guesses. The attempt budget is the hard cap. And if the code leaks, the attacker pairs first, and you never look at the machine's console, the machine is compromised. The mitigation is operational: generate the code on the machine, use it immediately, check the digits.

What a message relay learns

For each message, a relay sees that some key published an envelope addressed to a recipient, at a particular arrival time, of a particular size. The outer signing key is fresh every time, so envelopes cannot be grouped by sender, and the timestamp the sender writes on the envelope is randomised into the previous 48 hours. But traffic analysis by timing and volume is not defeated: arrival time at the relay is real, a relay operator watching a live connection sees a request arrive and a response depart shortly after, and correlating a burst of envelopes to one public key with a burst to another plausibly reveals that two parties are in session. Size leaks too — the encryption layer pads onto a coarse ladder, which blurs but does not hide the difference between an idle keepalive and a 24 KB output chunk. Publishing to four independent relays helps only against any single one of them.

The explicit non-guarantees

• No forward secrecy. Encryption uses static ECDH between long-term keys. An attacker who records traffic today and obtains a private key later can decrypt what they recorded.
• No post-compromise security. Once a key leaks, every future message is readable until you re-pair.
• No revocation broadcast. Revoking is local state on each machine. A stolen client means visiting every machine.
• No protection against a relay withholding messages. A relay can silently drop; your client sees a timeout. Using several independent relays is the only mitigation.
• No sandbox. Commands run with the service's full privileges, by design.
• No metadata hiding at the timing and volume level. See above. Padding everything to a fixed size would make the tool unusably slow on relays that rate-limit by bandwidth.
• The command denylist is not a security boundary, and the code, docs and CLI help all say so. Anyone who can run one command as SYSTEM can rewrite the config. Its job is to catch a mistake, not an adversary.

Two more things worth knowing before you deploy

The audit log records full command text, including any secret you paste into a command. That is a deliberate trade — an admin tool with no record of what was run is unauditable — and the log lives in a SYSTEM/root-only directory. Set log.audit: false to log metadata without command bodies.

Remote self-update of the agent is off by default. It requires an explicit config change on the machine and verifies a signature over the release artifact. It is the highest-value target in the system and is treated as such.

Your exported account file is the account. The default export format is passphrase-encrypted (scrypt + XChaCha20-Poly1305, tuned to about a second), export requires re-authentication, and the bundle carries your peer list as well as the key — which is a further reason the whole payload is encrypted rather than just the key. Restoring it on a new machine does not invalidate the old copy: both hold the same key, and both work.

Licensing

Free for five machines. A licence raises the number.

Every client enforces a default allowance of five paired machines with no licence at all — not a trial, and not a reduced feature set. A licence does exactly one thing: it raises that number for your account. Entitlement is keyed to your Public ID, so it follows your account rather than a device, and moves with it when you restore on a new machine.