Speedtest Tracker: self-hosted internet performance logging with Docker

The problem Speedtest Tracker addresses

A single speed test answers a narrow question: what was the throughput at that moment. It does not tell you whether the connection degrades every evening, whether packet loss appears only during peak hours, or whether an outage lasted four minutes or forty. Speedtest Tracker exists to turn that one-off measurement into a time series. The README describes it as a self-hosted application that monitors the performance and uptime of your internet connection, and lists automated tests, detailed metrics (download and upload speeds, ping, packet loss), historical data and threshold notifications as the feature set.

The audience is narrow but real. It is for the person who pays for a 1 Gbit line and wants to know what actually arrives, for the home lab operator who already runs containers and wants the data in their own database rather than in someone else's dashboard, and for anyone who has to argue with an ISP using dates and numbers. It is not a diagnostic tool for a single bad call, and it is not a substitute for a network monitor that watches individual devices.

How the scheduled tests and storage actually fit together

The repository layout shows a Laravel application: app/, bootstrap/, config/, database/, routes/, resources/, storage/ and tests/, with artisan at the root. That matters because it tells you what you are operating. This is a PHP web application with a database behind it, not a single binary that writes to a log file.

The .env.example file confirms the storage assumptions. DB_CONNECTION defaults to sqlite, and the commented DB_HOST, DB_PORT, DB_DATABASE, DB_USERNAME and DB_PASSWORD entries show that a server database is the alternative. QUEUE_CONNECTION is set to database, which means scheduled work is queued in the database rather than in memory, and SESSION_DRIVER is cookie. CACHE_STORE is also database. In practice, the container needs a writable volume for the SQLite file or a reachable PostgreSQL instance, and the queue has to be processed for scheduled tests to run.

The compose.yaml in the repository is the development stack rather than the production recipe. It builds a Laravel Sail style environment with a laravel.test service on port 80, a pgsql service using postgres:17-alpine on port 5432, mailpit for mail on 1025 with a dashboard on 8025, and an apprise service. The README points production users at the LinuxServer.io image and the installation guide instead, which covers Docker plus NAS platforms such as Synology and Unraid. That distinction is worth respecting: compose.yaml is what a contributor runs, not what you deploy.

Installing Speedtest Tracker with Docker and running a first test

The README states the application is containerized and that the image is built by LinuxServer.io, with installation steps for Docker, Synology and Unraid in the documentation. The repository's own compose.yaml is for local development, so treat the commands below as the shape of a deployment and check the environment variable page in the docs for the exact names your version expects. The compose.yaml shows the port mapping pattern: the application service publishes ${APP_PORT:-80}:80.

A minimal service definition follows that pattern, with a volume so the database survives a container restart.

services:
  speedtest-tracker:
    image: lscr.io/linuxserver/speedtest-tracker:latest
    ports:
      - '${APP_PORT:-80}:80'
    volumes:
      - ./config:/config
    restart: unless-stopped

Bring it up and watch the logs for the first boot, which is when the application key and database are prepared.

docker compose up -d
docker compose logs -f speedtest-tracker

Once the container is healthy, open the published port in a browser. The README does not document the first-run credentials, so use the default login information in the documentation rather than guessing. From the dashboard you configure the test schedule, and the README's feature list confirms that notifications fire when performance drops below a threshold you set. If you prefer a server database, the .env.example shows the switch: set DB_CONNECTION away from sqlite and fill in the DB_HOST, DB_PORT, DB_DATABASE, DB_USERNAME and DB_PASSWORD values.

Where Speedtest Tracker is the wrong tool

The application measures the connection at the point where the container runs. If you deploy it on a VPS in a data centre, you are measuring that data centre's link, not your home line. This is the most common way people misread the results, and the README does not warn about it because it assumes you know where your container sits.

The second limitation is that the data is only as continuous as your scheduling. The README lists notifications and thresholds but says nothing about backfilling a gap, so a container that is down for a weekend leaves a hole in the history. There is no documented rollback or migration path for the stored data in the README either, which matters if you switch database backends after months of collection.

Finally, this is a measurement tool, not a remediation tool. It will tell you that packet loss appeared at 20:00 and cleared at 22:00. It will not tell you which device on your LAN caused it, and it will not page your ISP for you. If your actual problem is Wi-Fi coverage inside the house, a speed test history is the wrong instrument.

Speedtest Tracker compared with MySpeed

MySpeed is the alternative that appears most often in searches about this project, and the difference is architectural rather than cosmetic. Speedtest Tracker is a Laravel application with a relational database, a queue and a web dashboard, distributed as a LinuxServer.io container. MySpeed is a Node.js application that also ships as a container and presents a dashboard with charts.

The practical consequence is in the storage and extension model. Because Speedtest Tracker uses Laravel's queue and database layers, the scheduled test is a queued job and the history lives in SQLite or PostgreSQL that you can query with standard SQL, back up with standard tooling, or point at an existing PostgreSQL server as the .env.example allows. MySpeed keeps its own storage and its own integration surface. If you want the results in a database you already operate, or you want to reuse an existing PostgreSQL instance, Speedtest Tracker's configuration is explicit about that path. If you want the smallest possible container with the fewest moving parts, the trade-off runs the other way.

Maintenance, licensing and upgrade cost

The repository is not archived and the last push was on 2026-09-16, so the codebase is being touched. Recent releases include v1.15.0 on 2026-08-21, v1.14.8 on 2026-08-18 and v1.14.7 on 2026-08-04. That cadence means you should expect to update the image periodically rather than pin it and forget it, and it means release notes are the place to look before upgrading.

The licence is MIT, given in LICENSE.md. MIT is permissive: you can run it, modify it and redistribute it, and the licence text itself is short enough to read. Nothing in the repository suggests a separate commercial tier, and the README does not describe one. This is not legal advice, and if you redistribute the application inside a product you should read LICENSE.md yourself.

The real upgrade cost is operational. Because the application stores its history in SQLite by default, an upgrade that changes the schema has to migrate that file, and the queue has to be running for scheduled tests to fire. The README does not document rollback, so before upgrading take a copy of the volume that holds your database. That single habit covers most of the risk.

Editorial conclusion

Adopt Speedtest Tracker if you want a self-hosted record of download and upload speed, ping and packet loss over time, and you already run containers on a NAS, a home server or a Proxmox host. Do not adopt it if you only need a single reading, or if you cannot give a container persistent storage and a database. Before committing, verify the environment variables for your deployment against the configuration page in the docs, confirm the notification channel you intend to use is documented, and check the release notes for the version you pin.

Frequently asked questions

Official sources

1. alexjustesen/speedtest-tracker on GitHub
2. License: MIT
3. Project website
4. README
5. Releases