Cloud continuity
Off by default, on in a minute. With sync enabled, every live session mirrors end-to-end encrypted to Termuna Cloud, and the session follows you to any browser or phone.
Turning it on
Open the sessions area, find the Termuna Cloud section, and sign in or
create an account. The app registers this machine and live sessions start
syncing. The sign-in writes the [cloud] section of
config.toml for you; nothing about the
setup is hidden.
Continuity and device sync are part of the Solo and Team plans; the Free tier is the complete local terminal (plans).
What mirrors, and how
- Every output and input frame, sealed with XChaCha20-Poly1305 on your machine before it touches the network. The relay stores ciphertext it cannot read.
- The session layout - tabs, splits, working directories - so a viewer joining late draws the right picture immediately.
- Scrollback history, which is what survives a reboot: processes die with the machine, the workspace and history do not (the honest version). Both the window and the depth held inside it depend on the plan (how long, and how deep).
When a synced session needs you - a bell, or an agent waiting on a question - the relay can push a notification to your browser (how that works).
Reachability
A signed-in desktop holds one lightweight connection to Termuna Cloud, separate from any session. It carries presence and the same sealed requests your sessions carry, so the relay learns that a machine is awake and nothing more: no directory, no command, no output. That is what lets your phone and the dashboard start a session on a desktop that has none open, open a saved host on it, or pick a dormant session back up.
Awake and asleep
Awake means the machine is holding that connection now and a request will reach it. Asleep means it stopped answering and the same silent host timeout that applies to sessions has expired. Closing the laptop lid makes a machine asleep within seconds. There is no third state and no wake button: we cannot wake a closed laptop, so an asleep machine offers what is actually there, its kept scrollback and a session started somewhere else.
Turning it off
Settings, Termuna Cloud, "Stay reachable with nothing running". With it off, that machine appears to your other devices only while it has a live session, which is the free plan behaviour. Staying reachable with nothing running is part of the Solo and Team plans (plans).
How long history is kept
Termuna Cloud stores your session output as sealed frames so a session can be resumed from another machine. Those frames do not live forever, and this is exactly how long they do live.
| fact | the rule |
|---|---|
| Free | 30 days |
| Solo | 12 months |
| Team | 12 months |
| The clock | counted from the last time the session was live, not from the moment it was created. A session that was never live has no clock at all. |
| Depth, Free | the newest 4,096 frames |
| Depth, Solo and Team | the newest 200,000 lines |
| The warning | the session's entry in the dashboard names its deletion date at least 14 days ahead |
The window is a property of the account's plan (plans): a session's history is kept for 30 days on a free account and for 12 months on Solo and Team, counted from the last time the session was live. After that the frames are deleted for good. A live session is never touched, however old it is.
What is deleted, and what is not
When a session ages out its frames are deleted, and then the session itself, with its layout snapshot and any share link still pointing at it. The session disappears from your list. Your account, your devices, your vault and your snippets are untouched: they have no retention window and are deleted only when you delete them. Your synced command history is a separate store and is not part of this rule.
The depth: how far back you can scroll
How long we keep a session and how far back you can scroll inside it are different promises. Free keeps a session for 30 days and holds the newest 4,096 frames of it; Solo and Team keep it for 12 months and hold the newest 200,000 lines. A week-long session on a chatty log tail therefore holds the last stretch of that log, not all of it. Whatever the plan, the top of a cut buffer names the limit that cut it, on the desktop, on the phone, and in the browser: what you can scroll back to is exactly what we hold, stated where you are looking at it.
Nothing about this changes what is on your own machine. The desktop keeps its own copy, and the archive is sealed with the session key before it leaves the machine, exactly like the live stream. The cloud never reads either copy.
Keeping something past the window
Export it. GET /v1/export hands back everything the
cloud holds for your account as one archive, on every tier including
free, and the dashboard has the same thing as a button. Each session in
the archive carries its retention_days and, once its clock
is running, its deletes_after, so the policy is checkable
by you rather than only stated by us
(the archive format).
Devices and tokens
Each machine's daemon connects with a device token, stored only as a hash on the server. Revoke any device from the dashboard's devices page and its daemon immediately loses cloud access, while the local terminal on that machine keeps working.
Share links
A share link is minted per session from the desktop's continuity panel, and two choices are made before it is copied: a mode, view only or can type, and a lifetime, one hour, one day, or until the session ends. The mode is the relay's to enforce, not the browser's: it decides what a viewer may send, so a view-only link watches and cannot type whatever its page is made to draw.
Links are listed and stopped per session or across the whole account. The place to take one back is the sessions view of the dashboard, from any device: every live link of the account is there with a Stop on each row and a Stop all. Stopping a link drops anyone attached through it at once and rotates the session's content key, so whoever held the stopped link cannot read what comes after. A link that runs out while someone is watching drops them the same way.
The decryption key rides in the link's #fragment, which
browsers never send to the server. Anyone with the link sees the
session; the relay never can.
The legacy bare link, written next to the session file in
~/.local/share/termuna/sessions/ as
<id>.cloudurl so scripts can find it, keeps opening
the session until its first share link is minted. From then on that
address asks for a share link instead.
Your keys, your passphrase
Session keys are generated on your devices and reach your other devices through your encrypted vault, unlocked by an encryption passphrase that never leaves your machines. Your snippets are items in that same vault, so they sync with your hosts, sealed the same way, with no change to the protocol. Losing the passphrase does not mean losing history: a recovery kit is generated when you set it - store it offline (the full encryption path).