Zum Hauptinhalt springen
S-EDV news
← Alle Anleitungen
📘 Anleitung Docker 18.10.2026 · 10 min Lesezeit

LubeLogger mit Docker Compose: Fahrzeuge und Wartung selbst verwalten

Diese Anleitung zeigt, wie Sie LubeLogger 1.7.4 mit Docker Compose betreiben, die standardmäßig offene Instanz sofort absichern, Wartungen und Tankvorgänge per Oberfläche und API erfassen sowie Daten und Cookie-Schlüssel sichern und nachweislich wiederherstellen.

Mit KI erstellt – redaktionelle Prüfung ausstehend

WerbelinksMit * markierte Links sind Werbelinks: Bei einem Kauf erhalten wir eine Provision, der Preis bleibt gleich. Als Amazon-Partner verdiene ich an qualifizierten Verkäufen. Mehr dazu

Titelbild: LubeLogger mit Docker, Fuhrpark und Wartung im Blick, mit Karten für Wartungshistorie, Tankbuch sowie Backup und Restore

Wann war der letzte Ölwechsel am Servicefahrzeug, wann ist die nächste Hauptuntersuchung fällig und was hat der Transporter im letzten Quartal verbraucht? LubeLogger sammelt sie in einer schlanken Weboberfläche: Wartungen, Reparaturen, Tankvorgänge, Steuern, Notizen und Erinnerungen je Fahrzeug, dazu eine REST-API für Skripte. Das Projekt steht unter MIT-Lizenz und läuft als einzelner Container. Diese Anleitung zeigt die Installation mit Docker Compose, die Anmeldung, die ersten Einträge per Oberfläche und API, ein sauberes Backup samt echtem Restore und den Update-Weg von Version 1.7.3 auf 1.7.4. Alle Befehle und Fehlermeldungen stammen aus einem eigenen Testlauf.

Voraussetzungen

Im Test belegte der Container rund 84 MB Arbeitsspeicher, das Image ist knapp 400 MB groß.

  • Linux-Server oder VM mit 1 bis 2 CPU-Kernen (x86_64 oder ARM64) und mindestens 1 GB RAM, besser 2 GB, wenn weitere Dienste laufen
  • 2 GB freier Speicher für Image und Daten, zusätzlich Platz für Fotos und Belege, die Sie an Einträge hängen
  • Docker Engine mit Compose-Plugin (v2), siehe Docker-Compose-Grundlagen
  • Für den Zugriff von außen ein Reverse Proxy mit TLS-Zertifikat und ein DNS-Eintrag, etwa fuhrpark.example.de
  • Ein Backup-Ziel außerhalb des Servers (NAS, zweiter Server oder Objektspeicher)

Schritt 1: Projektordner und Compose-Datei anlegen

Das offizielle Repository liefert eine minimale docker-compose.yml mit dem Tag latest. Schreiben Sie die Version fest. Die Tags in der GitHub Container Registry tragen ein vorangestelltes v, also v1.7.4. Ein Tag 1.7.4 ohne v existiert nicht.

mkdir -p /opt/lubelogger && cd /opt/lubelogger
printf 'LUBELOGGER_TAG=v1.7.4\n' > .env

Die Datei compose.yaml:

services:
  app:
    image: ghcr.io/hargata/lubelogger:${LUBELOGGER_TAG}
    restart: unless-stopped
    environment:
      LC_ALL: de_DE.UTF-8
      LANG: de_DE.UTF-8
      TZ: Europe/Berlin
    volumes:
      - data:/App/data
      - keys:/root/.aspnet/DataProtection-Keys
    ports:
      - "8080:8080"

volumes:
  data:
  keys:

Die beiden Locale-Variablen sorgen für deutsche Zahlen- und Datumsformate: Komma als Dezimaltrenner, Euro-Zeichen und dd.MM.yyyy. Das Volume data enthält die LiteDB-Datenbank cartracker.db, Konfiguration, Bilder und Dokumente. Im Volume keys legt ASP.NET die Schlüssel ab, mit denen Login-Cookies verschlüsselt werden.

