Speedtest Tracker mit Docker Compose: Internetanschluss automatisch messen

Eine einzelne Browsermessung klärt nicht, ob Anschluss, WLAN oder Tageszeit für ein zähes Internet verantwortlich sind. Speedtest Tracker misst nach Zeitplan, speichert Ping, Download, Upload und Messserver je Ergebnis und zeigt den Verlauf als Diagramm.

Nutzen und Grenzen

Speedtest Tracker (Laravel, MIT-Lizenz) ruft die Ookla-Speedtest-CLI auf und speichert die Ergebnisse. Die Anleitung beschreibt v1.15.0 vom 21.08.2026.

Wofür sich das Werkzeug eignet:

• Langzeitverlauf der Anschlussleistung, etwa Einbrüche zu bestimmten Uhrzeiten.
• Gesprächsgrundlage gegenüber Provider oder Dienstleister.
• Benachrichtigung, wenn Download, Upload oder Ping unter selbst gesetzte Schwellwerte fallen.
• Auswertung per API, Prometheus oder InfluxDB, falls bereits ein Monitoring vorhanden ist.

Wichtige Abgrenzung: Die Ergebnisse sind kein amtlicher Nachweis. Für Festnetzanschlüsse bietet die Bundesnetzagentur mit der Desktop-App der Breitbandmessung ein verbindliches Verfahren (30 Messungen an drei Kalendertagen innerhalb von 14 Tagen). Erst dieses Protokoll begründet Minderungs- oder Sonderkündigungsrechte, Speedtest Tracker ist ein Frühwarnsystem.

Weitere Grenzen:

• Gemessen wird vom Docker-Host aus: WLAN oder ein langsamer Switch-Port verfälschen das Ergebnis.
• Jede Messung belastet den Anschluss, bei Volumentarifen oder Mobilfunk-Backup nutzen Sie einen sparsamen Zeitplan.
• Gemessen wird gegen Ookla-Server, die CLI läuft mit --accept-license --accept-gdpr: Ookla-Bedingungen gelten.
• Unterstützt sind laut Doku Docker, Compose, Kubernetes, QNAP, Synology und Unraid, nicht Bare-Metal oder Proxmox-LXC ohne Docker.

Voraussetzungen und Ressourcen

• Linux-Host (x86-64 oder ARM64) mit Docker und Compose-Plugin: 1 CPU-Kern, 512 MB RAM, 1 GB Speicher.
• Kabelanbindung an den Router, damit nicht das WLAN gemessen wird.
• Ein freier Port für die Weboberfläche, in dieser Anleitung 127.0.0.1:18472.
• Ausgehender Zugriff auf icanhazip.com und Ookla-Server. DNS-Blocklisten, die icanhazip.com sperren, lassen Messungen fehlschlagen.
• openssl auf dem Host, um den Anwendungsschlüssel zu erzeugen.

Im Test: 152 MiB RAM im Leerlauf, Image 376 MB, SQLite wächst um wenige KB je Messung.

Plattformen, Image und getestete Version

Das Image stammt von LinuxServer.io (lscr.io/linuxserver/speedtest-tracker), Architekturen:

Als Beispiel dient amd64 mit dem Tag v1.15.0-ls172: php artisan about meldet Speedtest Tracker v1.15.0, Laravel 13.26.0, PHP 8.5.10 und Filament v5.7.6, Speedtest by Ookla 1.2.0.84. Die Doku zeigt latest, nutzen Sie einen festen Tag. Ein neuerer Build derselben Version trägt den Tag v1.15.0-ls173.

Vollständige compose.yaml und .env

Für einen Standort reicht SQLite (alternativ MariaDB, MySQL, Postgres). Legen Sie ein Projektverzeichnis an, darin die compose.yaml:

