# Homebox measures a home LAN up to 10G from a browser, with the client doing the work > Homebox is a home network toolbox that serves a browser based speed test, a ping check and a continuous stress mode, built as a Rust actix-web server with a TypeScript and React front end bundled by Rspack. The design trick is a Web Worker pool, with a low speed mode and a high speed mode, and the README is unusually candid about which machines can reach which numbers. **XGHeaven/homebox** — A Toolbox for Home Local Networks & LLM - Repository: https://github.com/XGHeaven/homebox - Stars: 818 · Forks: 68 - Language: TypeScript - License: not declared - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/xgheaven-homebox ## A speed test where the client is the measurement instrument Homebox is a toolbox for home local networks, and the README describes it as a set of tools for debugging, testing and stress testing a network while you are setting up a home LAN. The tool's main job is a browser based speed test, and the features list claims speeds up to 10G from the browser. There is a built-in ping check, a rich set of custom speed test parameters, and a note that the server does not need the solid state drive support that a traditional file copy would demand, because the data does not have to be written to disk. The architecture is a two part deployment. The README's requirement section is explicit that the software needs a server to be deployed, and then the client accesses a web page to run the tests. So this is not a single binary you run on your laptop, it is a service on a machine on the network and a browser on the machine you are measuring from. That arrangement is the interesting part. A conventional speed test between two machines copies a file, which means the disk is in the loop and the result is a number about the disk as much as about the network. Homebox keeps the transfer in the browser and in the server's memory, which is why the README can claim a server without solid state drive support. The stack is a Rust server using actix-web, a TypeScript front end with React, and Rspack as the bundler. ## Why every request runs inside a Web Worker The Design section explains the central engineering decision, and the reasoning is specific enough to be useful. The problem is that JavaScript in a browser is slow, and network requests occupy a lot of memory. To avoid the main thread stuttering, every request is issued from a Web Worker. One worker is not enough for a 10G network, though. The README compares a single connection single process curl, which can reach 2GB/s, roughly 16Gbps, against a worker issuing multiple concurrent requests, which reaches only about 500MB/s. The fix is to create several workers and stack their throughput, which satisfies the 10G requirement. The catch is that several workers demand a lot from the machine, so on a weak machine used only for gigabit testing the result would be inaccurate. That is exactly why there are two modes. In the high speed mode multiple workers are enabled, and in the low speed mode a single worker is used to reduce resource consumption. The default is the low speed mode, described as suitable for most network situations, and the high speed mode is available in the advanced configuration, where the client resources are squeezed as hard as possible to push as much traffic as possible through a link above 10G. This is a design that trades accuracy for reach, and the two modes are the visible consequence of that trade. ## Single test and continuous stress, and what each is for The usage section describes two test modes, and the distinction is about intent rather than about buttons. In the single test mode the tool runs a ping, a download and an upload test in sequence, and the README says this mode is generally the one to use. The continuous stress mode runs an unlimited duration load at the maximum speed the link will carry. The README gives three situations for it: testing link stability while a device is moving, testing several devices at once, and testing the thermal behaviour of a router's forwarding under load. The third of those is the interesting one, because a router that forwards at full rate for a sustained period is a different proposition from a router that forwards at full rate for ten seconds, and only the sustained version tells you about the heat. There is also a third mode, marked as work in progress, for the terminal. The idea is to copy the speed test script that the browser provides and run it in a terminal, which is offered as a convenience for people who do not want to type a command line, and which is said to be faster and more accurate because it removes the browser from the path. The limitation of that terminal mode is that it is work in progress, so for now the browser remains the supported path. ## Deploying it with Docker or a release binary The install section offers two routes. The Docker route needs a server that can run Docker, with the examples given being a Synology, FreeNAS, unRAID or CentOS machine. The image only supports x86 servers at the moment. ```bash docker run -d -p 3300:3300 --name homebox xgheaven/homebox ``` The image exposes port 3300 by default, and you then point a browser at http://your.server.ip:3300 to run the tests. The binary route is to download the matching build from the releases page, unpack it and run the serve command. ```text Usage: homebox serve [OPTIONS] Options: --port Port to listen --host Host to listen -h, --help Print help ``` So the two routes differ in what they cost you. The container is one command and gives you a server, and the binary is a file you run yourself with a port and a host you choose. The Dockerfile shows how the image is put together, and it is a three stage build. The web stage uses node:lts with corepack enabled and the Makefile targets bootstrap-web and build-web, the server stage uses rust:1.82-alpine3.20 and copies the built static assets across from the web stage, and the final image is alpine:3.20 with the release binary, exposing 3300 and running ./homebox serve as its command. ## The client CPU decides which numbers you get The Performance section is the part of the README that deserves to be read twice, and it starts with an admission: the author does not have a 10G or faster mobile device and asks for results if anyone has one. The client measurements that are given are attributed to specific machines. On a 2017 13 inch MacBook, the low speed configuration reaches 4G download and 3G upload. On a 2019 16 inch MacBook, the high speed mode reaches up to 12G download and 10G upload. On an AMD 3600 machine, the high speed mode reaches 15G download and 12G upload. On an M2 MacBook Air, the low speed mode reaches 20G download and 16G upload, and the README advises against using the high speed mode there because it causes resource scheduling contention, which lowers the numbers and makes them unstable. That last note is the useful one, because it explains the shape of the results. The M2 machine produces the highest numbers in low speed mode, and the high speed mode makes it worse, not better. The mode is a way of spending client resources, and on a machine where the browser already has what it needs, spending more of it makes the measurement less repeatable. The requirement section says the same thing in one line: when testing above 10G you have to make sure the client performance, mainly the single core CPU, is strong enough, otherwise it may become the bottleneck. So the honest reading of these numbers is that they describe client machines, not networks. The link was fast enough in every case, and the difference is what the browser could push. ## Cross compiled builds for NAS boxes and routers The Makefile is where the portability of the server shows, and it is more thorough than a typical release. The build targets produce a static-ish release binary per platform through build-arch, which adds the Rust target, builds with the locked release profile and copies the artefact into build/arch under a name composed of the target and a file suffix. The naming is what the FAQ tells you to look at when choosing a download, and the FAQ is refreshingly blunt about it: the name is mainly decided by os and arch, where os is windows, darwin or linux, and arch is arm64 for ARM machines, amd64 for Intel and AMD 64 bit processors, and 386 for 32 bit machines, which are rarely needed now. The platform list is aarch64 and x86_64 for darwin, x86_64 and i686 for Windows, and for Linux the glibc targets for amd64, arm64 and 386, plus musl variants of the first two, with a comment that the musl targets are for OpenWrt and Alpine style environments. That musl build is not a detail, because the FAQ has a whole entry about it. If an arm64 build fails on OpenWrt with an ELF interpreter error pointing at /lib/ld-linux-aarch64.so.1, the answer is to use the arm64-musl build instead. There is also a second FAQ entry that answers the question every project with binaries gets, which is why the downloaded file does not run, and the answer is that the wrong format was downloaded, with the advice to try each of them until one works. ## Where a speed test tool is the wrong answer Three situations rule it out. The first is a measurement you need to be repeatable and comparable over time. The README's own M2 MacBook Air result is the argument: the same machine and the same link produce different numbers depending on which mode is selected, and the high speed mode can make them unstable. A tool whose output depends on the client is the right tool for a sanity check on a link, and the wrong tool for a baseline you will compare against next month. The second is when you cannot deploy a server on the network. The tool's model is a server plus a browser client, and for testing a peer to peer link, a link between two laptops over a switch, or a path that leaves your LAN, the server has to be somewhere it can be reached, and that somewhere may change the result. The third is when you want a command line tool you can run over SSH. The terminal mode exists for that, but it is marked as work in progress, and a finished script that runs the same test without a browser is the thing most people would reach for in a server room. For its own case, though, the project is a neat piece of engineering. The insight that a browser speed test has to move the data through a Web Worker pool, and that the number of workers is a trade between reach and accuracy, is the kind of thing a network tool should have thought about before shipping. ## Conclusion Homebox fits a home lab or a small office that has outgrown a loopback test and wants to know what the link between two devices actually carries, since it measures through the browser and reports download, upload and ping separately. It is the wrong choice if you need a portable command line tool, because the terminal mode is marked as work in progress, and it is the wrong choice for a network where you cannot put a server behind it, since the tool needs a deployed server that the client points at. Before running a 10G test, read the performance section and check the client CPU, because the README states plainly that a weak single core becomes the bottleneck and that the high speed mode makes the numbers unstable on some machines. ## FAQ ### How do I install Homebox? With Docker, by running docker run -d -p 3300:3300 --name homebox xgheaven/homebox and then opening http://your.server.ip:3300 in a browser. The image supports x86 servers only. You can also download a release binary and run homebox serve with optional --port and --host arguments. ### What is the difference between Homebox's two speed test modes? The single test mode runs a ping, download and upload test in sequence and is the one the README recommends for most cases. The continuous stress mode runs an unlimited maximum speed load, which is meant for link stability while devices move, multi-device testing and checking router thermals under sustained forwarding. ### Why does Homebox use Web Workers for the speed test? Because browser JavaScript is slow and network requests consume a lot of memory, so the requests run in workers to avoid blocking the main thread. A single worker tops out around 500MB/s even with concurrent requests, so the high speed mode stacks several workers to reach 10G, while the low speed mode uses one worker to keep results accurate on weaker machines. ### Why does my downloaded Homebox binary not run on OpenWrt? The FAQ explains that an arm64 build on OpenWrt can fail with an ELF interpreter error, and the fix is to use the arm64-musl build instead. The Makefile produces musl variants of the Linux builds specifically for OpenWrt and Alpine style environments. ### What does Homebox need on the client side? A browser and a machine whose single core CPU can keep up, because the README states that for testing above 10G the client performance, mainly the single core, must be strong enough or it becomes the bottleneck. The published figures are client measurements, from a 2017 13 inch MacBook in low speed mode up to an M2 MacBook Air reaching 20G download in low speed mode. ## Sources - [Issues](https://github.com/XGHeaven/homebox/issues) - [README](https://github.com/XGHeaven/homebox/blob/master/README.md) - [Releases](https://github.com/XGHeaven/homebox/releases) - [XGHeaven/homebox on GitHub](https://github.com/XGHeaven/homebox) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/xgheaven-homebox