Self-hosted browser-based terminal access, honestly reviewed. No marketing fluff, just what you get when you run it yourself.

TL;DR

What it is: Open-source (MIT) terminal emulator that runs in your browser over HTTP/HTTPS — a web front-end for SSH connections or local shell access [1].
Who it’s for: Homelab operators, sysadmins, and developers who need shell access to a server without a dedicated SSH client, or who want to embed a terminal inside an internal web tool [1].
Cost savings: Zero licensing cost. Runs on any server you already have. No SaaS tier exists — it’s self-hosted only, and the only expense is the machine it runs on [1].
Key strength: WebSocket-based transport with xterm.js gives you a genuinely full-featured terminal in the browser — not the laggy Ajax workaround that older tools like ajaxterm use [1].
Key weakness: No user management, no session recording, no access controls beyond SSH authentication. It’s a thin browser shim over SSH, not an access management platform.
Stars: 5,189 on GitHub [1]. MIT license.

What is WeTTY

WeTTY (Web + TTY) does exactly one thing: it proxies a terminal session into your browser over HTTP or HTTPS. You point it at an SSH server, open a URL, authenticate, and get a working shell — in Chrome, Firefox, or any browser that supports xterm.js.

The GitHub README states it plainly: “Terminal over HTTP and https. WeTTY is an alternative to ajaxterm and anyterm but much better than them because WeTTY uses xterm.js which is a full fledged implementation of terminal emulation written entirely in JavaScript. WeTTY uses websockets rather than Ajax and hence better response time.” [1]

That distinction matters in practice. Ajaxterm, which dates to around 2007, polls the server over HTTP — you get perceptible latency between keystrokes, and full-screen terminal applications render incorrectly. WeTTY’s WebSocket connection behaves like a real bidirectional socket: input and output flow continuously, so typing feels immediate and htop, vim, and tmux work as expected.

The project is maintained by Cian Butler (GitHub handle: butlerx) and has accumulated 5,189 stars and 41 contributors [1]. It is not backed by a company — it is a personal open-source project maintained in the developer’s free time. That’s reassuring in one direction (no pricing pivots, no vendor lock-in) and a real consideration in another (no commercial support, no guaranteed response timeline for issues).

Why people choose it

Dedicated third-party reviews of WeTTY are sparse — no major review sites have published deep dives as of this writing. What exists is a consistent pattern in homelab forums, r/selfhosted threads, and self-hosted community discussions around the same four use cases.

Blocked SSH ports. Corporate firewalls frequently block port 22 but leave 443 open. If you need to reach a server from a work laptop, hotel WiFi, or a locked-down network, WeTTY tunneled over HTTPS through a reverse proxy becomes the clean solution. The alternative is a VPN, which is a larger setup and often also blocked, or negotiating firewall exceptions with an IT department that won’t help you.

No SSH client available. Chromebooks, managed company MacBooks with software restrictions, shared computers, tablets — there are situations where you don’t have a native SSH client. A browser is always available. WeTTY solves this with zero footprint on the client side.

Embedded terminal in internal dashboards. WeTTY supports iframe embedding via the --allow-iframe flag [1], which makes it usable as a terminal panel inside admin UIs, internal documentation, or custom homelab dashboards. This is a real workflow for people building internal tooling around their infrastructure.

Simpler than the alternatives. Apache Guacamole can do browser-based SSH, but Guacamole requires a Guacamole server, a guacd daemon, and a database. WeTTY is npm install wetty or one Docker run command. For people who want browser terminal access without infrastructure complexity, WeTTY wins on simplicity by a significant margin.

Features

Based on the README and CLI help output [1]:

Transport and terminal emulation:

WebSocket-based transport for low-latency bidirectional communication [1]
xterm.js terminal emulator — full ANSI escape codes, color support, resize handling, full-screen app support [1]
Works in all browsers that xterm.js supports (the same library VS Code uses for its integrated terminal) [1]

SSH connectivity:

Connects to a specified SSH host and port via --ssh-host and --ssh-port [1]
Username can be specified in the URL: http://server:3000/wetty/ssh/<username> [1]
SSH authentication via password or public key (--ssh-auth "publickey,password") [1]
Private key file support (--ssh-key) for passwordless connections — flagged in the README as “insecure” [1]
Alternative SSH config file support (--ssh-config) [1]
Known hosts file support (--known-hosts) [1]

Root mode:

When run as root, WeTTY launches /bin/login directly — no SSH required [1]
--force-ssh flag forces SSH mode even when running as root [1]

Flexibility:

Custom command via --command flag — can launch any shell or program, not just bash [1]
Configurable base path (--base) for serving under a sub-path on an existing domain [1]
Configuration file support (--conf) for persistent settings [1]
Window title customization [1]
iframe embedding support, defaulting to same-origin only [1]

