xterm.rs is a tiny Rust backend that streams a real PTY over a WebSocket. Job control, Unix signals, full-screen TUIs and live resize — the things web terminals usually only pretend to do. The window on the right is an actual shell — locked down for the public, but real. Go on.
Restricted sandbox · non-root · no network · type help
docker compose up, then refreshA lot of in-browser terminals match your input against a script and print canned output. It looks right until you press Ctrl-C or open an editor. xterm.rs spawns a genuine shell on a PTY with a controlling terminal, so the kernel — not a lookup table — decides what happens.
/dev/ttybash on a real PTYOne static binary, an xterm.js frontend, and a WebSocket between them. That's the whole stack.
Each connection gets its own pseudo-terminal, set up as a session leader with the slave as its controlling terminal.
Ctrl-C, Ctrl-Z, background jobs, fg, tcsetpgrp — the line discipline is the kernel's, not a polyfill.
vim, htop, tmux, less, nano — anything cursor-addressed renders byte-for-byte the same as a native term.
The frontend reports cols and rows; the backend issues TIOCSWINSZ and the process gets a SIGWINCH.
Point --cmd at a shell, a single program, or your own lesson launcher. Optionally exit when it does.
The backend is a single self-contained Rust binary — no runtime, no dependencies to install, just drop it in and run. The browser side is xterm.js talking to it over a WebSocket.
Every IT and ethical-hacking lab on hack.courses is a real machine in a browser tab, powered by xterm.rs. No VMs to install, nothing to configure — learners land in a working terminal and start breaking (and fixing) things from the first minute.
We build xterm.rs and run it across our own security training and tooling. Want a real terminal inside your product, or a hand getting it deployed and locked down? We're happy to help.