name: speedtest
services:
  speedtest-tracker:
    image: lscr.io/linuxserver/speedtest-tracker:v1.15.0-ls172
    container_name: speedtest-tracker
    restart: unless-stopped
    ports:
      - "127.0.0.1:18472:80"
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=Europe/Berlin
      - APP_KEY=${APP_KEY}
      - APP_URL=${APP_URL}
      - DB_CONNECTION=sqlite
      - SPEEDTEST_SCHEDULE=${SPEEDTEST_SCHEDULE}
      - DISPLAY_TIMEZONE=Europe/Berlin
      - PRUNE_RESULTS_OLDER_THAN=365
    volumes:
      - ./data:/config
    healthcheck:
      test: ["CMD-SHELL", "curl -fsS http://localhost/api/healthcheck || exit 1"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 60s

Die Werte stehen in der .env (Beispiel ohne echten Schlüssel):

# Benutzer und Gruppe des Hosts, ermitteln mit: id
PUID=1000
PGID=1000
# Erzeugen mit: echo "base64:$(openssl rand -base64 32)"
APP_KEY=base64:HIER_EIGENEN_SCHLUESSEL_EINTRAGEN
# Adresse, unter der die Oberfläche erreichbar ist
APP_URL=http://127.0.0.1:18472
# Minute 17 alle sechs Stunden
SPEEDTEST_SCHEDULE=17 */6 * * *

Schlüssel erzeugen, Ausgabe samt Präfix base64: übernehmen:

$ echo "base64:$(openssl rand -base64 32 2>/dev/null)"
$ chmod 600 .env

Parameter und Dateipfade

Alles Persistente liegt in ./data (im Container /config): database.sqlite, keys/ mit selbstsigniertem Zertifikat, log/, nginx/, php/. Eigene Zertifikate: cert.crt (volle Kette) und cert.key in /config/keys.

Installation und Start

# Image laden

$ docker compose pull

# Container im Hintergrund starten

$ docker compose up -d

# Status und Healthcheck beobachten

$ docker compose ps

Im Test lieferte der Healthcheck nach 52 Sekunden HTTP 200, danach (healthy). Version im Log:

$ docker compose logs --no-log-prefix | grep -i version

# Ausgabe im Test:
# Linuxserver.io version: v1.15.0-ls172

Programmversion im Container:

$ docker compose exec speedtest-tracker bash -c 'cd /app/www && php artisan about'

Erstkonfiguration

Anmeldung: /admin/login. Laut Doku (im Test bestätigt) legt der erste Start einen Admin mit admin@example.com und password an. Ändern Sie beides sofort (Benutzermenü, Profile) oder setzen Sie ADMIN_EMAIL und ADMIN_PASSWORD vor dem allerersten Start, später wirken sie nicht mehr.

Bei verlorenem Zugang:

$ docker compose exec -it speedtest-tracker bash -c 'cd /app/www && php artisan app:user-reset-password'

Laut Projekt-FAQ wählen Sie eine weniger belegte Minute statt der vollen Stunde, falls geplante Messungen schlechter ausfallen als manuelle (Beispiel: Minute 17). Kontrolle:

$ docker compose exec speedtest-tracker bash -c 'cd /app/www && php artisan config:show speedtest'

Im Test: schedule ... 17 */6 * * *. Für feste Messserver listen Sie nahe Server auf und tragen die IDs in SPEEDTEST_SERVERS ein:

$ docker compose exec speedtest-tracker bash -c 'cd /app/www && php artisan app:ookla-list-servers'

Die erste Messung starten Sie in der oberen Leiste, im Test stand sie nach rund 15 Sekunden auf completed.

Benachrichtigungen und Schwellwerte

Kernkanäle sind laut Doku Datenbank, Mail und Webhook, weitere Dienste laufen über Apprise, andere Kanäle gelten als veraltet. Mail braucht SMTP-Variablen:

MAIL_MAILER=smtp
MAIL_HOST=smtp.example.com
MAIL_PORT=587
MAIL_USERNAME=speedtest@example.com
MAIL_PASSWORD=HIER_SMTP_PASSWORT
MAIL_FROM_ADDRESS=speedtest@example.com
MAIL_FROM_NAME="Speedtest Tracker"

Setzen Sie Variablen nicht gleichzeitig in einer .env der Anwendung und in der Compose-Datei (Doku). Schwellwerte (THRESHOLD_ENABLED, THRESHOLD_DOWNLOAD, THRESHOLD_UPLOAD, THRESHOLD_PING) wirken als Variablen nur bei der Ersteinrichtung, danach pflegen Sie sie in der Oberfläche. Eigene Push-Dienste binden Sie per Webhook oder Apprise an.

Funktionsprüfung und Healthcheck

Der dokumentierte Endpunkt /api/healthcheck antwortet mit HTTP 200 und einer kurzen JSON-Meldung:

$ curl -s http://127.0.0.1:18472/api/healthcheck

# Ausgabe im Test:
# {"message":"Speedtest Tracker is running!"}

Der Healthcheck in der compose.yaml nutzt denselben Endpunkt (curl ist im Image). Die REST-API unter /api/v1 verlangt ein Token, ohne Token kam im Test HTTP 401. Tokens legen Sie unter /admin/api-tokens an.

Netzwerkfreigabe, Reverse Proxy und TLS

Die Bindung an 127.0.0.1 macht die Oberfläche nur vom Host erreichbar (LAN-Adresse schlug im Test fehl). Setzen Sie für Netzzugriff einen Reverse Proxy mit gültigem Zertifikat davor und tragen Sie die öffentliche Adresse in APP_URL und ASSET_URL ein:

APP_URL=https://speedtest.example.com
ASSET_URL=https://speedtest.example.com

Ein passender Server-Block für Nginx nach dem Muster der Projektdokumentation:

server {
    listen 443 ssl;
    server_name speedtest.example.com;

    ssl_certificate /etc/letsencrypt/live/speedtest.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/speedtest.example.com/privkey.pem;

    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_pass http://127.0.0.1:18472;
    }
}

