compare

There are five ways to reach a terminal from a phone.

All of them work. They optimise for different things, and one of them isn't mtmux. Here's the honest version.

Feature comparison across eight dimensions: mtmux, tmate, ttyd & wetty, mobile SSH apps, and VS Code Remote.
Capability	mtmux	tmate	ttyd / wetty	SSH apps	VS Code Remote
Attaches to your existing tmux	Supported	new session	via command	Supported	via terminal
Designed for touch	Supported	Not supported	Not supported	varies	Not supported
Reaches a host behind NAT	Supported, dials out	Supported, dials out	Not supported	Not supported	tunnel
Nothing to port-forward	Supported	Supported	Not supported	Not supported	tunnel
Credentials on the phone	none	none	password	SSH key	SSH key
Survives reconnects	Supported, reattaches	session stays	partial	with mosh	partial
Notifies you when a job ends	Not supported	Not supported	Not supported	Not supported	Not supported
Edit files in a GUI	in-terminal	in-terminal	in-terminal	in-terminal	Supported

The notification row is a column of dashes on purpose. None of these tools page you, mtmux included — if that is what you need, a tmux hook into ntfy or your agent's own hook support is the answer, and it composes with any row above it.

The rest of the landscape, briefly

The five above are the ones most people actually choose between. These come up often enough to deserve a straight answer about what they are.

Eight remote-terminal tools, what each one is, and how you reach it from another machine.
Tool	What it is	How you reach it	More
tmate	A second tmux server built for handing someone a link, right now.	Dials out to a tmate relay. Nothing to forward.	tmate alternative
ttyd	A small C binary that serves any command you name over a WebSocket. Read-only unless you pass -W.	Listens on port 7681. You expose it and bring your own proxy, TLS and auth.	ttyd vs wetty
wetty	A Node server that runs ssh for you and renders it in the browser. No read-only mode.	Listens on port 3000. You expose it; SSH is the auth.	ttyd vs wetty
GoTTY	The Go original of the same idea. The upstream repo's last release was 2017; an actively maintained fork carries it on.	Listens on port 8080, unencrypted unless you turn TLS on.	tmux in a browser
sshx	Collaborative terminal sharing with remote cursors. The encryption key lives in the URL fragment, so its relay cannot read the session.	Dials out to a hosted relay. Self-hosting is not supported today.	tmux in a browser
Zellij	A multiplexer in its own right — a tmux replacement, not a way to reach one. It has had an opt-in web client since v0.43.	Its web server listens on localhost by default; exposing it is your job.	tmux commands
Mobile SSH apps	A native client with your private key stored on the phone.	Needs a reachable sshd, which a machine behind NAT may not have.	tmux from your phone
mtmux	A CLI that serves the tmux server you already run, with a touch layer on top.	Dials out and seals frames end to end. Nothing to forward.	Two-minute quickstart

Zellij is in this table because people compare it to tmux, not because it competes with the rest — if you want a different multiplexer rather than remote access to the one you have, it is a good one. None of these tools send notifications.

the honest version

vs. tmate

tmate is the best tool in the world for “let me show you this for ten minutes.” It forks a second tmux server and hands out an SSH or web link for a shared session, and it has been doing that reliably for years.

mtmux attaches to the tmux server you are already running rather than starting a new one, and is built around a browser on a small screen rather than a link you paste to a colleague. Different job: pairing versus commuting. If you want someone else in your terminal, use tmate.

vs. ttyd & wetty

Both wrap a shell in a WebSocket and serve xterm.js. Excellent, minimal, and honest about scope: you bring the reverse proxy, the TLS, the auth and the open port.

mtmux dials out instead of listening, seals frames end-to-end so the relay carries ciphertext, and adds the mobile input layer on top. If you already trust your own proxy and only need a desktop browser on your own network, ttyd is less machinery and you should use it.

vs. mobile SSH clients

Native SSH apps are fast and mature, and some have genuinely good keyboards. The costs are a private key living on a phone and a reachable sshd — which, for a machine behind NAT, may not be arrangeable at all.

mtmux pairs a per-browser device key you can revoke by id, and needs nothing open because the CLI dials out. If you want a general-purpose shell to arbitrary hosts you already have SSH access to, keep the SSH app — mtmux only reaches machines you installed it on.

vs. VS Code Remote & code-server

If you want to write code on a tablet with a pointer, an editor in the browser beats a terminal. It is also a heavy install, a much larger attack surface, and a rough experience on a six-inch screen.

mtmux doesn't try to be an IDE. It is the fastest path to the session that is already running, on the device in your hand — which is a smaller ambition and a much smaller thing to install.

When not to use mtmux

You need a shell on a host you can't install mtmux on — use SSH.
You want a GUI editor with a file tree on an iPad — use VS Code Remote.
You want to hand a colleague temporary access to your terminal — use tmate.
You want to be paged when a job finishes — mtmux never pages you; wire up a tmux hook.
Your box has no outbound network access and no LAN reachability — nothing helps.

Everything else — a long run you want to keep an eye on from outside the house — is what mtmux was built for. Two-minute quickstart →