Deployment options:

Docker image: wettyoss/wetty on Docker Hub [1]
npm global install: npm -g i wetty [1]
Daemon/service mode documented [2]
Auto-login support documented [2]
File downloading from terminal sessions documented [2]
nginx, Apache, and Traefik reverse proxy configuration examples in docs [2]

What WeTTY does not include: user management, session recording, audit logging, access controls, multi-hop SSH support with a UI, or any browser-side credential storage.

Pricing: SaaS vs self-hosted math

There is no SaaS version of WeTTY. It is entirely self-hosted.

WeTTY software license: $0. MIT license, no usage restrictions [1].

What you actually pay:

The server it runs on. If you’re already running a VPS for other self-hosted tools, WeTTY adds essentially zero marginal cost — it’s a Node.js process consuming under 100MB of RAM.
Dedicated VPS if you don’t have one: $4–6/month on Hetzner Cloud or Contabo handles it easily.
Domain name for HTTPS via Let’s Encrypt: approximately $10–12/year.

Commercial alternatives for browser-based terminal access:

Direct SaaS pricing comparisons are unavailable because most browser-terminal solutions are either bundled into broader products or are enterprise software with undisclosed pricing. AWS CloudShell is free but locked to the AWS console — not a self-hosted option. Cloudflare’s browser-rendered SSH is included in their Zero Trust product, with a free tier but usage limits. Enterprise PAM products (BeyondTrust, CyberArk) that include browser terminal capabilities start at five figures per year for any meaningful deployment.

WeTTY isn’t competing with PAM platforms. The honest math: if your use case is “I need SSH access from a browser,” WeTTY costs whatever server you were already paying for, and nothing else.

Deployment reality check

This is where WeTTY’s reputation for simplicity is earned.

npm path:

npm -g i wetty
wetty --ssh-host your.server.com --port 3000

Open http://localhost:3000/wetty, authenticate, done [1].

Docker path:

docker run --rm -p 3000:3000 wettyoss/wetty --ssh-host=<YOUR-IP>

One command. Working browser terminal [1].

What you need:

Node.js >= 18 (for npm install) or Docker [1]
make, python, and build-essential for the npm path — WeTTY includes native Node.js modules [1]
A reverse proxy (nginx, Apache, Caddy) for production HTTPS [1]
Optionally: a domain name for Let’s Encrypt certificates

What can go sideways:

The native build dependencies (make, python, build-essential) catch people on minimal server images. Alpine Linux, stripped-down Docker base images, and freshly provisioned cloud instances frequently lack these packages. The Docker image avoids this entirely and is the safer default for most deployments.

Running WeTTY without HTTPS exposes SSH credentials in plaintext on the network. The README explicitly recommends a reverse proxy for production [1]. This is not optional if your instance is accessible beyond localhost.

The auto-login feature [2] connects to the SSH target without prompting for credentials — useful for embedded terminals, dangerous if the WeTTY port is public-facing. There is no built-in authentication layer beyond SSH. The security model requires that you control who reaches the port via network-level controls (VPN, IP allowlist, firewall rules) or that you treat SSH authentication as sufficient.

The --allow-iframe flag defaults to same-origin. Cross-origin embedding requires explicit configuration, and the documentation doesn’t elaborate on security implications for multi-tenant environments [1].

Realistic deployment time:

Developer who knows Docker: 5–15 minutes.
Developer setting up HTTPS with nginx and Let’s Encrypt: 30–60 minutes.
Non-technical founder without a guide: not recommended without help. There is no web-based installer.

Pros and cons

Pros

Genuinely simple to deploy. One npm command or one Docker command yields a working browser terminal. No database, no complex configuration, no dependencies you didn’t expect if you use Docker [1].
Real terminal emulation. xterm.js is the same library powering VS Code’s integrated terminal — full ANSI support, proper color rendering, resize handling, and correct behavior for full-screen applications [1].
WebSocket transport. Not the polling-based approach of older tools. Input latency over a decent connection is indistinguishable from native SSH [1].
MIT licensed. No usage restrictions, no commercial agreement required, no “fair-code” ambiguity [1].
Flexible SSH configuration. Password auth, public key auth, custom SSH configs, connections to arbitrary remote hosts — not locked to localhost [1].
iframe embeddable. Lets you drop a working terminal panel into internal dashboards and admin tools [1].
Minimal resource footprint. The server process uses minimal RAM and CPU at idle. It won’t noticeably compete with other services on a shared VPS.

Cons

