Learn
How does end-to-end encrypted terminal sync work?
End-to-end encrypted terminal sync means the machine running your shell encrypts every frame before it leaves, and only your own devices can decrypt them. The server in the middle relays and stores ciphertext it cannot read. This is the whole path, step by step, as Termuna builds it.
Where do the encryption keys come from?
Every session gets its own content key, generated on your device the moment the session is created. That key never leaves your devices in unwrapped form. It is not derived from a password on our servers, not escrowed with us, and not recoverable by us. If the key exists anywhere, it exists on hardware you control.
This is the decision everything else follows from. A system where the server generates or ever holds session keys can promise not to look. A system where the server never has key material cannot look, and the difference between those two sentences is the entire security model.
What happens to a frame before it touches the network?
Terminal output and input travel as frames. Before a frame leaves your machine, it is sealed with XChaCha20-Poly1305, an authenticated cipher, using a random 24-byte nonce for every message. The random nonce matters because a session has several writers at once: the host streaming output, and any viewer typing back in. With a 24-byte random nonce, writers do not need to coordinate counters, and nonces never repeat across devices sharing one session.
Authenticated encryption also means tampering is detectable. A frame that was modified in transit, by anyone, fails authentication and is rejected. The relay cannot silently alter what your terminal shows you.
What does the relay actually do?
As little as possible, on purpose. The relay routes sealed frames between the host and its viewers, and persists them so history and resume work. It stores and forwards the encrypted bytes exactly as they arrived, and never re-encodes the payload. It can read the envelope it needs for routing: which session a frame belongs to and in what order. It has no key material, so the payload is opaque to it.
The threat model is blunt: assume the relay is fully compromised. An attacker holding every byte the server has ever stored gains a pile of ciphertext, session sizes, and timestamps. Not one keystroke, not one line of scrollback.
How does a browser decrypt without the server seeing the key?
When you open a session from a share link, the decryption key rides in
the URL fragment, the part after #. Browsers never send the
fragment in HTTP requests, so it reaches the page's JavaScript without ever
reaching the server. The browser then remembers the key locally, so a link
is pasted once. Decryption and rendering happen entirely in the page.
Signed-in dashboard users skip the link: their session keys live in their encrypted vault, unlocked on the device. Either way the property is the same, the key travels around the server, never through it.
How does a second device get the same key?
Through your vault, not through the server's goodwill. When you sign in on a second device, Termuna does not hand it session keys: the keys sit in your encrypted vault, and the vault is unlocked on the device with a key derived from your encryption passphrase, which never leaves your machines. The server ships the ciphertext between devices and can do nothing else with it. The same wrapping mechanics power team vaults (explained here).
Why is TLS not enough?
TLS protects the pipe, not the destination. It encrypts traffic between your machine and the server, and then the server sees plaintext. That is fine when the server is meant to read your data, and wrong when it is not. End-to-end encryption treats the server itself as untrusted. Termuna uses both: TLS on every connection, and the end-to-end layer inside it, so compromising the transport gains nothing and compromising the server gains ciphertext.
The same logic answers a subtler question: your SSH sessions are already encrypted, so why another layer? Because SSH encrypts the hop between your machine and the SSH server. The mirror to Termuna's relay is a different path with a different endpoint, and without its own sealing, the relay would see your SSH session's plaintext the moment it left your terminal. Each hop gets the encryption whose endpoint you actually trust.
What does the server see, in one list?
- That a session exists, when it is live, and its size in bytes.
- Encrypted frames, stored exactly as they arrived.
- Account records and hashed device tokens.
- Never: keystrokes, output, scrollback, or keys.