Build a Private Speed Test Server with LibreSpeed and Docker

Why Your HomeLab Needs a Local Speed Test

We’ve all been there: your Jellyfin stream starts buffering right at the climax of a movie, or a 50GB backup to your TrueNAS server feels like it’s moving through molasses. Most users immediately check Speedtest.net, but that only measures your path to the internet. If a cheap Ethernet cable is bottlenecking your 1Gbps link or your Wi-Fi access point is overheating, an external test won’t tell you a thing.

LibreSpeed fills this gap. It is a lightweight, open-source utility that skips the bloat of Flash or Java. Running it on Docker makes it portable and incredibly easy to manage. In my experience, this is a foundational HomeLab tool. It provides a “ground truth” baseline that helps you troubleshoot every other service in your rack.

Quick Start: The 60-Second Deployment

If you need to diagnose a laggy connection right now, you can spin up a container with a single command. I recommend using the images maintained by LinuxServer.io. They are consistently updated, secure, and handle user permissions much better than generic alternatives.

docker run -d \
  --name=librespeed \
  -e PUID=1000 \
  -e PGID=1000 \
  -e TZ=Etc/UTC \
  -p 8080:80 \
  --restart unless-stopped \
  lscr.io/linuxserver/librespeed:latest

Once the container is live, point your browser to http://[YOUR-SERVER-IP]:8080. You’ll see a clean, ad-free interface. Hit ‘Start’ to immediately see your internal bandwidth limits. It’s that simple.

The Better Way: Docker Compose Setup

One-liners are great for testing, but I prefer Docker Compose for long-term setups. It keeps your configuration in a YAML file, making it easy to back up or migrate to a new server later. Create a project directory and a docker-compose.yml file to get started:

mkdir librespeed && cd librespeed
nano docker-compose.yml

Paste this configuration into the file:

services:
  librespeed:
    image: lscr.io/linuxserver/librespeed:latest
    container_name: librespeed
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Asia/Ho_Chi_Minh
      - PASSWORD=your_secure_password
    volumes:
      - ./config:/config
    ports:
      - 8080:80
    restart: unless-stopped

Launch the stack by running:

docker compose up -d

Breaking Down the Parameters

• PUID/PGID: These variables map the container’s internal user to your host user. This prevents permission errors when the container tries to write to your /config folder.
• Volumes: Mapping the config directory allows you to save custom CSS or telemetry data permanently. Without this, your data disappears if the container is deleted.
• Ports: I used 8080 here. It avoids conflicts with common tools like Portainer or Nginx, which often claim port 80 first.

Advanced Usage: Tracking Performance Over Time

A single speed test is just a snapshot. To see the bigger picture, you need telemetry. This feature saves every test result to a database, allowing you to see if your network degrades when the kids start gaming or when you’re running heavy backups.

Activating Telemetry

The LinuxServer image includes a built-in SQLite database. To enable it, add these environment variables to your compose file and restart the container:

    environment:
      - TELEMETRY=true
      - PASSWORD=mypassword # This protects your stats page

You can view your history at http://[YOUR-SERVER-IP]:8080/results/stats.php. This is incredibly useful for spotting patterns. For instance, you might notice your throughput drops by 200Mbps every time the microwave is running near your Wi-Fi router.

Pro Tips for Accurate Benchmarking

I often see users complain that their self-hosted test is “slow.” Usually, the bottleneck isn’t the network—it’s the testing method. Keep these four points in mind:

1. Mind the Browser CPU

LibreSpeed runs on JavaScript. While fast, testing a 10Gbps connection can max out a laptop’s CPU before it hits the network limit. I’ve seen 1Gbps tests struggle to reach 600Mbps simply because the client machine was thermal throttling.

2. Test the Path, Not Just the Destination

Don’t just test from your main workstation. Run tests from multiple points: a hardwired PC to set a baseline, a phone in the basement to find Wi-Fi dead zones, and a laptop behind a VPN to measure encryption overhead.

3. Avoid Reverse Proxies for Local Tests

If you use Nginx Proxy Manager or Traefik, try to bypass them for internal testing. Proxies add a layer of processing that can introduce latency. For the most accurate raw data, always connect directly to the server’s local IP address.

4. Know Your Hardware Limits

Hardware matters. If you run Docker on a Raspberry Pi 3, you will never see 1Gbps. The Pi 3’s Ethernet port is capped at roughly 300Mbps because it shares a bus with the USB ports. Always verify your host’s physical specs before you start replacing your Cat6 cables.

Deploying LibreSpeed is a quick win for any HomeLab enthusiast. It removes the guesswork from network troubleshooting and provides hard data. Once it’s running, you’ll likely find yourself using it every time you tweak your router settings or move an access point.