EckdatenWert
Imageghcr.io/hargata/lubelogger:v1.7.4 (Spiegel auf Docker Hub laut Doku)
Port8080/TCP im Container (HTTP)
Volumes/App/data (Datenbank, Konfiguration, Anhänge), /root/.aspnet/DataProtection-Keys (Cookie-Schlüssel)
Wichtige EnvLC_ALL, LANG, TZ, optional POSTGRES_CONNECTION, MailConfig__*, OpenIDConfig__*
DatenbankLiteDB (eingebaut), alternativ PostgreSQL
LizenzMIT

Verifizieren: docker compose config zeigt das aufgelöste Image ghcr.io/hargata/lubelogger:v1.7.4 ohne Warnung über eine fehlende Variable.

Schritt 2: Container starten

docker compose pull
docker compose up -d
docker compose logs --no-log-prefix | head -n 12

Im Log erscheinen die Versionszeile und die angelegten Verzeichnisse:

LubeLogger 1.7.4
SMTP Not Configured
Created images directory
Created documents directory
...
Now listening on: http://[::]:8080

Die Warnung No XML encryptor configured. Key ... may be persisted to storage in unencrypted form. ist normal: Die Cookie-Schlüssel liegen unverschlüsselt im Volume keys. Behandeln Sie dieses Volume deshalb wie ein Passwort.

Für Monitoring bietet LubeLogger einen anonymen Health-Endpunkt:

curl -s localhost:8080/health
{"status":"pass","version":"1.7.4","checks":[{"name":"LubeLogger database connections health check","status":"pass"}]}

Verifizieren: docker compose ps meldet den Dienst als Up, curl -s localhost:8080/health liefert "status":"pass" mit der erwarteten Versionsnummer.

Schritt 3: Authentifizierung sofort einschalten

Das ist der wichtigste Schritt. Ohne Konfiguration verlangt LubeLogger keine Anmeldung. Im Test nahm die API direkt nach dem Start einen Fahrzeugeintrag ohne jede Zugangsdaten an:

curl -s -H "Content-Type: application/json" \
  -d '{"Year":"2019","Make":"Volkswagen","Model":"Caddy","Identifier":"LicensePlate","LicensePlate":"DD-SE 4711","FuelType":"Diesel"}' \
  localhost:8080/api/vehicles/add
{"success":true,"message":"Vehicle Added","additionalData":{"vehicleId":1}}

Öffnen Sie deshalb http://SERVER:8080, wechseln Sie zu Settings, Reiter Admin, und aktivieren Sie Enable Authentication. Der Dialog fragt Benutzername und Passwort des Root-Benutzers ab. Verwenden Sie ein langes Passwort ohne Doppelpunkt, weil die API Basic Auth nutzt und dort der Doppelpunkt Benutzer und Passwort trennt.

Einstellungen von LubeLogger im Reiter Admin mit aktivierter Authentifizierung und Backup-Schaltflächen
Im Reiter Admin: Authentifizierung einschalten sowie Backups erstellen und einspielen.

Der Root-Benutzer sieht alle Fahrzeuge und darf als einziger Backups erstellen und einspielen. Für die tägliche Arbeit empfiehlt die Dokumentation einen zweiten Admin-Benutzer, den Sie im Admin Panel per Einladungstoken anlegen.

Verifizieren: Ohne Anmeldung leitet curl -s -o /dev/null -w "%{http_code}" localhost:8080/ mit 302 auf /Login/Index um, /api/vehicles antwortet mit 401. Mit curl -u admin:PASSWORT localhost:8080/api/vehicles erhalten Sie die Fahrzeugliste als JSON.

Schritt 4: Hinter einen Reverse Proxy stellen

LubeLogger spricht selbst nur HTTP. Für den Zugriff über das Internet gehört ein Reverse Proxy mit TLS davor, zum Beispiel Caddy mit automatischem HTTPS. Ein minimaler Eintrag im Caddyfile:

fuhrpark.example.de {
    reverse_proxy 127.0.0.1:8080
}

