tmux alternative · reachable from any browser

Your terminals. On your machines. One browser tab away — no SSH, no VPN, no tunnels.

Cordane keeps your terminals running on hardware you own and lets you reach them from any browser, anywhere. Like tmux, sessions persist and survive disconnects — but the machine can sit behind NAT or a firewall, because the worker dials out. Nothing ever connects to it.

PTYs live on the worker Reconnect replays scrollback Your real shell & dotfiles Follows you to your phone
The trade-off today

tmux keeps the session alive. Getting back to it is the hard part.

tmux is great once you're on the box. The friction is everything around it — the SSH config, the VPN, the open port, the moment you're on your phone and the tunnel is gone.

tmux + SSH / VPN today

Persistent — if you can get to it.

  • The session survives, but reaching it means an SSH key, a VPN client, or a port left open on the box.
  • A machine behind NAT or a corporate firewall needs a jump host or a tunnel before tmux attach even works.
  • From a phone or a borrowed laptop, you're re-typing keys and hostnames just to get a prompt.
  • A tmux server restart ends every pane unless you saved with resurrect first.
Cordane

Persistent — and a tab away.

  • The worker dials out over one WebSocket — no inbound port, no VPN, no SSH config to maintain.
  • Open the same terminal from any browser, on any device, wherever you are.
  • PTYs live on the worker and keep running through a browser close, a network drop, and a hub restart.
  • Two people can attach to one live PTY and type together — no screen-sharing.
If you think in tmux

Every tmux idea has a home in Cordane.

The mental model carries over almost verbatim. Same building blocks, different surface — with your real shell underneath.

In tmux In Cordane
A session A space — a named workspace of terminals you open and close as a unit.
Windows & panes Multiple terminals side by side in one space, each a full PTY on the worker.
attach / detach Open or close the browser tab. The PTY keeps running on the worker either way; reconnecting replays the scrollback.
A tmux-resurrect save file A space definition — a saved layout with a working directory and a command per pane, that you can spawn as many fresh instances of as you want.
Your .tmux.conf world Your real login shell and dotfiles — .zshrc, starship, aliases — run as-is. Nothing to translate into a new config format.
The honest comparison

What survives what — measured against tmux + resurrect.

This is the whole argument, laid out per event. Parity where it's parity, better where the dial-out and worker/hub split genuinely helps — and nothing dressed up.

When this happens tmux + resurrect Cordane
Your browser or SSH client disconnects Survives — session detaches; SSH back in and reattach. Survives — PTY keeps running on the worker; reopen the tab and scrollback replays.
You close the laptop and pick up your phone Only if you can SSH into the box again from the phone. Survives — same URL in any browser, with a touch key bar for Ctrl, Esc, and arrows.
The control process restarts (tmux server / Cordane hub) Lost — a tmux server restart ends every pane; resurrect re-spawns layout & dirs, not live state. Survives — PTYs live on the worker, not the hub, so a hub restart never touches them.
The machine reboots (tmux host / worker) Re-spawns — live state gone; resurrect re-spawns the saved layout, working dirs, and programs. Re-spawns — live state gone; a space definition re-spawns the layout, working dir, and command per pane.

Parity on disconnects and reboots, better on control-process restarts — because in Cordane the terminals run on the worker while the hub is just the surface you reach them through.

It's your real shell

Not a sandbox. Not a web toy. Your actual terminal.

Your login shell & dotfiles

The real login shell from /etc/passwd — your .zshrc, your aliases, your starship prompt. Nothing sandboxed away, nothing to reconfigure.

True-color, WebGL-rendered

TERM=xterm-256color with 24-bit color, drawn on a WebGL canvas. vim splits, htop, lazygit, and your colorscheme all render the way they should.

Follows you to your phone

Open the same live terminal on mobile, with a touch key bar for the keys a phone keyboard hides — Ctrl, Esc, Tab, and the arrows. Tap Ctrl+C and the prompt comes back.

Two people, one live PTY

Attach a teammate to the same running terminal and both of you type into it — genuine pairing on the exact same session, not a screen-share of one person's screen.

Straight talk

Where it isn't tmux — said plainly.

If you live in tmux, you deserve the limits up front, not buried in a footnote. Here's what to expect.

  • Keystrokes relay through the hub. There's no mosh-style predictive local echo, so on a high-latency link you feel the round trip. It's comfortable for shell work; it isn't zero-latency local typing.
  • No tmux prefix, copy-mode, or keybindings. Your .tmux.conf muscle memory doesn't carry over — this is an alternative, not a drop-in replacement.
  • Scrollback is in-memory, not on disk. Each terminal keeps a 2 MiB ring buffer that replays on reconnect; it isn't persisted to disk, so it isn't a permanent log.
  • Don't want the kanban? The hub is one Go binary — run it, join a worker, use only the terminals, and ignore the board entirely. It's there when you want it and out of the way when you don't.
FAQ

tmux users ask these first.

Is Cordane a drop-in replacement for tmux?
No — it's an alternative, not a drop-in replacement. There's no tmux prefix key, no copy-mode, and none of your .tmux.conf keybindings carry over; the interaction model is different. What maps 1:1 is the persistence: a session becomes a space, panes become terminals side by side, and a tmux-resurrect save file becomes a space definition you can re-spawn.
Do my terminals survive if I close the browser or lose my connection?
Yes. The PTY lives on the worker, not in your browser, so closing the tab or dropping your network changes nothing — the process keeps running. Reconnect and Cordane replays the scrollback so you land where you left off.
What survives a hub restart versus a machine reboot?
A hub restart doesn't touch your terminals — they run on the worker, not the hub, so they keep going and you reconnect to live processes. This is where Cordane beats a plain tmux server, which loses every pane if it restarts. A full worker reboot does end live processes, the same as rebooting a tmux host; a space definition then re-spawns the layout, working dir, and command per pane, the way tmux-resurrect re-spawns a saved session.
Do I need SSH, a VPN, or open ports to reach my machines?
None of them. Each worker opens a single outbound WebSocket to the hub and keeps it open, so a box behind NAT, a corporate proxy, or a home router just works — nothing ever connects to it. There are no inbound ports to forward and no VPN to configure.
Is there input latency?
Yes, some — and we won't pretend otherwise. Keystrokes relay through the hub and back, and there's no mosh-style predictive local echo, so on a high-latency link you feel the round trip. For interactive shell work it's comfortable; for latency-critical typing over a bad connection, plain local SSH will feel snappier.
Can I use it without the kanban board?
Yes. The hub is one Go binary — run it on localhost, join a worker, and use only the terminals if that's all you want. The board is there when you need it and completely ignorable when you don't.
Managed cloud waitlist

Reach your terminals from anywhere.

Self-hosting is free and available now — start with the quickstart, no email required. This list is only for managed cloud, where we run a finite fleet and would rather queue you than sell a hub we can't build well. We store your address only to tell you when a slot opens, and you can ask us to delete it any time.

No spam. No newsletter. One email when a slot opens.