GoTTY: Turn Any CLI Tool Into a Web Application With Zero Configuration
Hook
What if you could share a live terminal session with anyone who has a web browser—no SSH keys, no VPN, no client software—using a single command?
Context
Command-line tools are powerful, but they’re terrible at collaboration. When you need to show someone a running process, demonstrate a CLI workflow, or provide remote support, you’re stuck with screen sharing, copy-pasting output, or walking someone through SSH setup. For non-technical stakeholders who need to see what a deployment script is doing or monitor a long-running job, the terminal is a barrier.
GoTTY solves this by acting as a bridge between Unix pseudo-terminals (PTYs) and web browsers. It wraps any command-line program in a web server, streams the terminal I/O over WebSockets, and renders everything in a browser-based terminal emulator. The result is instant, zero-dependency terminal sharing that works anywhere HTTP does. Written in Go by Iwasaki Yudai, it’s gained over 19,000 GitHub stars for its elegant simplicity: one binary, one command, and your terminal is on the web.
Technical Insight
GoTTY’s architecture is deceptively simple. When you run gotty top, the Go binary spawns a pseudo-terminal (PTY) for the top command, starts an HTTP server (default port 8080), and waits for WebSocket connections. Each browser client connects via WebSocket, and GoTTY streams the PTY output in real-time while optionally accepting input from the client. The frontend uses xterm or hterm to render the terminal in the browser with full ANSI color support and terminal escape sequence handling.
Getting started requires zero configuration. Download the binary from the releases page and run it with any command:
# Share a live system monitor
gotty top
# Share an interactive shell (dangerous without auth!)
gotty -w bash
# Share a build process with read-only access
gotty npm run buildThe real power emerges when you layer in GoTTY’s security and configuration options. For demonstration scenarios, the --random-url flag generates a hard-to-guess URL path, giving you lightweight security through obscurity. For anything beyond demos, you’ll want basic authentication and TLS:
# Secure terminal sharing with auth and encryption
gotty -w \
--credential admin:secretpass \
--tls \
--tls-crt ~/.gotty.crt \
--tls-key ~/.gotty.key \
bashOne of GoTTY’s most elegant features is its configuration flexibility. Beyond CLI flags, you can use environment variables (prefixed with GOTTY_) or a .gotty config file in your home directory. The config file uses a simple format that supports both server options and terminal customization:
// ~/.gotty
port = "9000"
enable_tls = true
permit_write = false
random_url = true
// Customize the hterm terminal appearance
preferences {
font_size = 5
background_color = "rgb(16, 16, 32)"
}The WebSocket architecture handles dynamic terminal resizing elegantly—when you resize your browser window, GoTTY sends a window size update to the PTY, and most well-behaved CLI applications respond appropriately.
For shared sessions where multiple users need to see and interact with the same terminal state, GoTTY’s default one-process-per-client model doesn’t work. The workaround is terminal multiplexers. Start GoTTY with tmux or GNU Screen, and multiple clients can attach to the same session:
# Create a shared tmux session
gotty -w tmux new -A -s shared_sessionThis pattern is crucial for collaborative debugging or pair programming scenarios. Each browser client connects to GoTTY, which connects to the same tmux session, giving everyone a synchronized view of the terminal.
The --permit-arguments flag opens up creative possibilities for parameterized CLI tools. When enabled, clients can pass command-line arguments via URL query parameters:
# Start a parameterized grep tool
gotty --permit-arguments grep -r
# Clients access: http://localhost:8080/?arg=TODO&arg=/path/to/codeThis effectively turns CLI tools into crude web APIs, though you should be extremely careful about command injection risks here. Only use this with read-only commands and understand that you’re accepting arbitrary arguments from the web.
Gotcha
GoTTY’s simplicity comes with significant trade-offs. The security model requires careful thought. Basic authentication sends credentials in plain text unless you enable TLS, and the README explicitly warns that enabling write access (-w) is dangerous. It is. Without proper network isolation or authentication, you’re essentially giving remote code execution to anyone who can reach your port. Even with authentication, the basic auth mechanism is rudimentary. The --random-url flag provides some security through obscurity, but that’s not a substitute for real authentication and encryption.
The one-process-per-client architecture means each browser connection spawns a new instance of your command. For read-only monitoring of expensive processes, this can quickly exhaust system resources. The tmux workaround for shared sessions is clever but adds complexity and another dependency. If you need true multi-user collaboration with session persistence, GoTTY may not be the right tool—consider whether something purpose-built for that use case would better serve your needs.
Verdict
Use GoTTY if you need quick, ephemeral terminal sharing for demonstrations, tech support, or showing CLI output to non-technical stakeholders. It excels at scenarios where you want to expose a long-running build process, demonstrate a CLI tool without requiring SSH access, or provide read-only access to system monitoring commands. The zero-configuration deployment model—single binary, no dependencies—makes it perfect for temporary use cases. Consider alternatives for production environments requiring active security maintenance, long-term deployments, or true collaborative terminal sessions beyond simple screen sharing. For security-sensitive contexts, evaluate whether actively maintained alternatives better meet your requirements.