No built-in authentication. WeTTY relies entirely on SSH for auth. In root mode with /bin/login, anyone who reaches the port gets a login prompt. An exposed, unauthenticated WeTTY instance is a brute-force target.
No session recording or audit logging. If you need to know who typed what and when — for compliance, incident response, or security review — WeTTY cannot help. This isn’t a missing feature that might be added; it’s outside the project’s scope.
No user management. No WeTTY user database, no role-based access, no “this person can only reach this host.” Access control happens entirely at the SSH and network layer.
Personal project, not company-backed. One maintainer, no commercial support. The codebase is mature and stable, but long-term maintenance depends on one person’s continued interest [1][GitHub].
Documentation is thin on security hardening. The README covers flags and setup clearly but doesn’t give explicit guidance on hardening a public-facing instance. Less experienced users may not know what questions to ask.
Build dependencies are a gotcha. The npm path requires native build tools not present on minimal images [1]. Not a blocker, but an unexpected failure mode.

Who should use this / who shouldn’t

Use WeTTY if:

You need SSH access from environments where port 22 is blocked — corporate networks, hotel WiFi, restricted environments.
You have a homelab and want browser-based shell access from a tablet, Chromebook, or any device without an SSH client.
You’re building an internal admin tool and want to embed a live terminal panel via iframe.
You know Docker and want a browser terminal running in under 15 minutes.
You’re running a small operation and SSH-level authentication is sufficient for your access control requirements.

Skip it (use Teleport instead) if:

You need session recording, audit logs, or certificate-based access controls.
You’re managing production infrastructure for a team where access accountability matters.
You need role-based access: this person can reach these servers, that person cannot.

Skip it (use Apache Guacamole instead) if:

You need VNC or RDP support in addition to SSH.
You want connection history and session management with a multi-user web UI.
You’re comfortable with a heavier Java-based deployment in exchange for more features.

Skip it entirely if:

You can’t or won’t configure a reverse proxy for HTTPS. Running WeTTY over plain HTTP on a public address is a credential exposure risk.
You’re a non-technical founder without someone to handle the initial setup and ongoing security hygiene. The tool is technically simple; the security model requires understanding it.

Alternatives worth considering

ttyd — The closest direct alternative. Also uses xterm.js, also WebSocket-based, also MIT. The key difference: ttyd executes a local command (any shell or process) rather than proxying SSH. Useful when you want to expose a specific tool in a browser rather than general remote shell access. Lighter and narrower.

Apache Guacamole — More complex, more capable. Supports SSH, VNC, RDP, and Telnet from a single gateway. Includes session recording, connection history, and user management. Requires a Java application server, guacd daemon, and database. Setup time is hours. Choose Guacamole if you need more than SSH or need built-in session recording.

Teleport — The enterprise option. Browser SSH, session recording, role-based access controls, certificate-based authentication, full audit trail. Community edition is open source; the feature set most teams need is behind commercial licensing. Overkill for a homelab; correctly sized for a team with compliance requirements.

Shell In A Box — The predecessor. Uses Ajax polling rather than WebSockets — perceptibly worse performance, largely unmaintained. WeTTY replaced it for good reason. No reason to use Shell In A Box for new deployments.

JumpServer — Open-source PAM platform. Browser SSH, RDP, VNC, audit logging, asset management, RBAC. Much heavier than WeTTY and aimed at teams managing many servers with compliance requirements. More comparable to Teleport than to WeTTY.

Cloudflare Zero Trust browser-rendered SSH — Cloudflare proxies SSH through the browser as part of their Zero Trust product. Not self-hosted, free tier available, requires Cloudflare account. If you’re already in the Cloudflare ecosystem and don’t want to run your own WeTTY instance, worth evaluating — though you’re trading infrastructure control for SaaS convenience, which is the opposite of why most people are looking at WeTTY.

Bottom line

WeTTY does one thing: it puts a real terminal in your browser. It does that thing well — xterm.js emulation, WebSocket transport, SSH connectivity, Docker deployment in one command. If that’s what you need, it’s the right tool and you’ll have it running in minutes. What it doesn’t do is manage users, log sessions, or protect you from your own firewall mistakes. It’s a thin, sharp tool, not an access management platform. For a homelab operator, a developer who needs to reach servers from restricted networks, or someone embedding a live terminal in an internal dashboard, WeTTY is the obvious pick. For teams with compliance requirements or anyone managing production infrastructure where access accountability matters, you need something heavier — Teleport or Guacamole — where audit trails and access controls are built in rather than expected at the network layer.

If the setup is the blocker, that’s exactly what upready.dev deploys for clients: one-time setup, you own the infrastructure, no recurring SaaS bill.

Sources

WeTTY GitHub Repository and README — Cian Butler (butlerx), 5,189 stars, MIT license
https://github.com/butlerx/wetty
WeTTY Official Documentation — flags reference, HTTPS setup, nginx/Apache guides, auto-login, file downloading, daemon mode
https://butlerx.github.io/wetty
WeTTY npm Package — install page, version history
https://www.npmjs.com/package/wetty