Is remote terminal access safe? How TermLink is built
Your machine dials out and nothing listens for inbound connections, so none of it is reachable from the internet. Here is what that covers, and what it does not.
- Inbound ports opened
- None
- Connection direction
- Outbound only, your machine to the relay
- Transport
- WSS (WebSocket over TLS)
- Sign-in
- Google, once per machine
- Credentials on disk
- ~/.termlink, owner-only (0600)
- Terminal output stored by us
- None
- Who can list your machines
- Your Google account only
- Signing a machine out
- termlink devices --revoke
The part most pages leave out
TermLink is not end-to-end encrypted. Traffic runs over TLS, but the relay terminates it, which means the relay handles your terminal bytes in the clear in order to route them. That is the honest cost of reaching a terminal from a browser with nothing installed on it.
What we can tell you is what happens to those bytes: they are forwarded from memory to whoever is connected, and then they are gone. Nothing is written to disk, and there is no recording, no transcript, and no scrollback held on our side. If that trade is the wrong one for your work, SSH on a machine you control is the right tool and we would rather you use it.
Do I need to open a port or expose my machine?
No. The host process only ever dials out to the TermLink relay over WSS and keeps that connection alive. It never listens for an inbound connection, so there is no port to forward, no firewall rule to add, and no VPN. Nothing about your machine becomes reachable from the internet.
This is also why it keeps working on a laptop that moves between networks: there is no address for anyone to reach, and the machine simply re-establishes its own outbound connection wherever it lands. How TermLink works walks through the same connection from the setup side.
How do you know it is me?
You sign in with Google once, on the machine. That sign-in is traded for a device token issued to your account, and the Google credential is then deleted from disk. Every later launch authenticates with the device token, so a machine never needs Google again.
Removing the Google credential is the point rather than tidiness. While a refresh token stays on a machine, that machine can re-enrol itself the moment you revoke it, which would make revocation theatre.
Opening a specific terminal narrows the credential again: what travels to the relay carrying your session is a token scoped to that one session id, minted fresh each time a host starts. When the session ends, it authorizes nothing.
What can the relay see, and what does it keep?
It can see the terminal stream, because it has to route it. It keeps none of it. Frames pass through memory to the connected clients and are never written to disk.
Three things are stored, none of which is terminal content: the machines enrolled on your account, so you can sign a lost one out; any session-sharing grants you create; and the relay pool itself. Product analytics record that a session started, along with the host operating system and architecture — never what ran in it.
The relay source is public if you would rather read it than take our word: github.com/bertshim/termlink-relay.
Where do my credentials live on the machine?
In ~/.termlink — the same place on macOS, Linux and Windows, deliberately, so it sits beside ~/.ssh and ~/.aws where you would look for it. The directory is created 0700 and the files are written 0600, so only your user account can read them.
Treat device.json the way you would treat a private key: it is a bearer credential, and anything holding it can open terminals as you until the device is revoked. That is precisely what termlink devices --revoke is for.
Can someone else open my terminal?
Only if they can sign in as you, or if you explicitly share a session with them. Your machines are listed under your Google account and nothing else resolves them.
Sharing is worth being blunt about. A grant gives the guest full write access to that one terminal for as long as the host process lives — there is no read-only mode yet and no locking, so two people typing at once interleave exactly as they would in a shared tmux. Share with someone you would hand your keyboard to, and nobody else.
A grant is pinned to a session id, and session ids are minted fresh on every host launch, so it dies with the session rather than lingering as a standing invitation.
How do I sign out a machine I no longer have?
Run termlink devices to see every enrolled machine with its hostname and when it was last seen, then termlink devices --revoke <id> for one, or --revoke-all for all of them, this one included.
Revocation is checked on every request rather than at expiry, so a revoked machine loses access on its next attempt. There is no window to wait out.
termlink logout does both halves in the safe order: it revokes the enrolment on the server first and only then clears the local files, so a failed network call can never leave you told-you-are-out with a working credential still enrolled.
What happens to a running session if I lose the connection?
Nothing. The session lives in the host process on your own machine, not in the browser tab, so closing the tab or dropping off the network leaves the work running.
When you reconnect, the host repaints the current screen from state it kept locally, terminal UI and all. The screen is reconstructed on your machine — it is not replayed out of a buffer on our servers, because there is no such buffer.
The one requirement is that the host process keeps running. TermLink is not a background daemon: close the terminal it runs in and the machine goes offline until you start it again. You can also end a live session deliberately from the machine list, which tells the session to terminate rather than merely cutting its socket.
What is not here yet?
Stated plainly, so you can decide rather than discover: no end-to-end encryption, no read-only session sharing, and no third-party security certification.
TermLink is a small product and these are real limits rather than roadmap language. If any of them is disqualifying for your work, that is a reasonable conclusion to reach from this page, which is why the page exists.
Register the machine your code lives on, and open its terminal from anywhere. Or read how the connection is set up.