Läuft der Proxy auf demselben Host, sollten Sie das Port-Mapping in der Compose-Datei auf "127.0.0.1:8080:8080" einschränken, damit Port 8080 nicht zusätzlich offen im Netz steht.

Verifizieren: curl -I https://fuhrpark.example.de/ liefert 302 mit Location: .../Login/Index, und ss -tlnp | grep 8080 zeigt nur noch 127.0.0.1:8080.

Schritt 5: Fahrzeuge, Wartungen und Tankvorgänge erfassen

Nach der Anmeldung zeigt die Garage alle Fahrzeuge als Karten. Über das Plus legen Sie ein neues Fahrzeug mit Baujahr, Hersteller, Modell und Kennzeichen an.

Garage-Ansicht von LubeLogger mit zwei Fahrzeugkarten und einer Karte zum Hinzufügen
Die Garage zeigt alle Fahrzeuge als Karten, über das Plus kommt ein neues hinzu.

Innerhalb eines Fahrzeugs verteilen sich die Daten auf Reiter: Service Records für planmäßige Wartung, Repairs für Reparaturen, Fuel für Tankvorgänge, dazu Steuern, Notizen und Erinnerungen. Jeder Eintrag nimmt Datum, Kilometerstand, Beschreibung, Kosten und optional Belege auf.

Reiter Service Records eines Fahrzeugs mit zwei Wartungseinträgen und Gesamtkosten
Wartungseinträge mit Datum, Kilometerstand und Kosten im Reiter Service Records.

Dieselben Einträge legen Sie per API an, etwa aus einem Werkstattsystem. Eine Wartung für Fahrzeug 1:

curl -s -u admin:PASSWORT -H "Content-Type: application/json" \
  -d '{"Date":"2026-10-17","Odometer":"84250","Description":"Ölwechsel 5W-30","Cost":"189,90","Notes":"Werkstatt"}' \
  "localhost:8080/api/vehicle/servicerecords/add?vehicleId=1"
{"success":true,"message":"Service Record Added","additionalData":{"recordId":1}}

Beträge übergeben Sie im Format der eingestellten Locale, hier also mit Komma. Für Tankvorgänge verlangt /api/vehicle/gasrecords/add zusätzlich FuelConsumed, IsFillToFull und MissedFuelUp. Aus mehreren Volltankungen berechnet LubeLogger den Verbrauch in l/100 km. Die API-Beschreibung liefert Ihre Instanz unter /api.

Reiter Fuel mit drei Tankvorgängen, Verbrauch in Litern pro 100 Kilometer und Kosten
Aus Volltankungen berechnet LubeLogger den Verbrauch in l/100 km.

Verifizieren: curl -s -u admin:PASSWORT "localhost:8080/api/vehicle/servicerecords?vehicleId=1" gibt den Eintrag mit Datum 17.10.2026 und Kosten 189,90 zurück, und er erscheint im Reiter Service Records.

Schritt 6: Backup anlegen

LubeLogger bringt eine Backup-Funktion mit: in der Oberfläche unter Settings, Admin, Backups, Create, per API über /api/makebackup. Beides erfordert den Root-Benutzer. Mit output=download liefert die API die ZIP-Datei direkt aus, was sich für einen Cronjob eignet:

mkdir -p /srv/backup/lubelogger
curl -fsS -u "admin:$(cat /root/.lubelogger-pw)" \
  -o /srv/backup/lubelogger/lubelogger-$(date +%F-%H%M).zip \
  "http://127.0.0.1:8080/api/makebackup?output=download"

Die Datei /root/.lubelogger-pw enthält nur das Passwort und gehört root mit Rechten 600. Im Test enthielt das ZIP genau zwei Dateien: data/cartracker.db und config/userConfig.json, bei Bedarf zusätzlich Bilder, Dokumente, Übersetzungen und Themes. Was fehlt, sind die Cookie-Schlüssel aus dem Volume keys. Sichern Sie deshalb zusätzlich beide Volumes bei gestopptem Container:

cd /opt/lubelogger
docker compose stop app
docker run --rm -v lubelogger_data:/data:ro -v /srv/backup/lubelogger:/backup alpine \
  tar czf /backup/lubelogger-data.tgz -C /data .
