Installation
Install LoadWave with go install, from a release archive, or build it from source. One self-contained binary with the dashboard inside it.
LoadWave is one executable with the dashboard embedded in it — no agent package, no server component, no database. The same file runs a test, coordinates a fleet, and serves the UI.
That embedding happens at build time: a JavaScript build step compiles the
dashboard, and the Go build then reads that output into the binary. Only
the release archives and building from source run that step. go install
does not — see below.
From a release archive (has the dashboard)
Download the archive for your platform from
Releases and extract
loadwave (or loadwave.exe) somewhere on your PATH.
Invoke-WebRequest -Uri "https://github.com/SnowyFoxStudios/LoadWave/releases/latest/download/loadwave_windows_amd64.zip" -OutFile loadwave.zip
Expand-Archive loadwave.zip -DestinationPath . -Forceloadwave.exe is now in the current folder. Move it into a folder already on
your PATH — for example $(go env GOPATH)\bin if you have Go installed, or
anywhere else you keep local executables — or just run it from where it is:
.\loadwave.exe demoOn ARM64 Windows, use loadwave_windows_arm64.zip instead.
Every archive also carries a checksums.txt (in the release's file list, not
inside the archive itself) if you want to verify the download:
sha256sum -c checksums.txt --ignore-missingFrom source (has the dashboard)
Building from source needs Go 1.26+ and Node 26+, because the dashboard is a React application compiled and then embedded into the Go binary.
git clone https://github.com/SnowyFoxStudios/LoadWave.git
cd LoadWave
make build # ./bin/loadwavemake build runs the frontend build first and then compiles the Go binary
around it. Running go build ./cmd/loadwave directly, skipping make,
produces a working binary too — but skips that frontend step, so it embeds a
placeholder where the dashboard should be (the same situation as go install
below).
With go install (CLI and API only — no dashboard)
go install github.com/SnowyFoxStudios/LoadWave/cmd/loadwave@latestThis is the odd one out: it does not include the dashboard. go install
fetches the module's source and compiles it directly — there is no hook for it
to run a frontend build first, so the file the dashboard would come from is
never produced. The result is a fully working loadwave for the CLI and the
whole /api/v1/ REST surface; only --ui has nothing to serve, and says so:
LoadWave: the dashboard has not been built into this binary.
The REST API is available at /api/v1/. To build the UI:
make uiNeeds Go 1.26 or later. The binary lands in $(go env GOPATH)/bin, so make
sure that is on your PATH — and check that nothing else on your PATH
resolves to loadwave first, or you will be running whichever one comes first
without realising it.
If you installed this way and want the dashboard too, the fix is to replace
that binary with one from a release archive or a source build, above — not to
run go install again, which will only reproduce the same result.
Check it worked
loadwave versionThen, for a real end-to-end check that needs nothing else installed and no service to point at:
loadwave demo --duration 30s --headlessThat starts a small target server inside the same process, runs a two-scenario test against it and prints a report. If that works, the whole path — coordinator, agent, worker processes, merged metrics, thresholds — works.
To check the dashboard specifically, drop --headless:
loadwave demoand look for ui=true in the startup log, or just open
localhost:8088 — a binary without the dashboard says
so on that page instead of showing it.
What you will need in production
Nothing else, for a single-machine run. Two things are worth setting up before a large or distributed one:
- Raise the file descriptor limit. Every connection is a descriptor and the
default will bite long before the CPU does:
ulimit -n 65535. - Run NTP on every load host. Metric buckets are aligned to the wall clock so that nodes agree on what a given second means. See Distributed runs.