Find your next open-source project

Search by name, purpose, or keyword — or paste a GitHub repository URL

Streams X11, macOS or Windows desktops to a browser as low-latency H.264, aimed at VMs, sandboxes and agents.

1,257
65
Rust
MIT
4 months old

What it does

voxl is a Rust server that captures a Linux X11 display (including Xvfb), a Mac screen or a Windows desktop, encodes it as H.264 with x264 on the CPU and sends it over a single WebSocket to a small web client that decodes with WebCodecs. Alongside video it carries input, clipboard, desktop audio, a browser microphone channel, and file and folder transfer, and it can resize the desktop to follow the viewer's window.

It is built for headless servers, VMs and sandboxes — CI machines, computer-use agents and "software factories" — where no one wants to install a client. There is nothing to install on the viewing side: the process serves its own page, and a link including a sign-in token is printed at startup.

Quick start

On Linux, the build needs Rust, pkg-config, clang, x264, libyuv, libopus, libpulse and esbuild; nix-shell provides them all. From a checkout:

nix-shell
cargo build --release
DISPLAY=:1 ./target/release/voxl --port=6901
# prints: open http://localhost:6901/?token=4f1c… to sign in

Or install the published crate, whose binary is named voxl (voxl-server on crates.io):

cargo install voxl-server
DISPLAY=:1 voxl

Open the printed link and the desktop appears in the browser. For an Xvfb desktop, start it with -shmem for zero-copy capture. ?stats on the URL adds an FPS overlay. macOS and Windows have their own build steps in the macOS and Windows sections; on those platforms voxl streams the machine's own screen.

To integrate it with automation, screenshots and recordings are plain HTTP calls (agent examples):

curl -u ":$VOXL_PASSWORD" -o shot.png localhost:6901/screenshot
curl -u ":$VOXL_PASSWORD" -o clip.mp4 "localhost:6901/record?seconds=10"

/wait blocks until the screen settles or changes, so scripts do not need fixed sleeps.

Constraints and access control

  • Browsers and HTTPS: viewing requires a browser with WebCodecs, and browsers only expose it on HTTPS pages or localhost. Remote viewers need a TLS proxy (Caddy, Cloudflare Tunnel, tailscale serve) plus --allowed-hosts, or an SSH port forward. Chrome/Edge 94+, Firefox 130+ desktop, Safari 16.4+ and iOS/iPadOS browsers are supported; Firefox for Android is not.
  • Login: a password is required by default, taken from --basic-auth-password or VOXL_PASSWORD or generated and embedded in the printed link. --enable-basic-auth=false disables it behind an authenticating proxy.
  • Host and origin checks: the server answers only for IP addresses and localhost, and only for its own page, unless --allowed-hosts and --allowed-origins are set. Non-browser clients such as curl send no Origin and connect normally.
  • Platforms: Linux streaming is X11-only; Wayland is not yet supported. Windows needs Windows 10+ and should run in the user session, not as a service, to see the lock screen and UAC. macOS needs Screen Recording and Accessibility permissions, plus a loopback audio device for the microphone.
  • Files and permissions: the Files panel is confined to --files-root ($HOME by default), and --read-only blocks input, clipboard writes, microphone, uploads and resizing.
  • Encoding: H.264 is encoded on the CPU; a busy 2560x1600 desktop costs roughly 1.3–1.7 cores including the X server, and there is no hardware encoding yet. Recordings are saved as MP4 without re-encoding, cost no extra CPU, omit the cursor and end when the resolution changes.
  • Transport: TCP over WebSocket keeps deployment simple but stalls on lossy links, where WebRTC can skip ahead.
  • License: the voxl code is MIT, but it links GPL-2.0 x264, so distributed binaries fall under the GPL.

Benchmarks

On a 16 vCPU AMD EPYC VM without a GPU at 2560x1600 Xvfb, voxl averaged 60 FPS with a median latency of 12–99 ms across the tests, while noVNC averaged under 8 FPS. The README compares selkies, KasmVNC, Neko, Sunshine and Daytona on the same workloads, in both FPS and p50/p99 latency, and notes that Sunshine is designed for GPU capture, so its numbers here reflect a GPU-less fallback rather than its target hardware. The bench/ directory contains the reproduction setup.

HotRepo's take

The Rust daily list of 2026-11-05 records voxl at position 5 with 285 stars gained and a total of 1074 stars. That is the only snapshot available, so it supports a single strong day of attention rather than a trend. The repository has no recorded position on the all-language daily list.

The README's most useful differentiator is not the benchmark table alone but the choice of one WebSocket over WebRTC: it means the stream travels through reverse proxies, tunnels and sandbox preview URLs without TURN servers, which fits the headless-VM and agent use case the project targets. The agent-facing endpoints (/screenshot, /record, /wait) and the --read-only and files-root controls make that positioning concrete rather than aspirational. The trade-off is stated plainly too: TCP stalls on lossy links. Readers evaluating it against Sunshine or RustDesk should note it runs X11 on Linux only and encodes on the CPU, so it is not a GPU gaming-streamer replacement.

Written by AI from the project's README, updated . The project's own docs are the source of truth.

Hacker News

Voxl: Fast remote desktop streaming written in Rust
▲ 5 · 0 comments · November 3, 2026