docker run --rm -v lubelogger_keys:/k:ro -v /srv/backup/lubelogger:/backup alpine \
  tar czf /backup/lubelogger-keys.tgz -C /k .
docker compose start app

Der Präfix lubelogger_ entspricht dem Projektordner (docker volume ls). Jedes Backup bleibt zusätzlich als ZIP im Ordner data/temp liegen. Der Aufruf /api/cleanup räumt diesen Ordner auf, im Test meldete er {"temp_files_deleted":"3"}.

Verifizieren: unzip -l lubelogger-*.zip listet data/cartracker.db und config/userConfig.json, tar tzf lubelogger-keys.tgz zeigt mindestens eine Datei key-*.xml.

Schritt 7: Wiederherstellen

Für den Test wurden Wartungseintrag und Fahrzeug per API gelöscht; danach lieferten /api/vehicles und /api/vehicle/servicerecords/all nur noch leere Listen. Anschließend wurde die ZIP-Datei über Settings, Admin, Backups, Restore eingespielt. Die Funktion antwortete mit true, Fahrzeug und Wartungseintrag mit identischem Datum, Kilometerstand und Betrag waren sofort wieder da, ohne Neustart.

Für den Totalverlust, etwa nach einem Serverwechsel, greifen Sie auf die Volume-Archive zurück:

cd /opt/lubelogger
docker compose up -d && docker compose stop app
docker run --rm -v lubelogger_data:/data -v /srv/backup/lubelogger:/backup:ro alpine \
  sh -c "rm -rf /data/* && tar xzf /backup/lubelogger-data.tgz -C /data"
docker run --rm -v lubelogger_keys:/k -v /srv/backup/lubelogger:/backup:ro alpine \
  sh -c "rm -rf /k/* && tar xzf /backup/lubelogger-keys.tgz -C /k"
docker compose start app

Im Test wurden beide Volumes mit docker compose down -v vollständig entfernt. Wichtig dabei: Die frisch gestartete, leere Instanz war wieder ohne Anmeldung erreichbar, bis die Daten zurück waren. Nach dem Zurückspielen des Daten-Archivs waren Marker-Eintrag und Authentifizierung wieder aktiv, ein vorher ausgestelltes Login-Cookie wurde aber abgewiesen (302 zur Anmeldung). Erst mit dem Schlüssel-Archiv akzeptierte LubeLogger das alte Cookie wieder. Ohne Schlüssel-Backup verlieren Sie also keine Daten, alle Benutzer müssen sich aber neu anmelden.

Verifizieren: curl -s -u admin:PASSWORT "localhost:8080/api/vehicle/servicerecords?vehicleId=1" liefert die gesicherten Einträge, und /api/vehicles ohne Zugangsdaten antwortet wieder mit 401.

Schritt 8: Updates einspielen

Erstellen Sie vor jedem Update ein Backup nach Schritt 6. Danach ändern Sie nur das Tag in der .env:

sed -i 's/^LUBELOGGER_TAG=.*/LUBELOGGER_TAG=v1.7.4/' .env
docker compose pull
docker compose up -d
docker compose logs --no-log-prefix | grep "LubeLogger 1"

Im Test lief die Instanz zunächst mit v1.7.3, inklusive Marker, Backup und Restore. Nach dem Wechsel auf v1.7.4 meldeten Log und /health die neue Version, alle Einträge waren vorhanden und bestehende Sitzungen blieben gültig. Lesen Sie vorher die Release-Notes: Version 1.7.1 schloss mehrere IDOR-Lücken, 1.7.4 korrigiert die Rechteprüfung für API-Schlüssel. Für die Benachrichtigung über neue Tags eignet sich ein Werkzeug wie Diun oder WUD, siehe Docker-Container-Updates mit Diun und WUD.

Verifizieren: curl -s localhost:8080/health zeigt "version":"1.7.4", docker compose ps zeigt das neue Image-Tag, und ein bekannter Eintrag ist per API abrufbar.

Troubleshooting

