GoTTY

Last reviewed Aug 26, 2026 · 780 words

GoTTY's upstream repository has not seen a release in years, and I would still keep the binary around for one job: putting a read-only terminal program on a web page in about 5 seconds. Run gotty htop and a colleague on the VPN is watching your server's load in a browser tab, with no client, no agent and no configuration. For anything you want to type into, use ttyd, which is the same idea with an active maintainer and a better terminal. The difference between "share a view" and "share a shell" is the whole security story here, so it gets its own section.

The 5-second version, and the flags after it

gotty top                              # read-only, http://host:8080
gotty -w bash                          # writable: a real shell in the browser
gotty -p 9000 -c alice:hunter2 top     # custom port, HTTP basic auth
gotty --random-url top                 # unguessable path
gotty -t --tls-crt cert.pem --tls-key key.pem top   # HTTPS directly
gotty --once -w bash                   # exit after the first client disconnects

The default is read-only, which is the right default. Add --reconnect for a session that survives a flaky link, and --permit-arguments if you want the URL query string passed to the program (and think hard before you do). It is a single static Go binary, 64 MB is generous, and there are no dependencies on the host beyond the program you are sharing.

Read-only is the product; -w is a remote shell for whoever finds it

gotty -w bash bound to a public interface is a shell with a URL, and basic auth over plain HTTP sends the password in the clear on every request. There are three acceptable deployments and no fourth. Bind to localhost and put a reverse proxy with TLS and forward-auth in front, so Authelia or a similar layer owns the login. Or run it only on a mesh VPN address, such as your Tailscale IP, where the network itself is the authentication. Or run it read-only with --random-url for a short-lived share and kill it afterwards. The catalogue's "security needs careful setup" note is polite; the honest version is that the writable mode is a loaded tool and the safety is entirely on you.

Upstream is stale; forks and packagers carry it

The original yudai/gotty has been effectively unmaintained for a long time and the last tagged release predates several generations of browser changes. It still works, because the protocol is a WebSocket carrying bytes and browsers have not broken that. Community forks (sorenisanerd/gotty is the one most packagers and users seem to have settled on) keep dependencies current and fix the bugs that matter, and are what I would actually download. This is the classic "19,547 stars, and the stars are historical" project: the idea was excellent, it was copied everywhere, and the original author moved on.

ttyd is the maintained sibling; Guacamole is the grown-up

ttyd does everything above (ttyd -W bash, port 7681, basic auth, TLS, read-only by default) with an xterm.js front end that handles colours, resizing and Unicode better, plus an active release cadence. For a new deployment there is no reason to prefer GoTTY over it. If what you actually want is persistent remote access to several machines with recorded sessions, SSH key management and a login page, neither is the tool; that is Apache Guacamole, which is a full gateway and sized accordingly. GoTTY and ttyd are for exposing one program, right now, to a browser.

Where it earns its place in a homelab

Three uses I still see and endorse. A read-only htop or a tail -f of a build log on a wall-mounted dashboard, next to your monitoring panels, where a browser is the only client available. A one-off shell for a friend helping you debug, shared over Tailscale with --once so it dies when they leave. And a throwaway terminal on a locked-down machine where you cannot install a client but can open a browser tab. In each case the program is the interface and the browser is a window onto it, which is exactly what GoTTY was built for a decade ago.

What I'd do

Install ttyd for anything new and interactive. Keep a maintained GoTTY fork binary for the read-only dashboard use case, always behind Tailscale or a forward-auth proxy, never with -w on an interface that faces the internet. Neither replaces SSH; they replace the moment when you need a terminal on a screen that has no terminal.