in the browser

kittwm in a browser tab

The same window manager compiles to WebAssembly and draws with the GPU through WebGPU. A tab can attach to a kittwm host you run, speak SSH to a machine by itself, or boot a whole Linux guest with no server at all.

Live demos

• kittwm in a microVMA v86 emulator boots a small Linux guest inside the tab, and kittwm runs in it. Nothing leaves your browser; the first load is about 38 MB.no server needed
• SSH from the tabThe connect form: give it a WebSocket relay, a user and a password or key, and it renders that machine's kittwm.bring your own relay
• Attach to your hostThe web shell for a host running kittwm serve-pty: add ?ws= and #token= to the address.bring your own host
• The web shellThe same web shell build, served at a second address.same build

Three ways in

Attach to a host

A native kittwm serves its terminals over a WebSocket, guarded by a bearer token:

kittwm serve-pty --listen 127.0.0.1:8787 --token "$(openssl rand -hex 16)" --cols 80 --rows 24

Then open the web shell with ?ws=ws://127.0.0.1:8787#token=token. The token sits in the address fragment, which browsers never send to a server, or it can be typed into the in-canvas login prompt.

• kittwm serve-screen --real-wm --per-window streams each window as its own surface, with its own position and stacking, so floating and overlapping windows mirror faithfully, and clicks and keys go to the window under them.
• Frames are deduplicated end to end: when a captured frame is unchanged, the host sends only its hash, tens of bytes, and the browser skips decoding and GPU upload entirely.
• A development bundle builds with trunk serve; trunk build --release produces a size-optimised one of a few megabytes.

SSH in the tab, safely

For a machine with plain SSH, the tab runs an SSH client compiled to WebAssembly. A small relay near the target bridges the browser's WebSocket to TCP:

kittwm ws-ssh-relay --listen 127.0.0.1:8822 --ssh-target host:22

A browser has no known_hosts file and cannot stop a handshake to ask a question, so the web shell brings its own trust model:

Trust on first use

The first host key seen for a host is pinned. A different key later stops the connection behind a security overlay instead of continuing.

An encrypted vault

Pins and private keys persist in the browser only inside an AES-GCM-encrypted vault. Key passphrases are asked for at connect time and never stored.

No silent failures

No reachable backend, a GPU failure, a slow start, an authentication problem and a host-key mismatch each have a distinct message.

A Linux guest in the tab

The microVM demo needs no network at all. The page loads the v86 x86 emulator, boots a small Linux kernel and an initial ramdisk containing an i686 build of kittwm, and connects the web shell to kittwm serve-screen running inside the guest through an in-page network shim. It is slower than a real host, but it is a complete, isolated kittwm that anyone can try.

Every surface