TeslaLogger lässt sich sehr sauber auf Proxmox betreiben: als eigener, unprivilegierter Debian-LXC mit Docker Compose. So bleiben Fahrten, Ladevorgänge, Verbrauch und Grafana-Auswertungen im eigenen Homelab – und die Anwendung kann unabhängig von Home Assistant gewartet und gesichert werden.
Dieser Beitrag beschreibt nicht nur ein theoretisches Setup. In meinem Homelab läuft TeslaLogger genau in dieser Form: ein schlanker Debian-Container mit einem CPU-Kern, 1 GB RAM und 12 GB Speicher. Darin arbeiten TeslaLogger, MariaDB, Grafana, Webserver und der Update-Dienst als getrennte Container.
Warum ein eigener Proxmox-Gast?
TeslaLogger sammelt dauerhaft Fahrzeugdaten. Deshalb sollte die Instanz zuverlässig laufen, ohne dass ein Update an Home Assistant oder einer anderen Anwendung sie mitreißt. Ein eigener Gast bietet dafür klare Vorteile:
- eigene Ressourcen und ein eigener Wartungszyklus,
- saubere Proxmox- und PBS-Sicherungen,
- einfache Fehlersuche mit
docker compose psund den Container-Logs, - keine Vermischung mit der Home-Assistant-Datenbank,
- bei Bedarf eine schnelle Rückkehr zu einem funktionierenden Stand.
Wer Docker innerhalb eines LXC nicht möchte, kann dieselbe Compose-Installation auch in einer kleinen Debian-VM betreiben. Eine VM isoliert den Docker-Kernel stärker, benötigt aber etwas mehr Arbeitsspeicher. Für mein kompaktes Homelab reicht ein unprivilegierter LXC mit aktivierter Verschachtelung.
Voraussetzungen in Proxmox
Als Basis verwende ich einen unprivilegierten Debian-LXC. Für Docker im LXC werden in der Proxmox-Konfiguration üblicherweise nesting und keyctl benötigt. Mein praxiserprobtes Startprofil sieht so aus:
- Debian 13, 64 Bit,
- 1 CPU-Kern,
- 1 GB RAM plus kleiner Swap,
- 12 GB Root-Dateisystem,
- Autostart aktiviert,
- unprivilegierter Container.
Das ist ein sinnvoller Einstieg, aber keine in Stein gemeißelte Vorgabe. Wächst die Datenbank über Jahre oder werden besonders viele Grafana-Abfragen ausgeführt, sollte man Speicher und RAM beobachten und bei Bedarf erweitern.
Docker und TeslaLogger installieren
Zuerst wird Docker aus der aktuellen offiziellen Docker-Paketquelle installiert. Alte docker-compose-Pakete aus Distributionsquellen sollte man vermeiden; TeslaLogger empfiehlt eine aktuelle Docker- und Compose-Version. Anschließend wird ein eigenes Arbeitsverzeichnis angelegt:
mkdir -p /home/TeslaLogger
cd /home/TeslaLogger
mkdir -p backup mysql invoicesDie aktuelle TeslaLogger-Konfiguration kommt direkt aus dem offiziellen Repository. Das Projekt verwendet für die moderne .NET-8-Variante derzeit den Branch NET8:
wget https://raw.githubusercontent.com/bassmaster187/TeslaLogger/refs/heads/NET8/.env -O .env
wget https://raw.githubusercontent.com/bassmaster187/TeslaLogger/refs/heads/NET8/docker-compose.yml -O docker-compose.yml
docker compose pull
docker compose up -dVor dem Start sollte die .env-Datei geprüft werden, besonders Zeitzone und Portbelegung. Zugangsdaten oder Fahrzeug-Tokens gehören niemals in eine öffentliche Dokumentation, ein Git-Repository oder ein ungeschütztes Backup.
Was nach dem Start laufen sollte
Die offizielle Compose-Variante besteht aus mehreren Diensten. In meinem laufenden Setup sind das:
- der eigentliche TeslaLogger,
- eine MariaDB für die Langzeitdaten,
- Grafana für Dashboards,
- ein Webserver für das Administrationsportal,
- ein Update-Dienst.
docker compose ps
docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"Beim ersten Start braucht vor allem die Datenbank Geduld. Wenn das Webinterface anfangs noch nicht erreichbar ist, zuerst die Container-Logs prüfen und nicht sofort Volumes löschen oder das Setup neu installieren.
Tesla-Zugang und Fleet API
Die Fahrzeugverbindung wird im Administrationsbereich eingerichtet. TeslaLogger verwendet dafür Token beziehungsweise die Tesla Fleet API. Wichtig: Durch Teslas Änderungen an der Fleet API können für TeslaLogger je nach Fahrzeug und Nutzungsart laufende Kosten beziehungsweise ein Projekt-Abonnement anfallen. Vor der Einrichtung sollte deshalb der aktuelle Hinweis des Projekts gelesen werden.
Das Administrationsportal und Grafana sollten nur im Heimnetz, über ein VPN oder über einen sauber abgesicherten Reverse Proxy erreichbar sein. Eine direkte Portfreigabe ins Internet ist keine gute Idee. Nach dem ersten Grafana-Login wird das Standardkennwort sofort geändert.
Backups: Snapshot plus Datenbank
Ein Proxmox-Snapshot ist praktisch, ersetzt aber keine anwendungsnahe Sicherung. Ich kombiniere deshalb zwei Ebenen:
- regelmäßige Sicherung des gesamten LXC auf Proxmox Backup Server,
- zusätzliche TeslaLogger-/Datenbank-Sicherung innerhalb der Anwendung,
- gelegentliche Wiederherstellungsprobe in einem isolierten Testgast.
Die Backup-Verzeichnisse und Docker-Volumes müssen in der Sicherung enthalten sein. Vor größeren Updates sichere ich außerdem die Compose- und Umgebungsdatei – selbstverständlich ohne sie öffentlich abzulegen.
Updates ohne Blindflug
Vor einem Update sichere ich zuerst Datenbank und Gast. Danach prüfe ich die aktuellen Hinweise des Projekts, denn ein Wechsel der MariaDB-, Grafana- oder .NET-Basis kann zusätzliche Schritte erfordern.
cd /home/TeslaLogger
docker compose ps
docker compose pull
docker compose up -d
docker compose psAnschließend kontrolliere ich Webinterface, Grafana, Fahrzeugstatus und die neuesten Fahrten. Erst wenn neue Daten ankommen, ist das Update für mich abgeschlossen.
Mein Fazit
TeslaLogger passt hervorragend in ein Proxmox-Homelab. Der eigene LXC hält die Anwendung übersichtlich, verbraucht wenig Ressourcen und lässt sich sauber sichern. Entscheidend sind nicht möglichst viele Automatisierungen, sondern klare Grenzen: eigener Gast, keine öffentlichen Ports, aktuelle Compose-Dateien und ein überprüfbares Backup.
Wer die Fahrzeugdaten zusätzlich in sein Smart Home einbinden möchte, kann später MQTT und Home Assistant ergänzen. Ich würde aber zuerst TeslaLogger selbst stabil betreiben und die Datenqualität einige Tage beobachten.
Weiterführend: offizielle TeslaLogger-Docker-Anleitung · TeslaLogger auf GitHub · mein Tesla-Beitrag auf Xerolux