Die folgenden Fehlerbilder traten im Test real auf:

  • failed to resolve reference "ghcr.io/hargata/lubelogger:1.7.4": not found: Das Tag braucht das v, also v1.7.4.
  • Bind for 0.0.0.0:8080 failed: port is already allocated: Ein anderer Dienst belegt Port 8080. Ändern Sie die linke Seite des Mappings, etwa "8081:8080", oder beenden Sie den anderen Dienst und starten Sie mit docker compose up -d --force-recreate neu.
  • Backup-Aufruf liefert HTTP 500, im Log steht The file '/App/data/temp/db_backup_....zip' already exists.: Zwei Backups innerhalb derselben Sekunde erzeugen denselben Dateinamen. Rufen Sie /api/makebackup nicht doppelt hintereinander auf.
  • Input object invalid, Date, Description, Odometer, and Cost cannot be empty. (HTTP 400): Ein Pflichtfeld fehlt oder der Feldname enthält ein Leerzeichen.
  • Fuel Type must be either Gasoline, Diesel, or Eletric (HTTP 400): FuelType akzeptiert nur die englischen Werte Gasoline, Diesel und Electric.
  • Falsche Zugangsdaten: Die API antwortet mit 401 und einer HTML-Seite Access Denied statt JSON. Das Log zeigt Failure message: Invalid credentials. Die Info-Meldungen Cookie is invalid or does not exist bei anonymen Aufrufen sind normal.
  • Nach einem Restore sind alle abgemeldet: Das Volume keys wurde nicht mit zurückgespielt. Die Daten sind vollständig, eine neue Anmeldung genügt.

Laut Dokumentation entstehen ERR_TOO_MANY_REDIRECTS und Einstellungen, die erst nach einem Neustart greifen, durch ein erschöpftes inotify-Limit des Hosts (Standard 128).

Häufige Fragen

Brauche ich PostgreSQL?

Für einen kleinen oder mittleren Fuhrpark nicht. Die eingebaute LiteDB-Datei reicht und macht das Backup einfach. Mit PostgreSQL sichert die eingebaute Backup-Funktion laut Doku nur noch Bilder, Dokumente und Konfiguration; die Datenbank müssen Sie dann selbst mit pg_dump sichern.

Ist die Oberfläche auf Deutsch?

Die Menüs sind standardmäßig Englisch. Zahlen, Währung und Datum folgen der Locale aus LC_ALL und LANG. Übersetzungsdateien bindet der Root-Benutzer unter Settings, Admin, Manage Languages ein.

Wie greifen Skripte auf die API zu?

Per Basic Auth mit Benutzername und Passwort oder mit API-Schlüsseln, die sich auf die Rollen Viewer, Editor und Manager beschränken lassen. Für Backups über /api/makebackup sind Root-Zugangsdaten nötig.

Kann LubeLogger an fällige Wartungen erinnern?

Ja, über Erinnerungen je Fahrzeug nach Datum oder Kilometerstand. Für den Versand per E-Mail konfigurieren Sie SMTP im Server Settings Configurator unter /setup; alternativ gehen Benachrichtigungen an Dienste wie ntfy oder Gotify.

Fazit

LubeLogger ist eine angenehm schlanke Lösung für die Fahrzeugverwaltung im eigenen Haus: ein Container, wenig Speicher, eine verständliche Oberfläche und eine brauchbare API. Zwei Punkte sollten Sie kennen: Jede neue oder leere Instanz startet ohne Anmeldung, und die eingebaute Backup-Funktion sichert die Cookie-Schlüssel nicht. Wer die Authentifizierung sofort einschaltet, das ZIP-Backup per Cronjob zieht und die beiden Volumes zusätzlich sichert, bekommt einen wartungsarmen Dienst, der sich in wenigen Minuten wiederherstellen und aktualisieren lässt. Für eine allgemeine Inventarverwaltung neben dem Fuhrpark lohnt ein Blick auf Homebox.

Weiterführende Anleitungen und Quellen

LubeLoggerDocker ComposeFuhrparkFahrzeugverwaltungSelfhostingBackupREST-API