Mit ALLOWED_IPS beschränken Sie Anfragen auf bestimmte Adressen, PUBLIC_DASHBOARD (Dashboard ohne Anmeldung) nur im internen Netz. Nutzen Sie VPN oder Proxy mit Anmeldung.

Persistente Daten und Rechte

Dank PUID und PGID gehören die Dateien in ./data dem Host-Benutzer, Unterverzeichnisse des Containers können abweichen: Im Test scheiterte rm -rf data an data/.composer/cache/.htaccess: Permission denied. Für Backup unkritisch, zum Entfernen brauchen Sie sudo oder einen Hilfscontainer.

Backup und Restore

Bei SQLite ist der Bestand eine Datei: Stoppen Sie den Container kurz und sichern Sie ihn. Sichern Sie die .env getrennt und geschützt, ohne passenden APP_KEY sind verschlüsselte Inhalte unlesbar.

# Container anhalten

$ docker compose stop

# Datenverzeichnis sichern

$ tar czf speedtest-backup-$(date +%F).tgz -C data .

# Container wieder starten

$ docker compose start

Restore im Test: Markertabelle angelegt, Backup (12,5 KB), database.sqlite gelöscht, Backup zurückgespielt. SHA-256 stimmte, Healthcheck 200, Markertabelle zurück.

# Container anhalten

$ docker compose stop

# Datenbank aus dem Backup zurückholen

$ tar xzf speedtest-backup-2026-09-26.tgz -C data ./database.sqlite

# Prüfsumme mit dem Stand vor dem Backup vergleichen

$ sha256sum data/database.sqlite

# Container starten und Healthcheck abwarten

$ docker compose start
$ curl -s http://127.0.0.1:18472/api/healthcheck

Beim Entpacken in ein nicht leeres Verzeichnis meldete tar Cannot open: File exists für Dateien unter .composer. Entpacken Sie in ein leeres Verzeichnis oder stellen Sie gezielt Dateien her. Bei MariaDB oder Postgres sichern Sie per mariadb-dump oder pg_dump.

Updates und Rollback-Grenzen

Update: Backup, Tag anheben, Container neu erstellen.

# neuen Tag in compose.yaml eintragen, danach:

$ docker compose pull
$ docker compose up -d
$ docker compose logs --no-log-prefix | grep -i version

Beim Start laufen Migrationen, ein älteres Image kommt mit dem neuen Schema nicht zwingend zurecht. Rollback heißt: alter Tag plus Backup vor dem Update. Lesen Sie vor Versionssprüngen die Release-Hinweise.

Typische Fehler mit Diagnose und Lösung

php artisan tinker fehlt im Image (Command "tinker" is not defined), about, config:show, schedule:list und die app:-Befehle stehen zur Verfügung.

Saubere Deinstallation

# Container und Netzwerk entfernen

$ docker compose down -v --remove-orphans

# Image namentlich löschen

$ docker rmi lscr.io/linuxserver/speedtest-tracker:v1.15.0-ls172

# Datenverzeichnis löschen, bei Rechtefehlern mit sudo

$ sudo rm -rf data

# Kontrolle

$ docker ps -a --filter name=speedtest

Entfernen Sie auch Proxy-Block und DNS-Einträge.

Passende Anleitungen auf S-EDV

• Uptime Kuma mit Docker und Nginx Proxy Manager installieren
• Nginx als Reverse Proxy mit TLS einrichten
• ntfy mit Docker selbst hosten

Quellen

• Speedtest Tracker Dokumentation: Using Docker Compose
• Speedtest Tracker Dokumentation: Environment Variables
• Speedtest Tracker Dokumentation: Authentication (Standardkonto)
• Speedtest Tracker Dokumentation: Error Messages
• GitHub: alexjustesen/speedtest-tracker
• GitHub: linuxserver/docker-speedtest-tracker
• Bundesnetzagentur: Internetgeschwindigkeit und Nachweisverfahren

Grundlagen dazu: Docker Compose absichern.