LibreSpeed

Last reviewed Sep 13, 2026 · 795 words

LibreSpeed measures the path between the browser that opens it and the server that hosts it, and nothing else. Run it on a box in your rack and you get a number for your LAN or Wi-Fi. Run it on a VPS and you get the real throughput of your home connection to that provider. Run it behind a Cloudflare tunnel and you have measured the tunnel. It will not tell you what Speedtest.net tells you, because Ookla picks a server 5 ms from your ISP's core and you picked the one you own. That is a feature once you know it, and a confusing afternoon if you do not.

Three placements, three different numbers

On the LAN, LibreSpeed on a wired server answers "is this access point delivering 600 Mbit/s or 90". Over a VPN, it reports the tunnel's real throughput, which is the number people are chasing when they wonder whether WireGuard on a Raspberry Pi is the ceiling. On a VPS, it measures your ISP to that datacentre, typically within 10 to 15 percent of an Ookla result and arguably the more honest figure, since it is not a server your ISP has any reason to treat specially. Pick the placement for the question you have; two containers in two places costs nothing.

The container is one image and a password

services:
  librespeed:
    image: lscr.io/linuxserver/librespeed:latest
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - PASSWORD=stats-page-password
      - DB_TYPE=sqlite
    volumes:
      - ./librespeed-config:/config
    ports:
      - "8080:80"
    restart: unless-stopped

That is a working install. The test page runs download, upload, ping and jitter in the browser with no client app, which is the whole reason it exists. The backend is PHP by default, with Go, Node and Rust implementations in the project for anyone who objects to PHP. The upload test posts chunks to the server, so if you front it with a reverse proxy, raise the body size limit (client_max_body_size in nginx; Caddy's default is fine) or upload will read as zero. The 512 MB listed as a minimum is generous; at rest it uses almost nothing.

History needs the results database

Out of the box each test is a number on a screen and then gone. With DB_TYPE set to sqlite, or to mysql or postgresql with the matching DB_ connection variables, every result lands in a table with a share link, and the stats page behind PASSWORD lists them. That gives you a modest history: run a test from the same laptop every Sunday evening and see whether the ISP's peak-hour slowdown is real. It is manual and it depends on a human clicking a button, which is the limitation to accept before you expect a graph.

Gigabit and above: the client is the bottleneck

Past about 1 Gbit/s the limiting factor stops being the network and becomes the browser and the laptop doing the test. A single tab pushing 2.5 Gbit/s through JavaScript is CPU-bound on many machines, and a mid-range laptop's USB-C Ethernet adapter caps well below that anyway. The test opens several parallel streams to get around per-connection limits, so a proxy that restricts connections per client will cap the result. If your 2.5 GbE link reads as 1.4 Gbit/s, run iperf3 between two wired hosts before blaming the switch, or use the project's command-line client, which removes the browser from the equation.

What it is not: a monitor

For "was my internet slow at 3 a.m.", the tool is Speedtest-tracker, which runs a test on a schedule from the server itself, stores results, draws the graph and can alert. LibreSpeed is on-demand, from a browser, by a person. They answer different questions, and many people run both: the tracker for the WAN trend line, LibreSpeed for the "is it the Wi-Fi or the ISP" moment. Neither is an uptime tool in the monitoring category sense; that is Uptime Kuma's job, and it stays that way.

What I'd do

One LibreSpeed on the home server, wired, reachable on the LAN and over the tailnet, SQLite results on, password on the stats page. A second on the cheapest VPS I have, no database, for the honest WAN number. Speedtest-tracker beside them for the scheduled trend. That is 15 minutes of setup and it settles the "the internet is slow" argument with a number every time, which is the only reason any of it exists. As a Speedtest.net alternative it is complete; as a monitoring system it was never trying to be one.