Traccar mit Docker Compose selbst hosten: GPS-Tracking-Server im Eigenbetrieb

Traccar ist ein quelloffener GPS-Tracking-Server, der Positionsmeldungen von Fahrzeug-Trackern, Asset-Trackern und Smartphone-Apps entgegennimmt, speichert und in einer Weboberfläche auf einer Karte darstellt. Wer Standortdaten nicht an einen Cloud-Anbieter geben will oder kann, betreibt den Server selbst. Diese Anleitung zeigt eine vollständige Installation mit Docker Compose, den Funktionscheck, die Absicherung und den Weg zu einer produktionstauglichen Datenbank.

Der praktische Teil wurde am 23.09.2026 auf einem Linux-Host mit dem Image traccar/traccar:6.15.3-alpine tatsächlich ausgeführt. Alle Angaben, die hier als geprüft markiert sind, stammen aus diesem Lauf. Alles übrige ist ausdrücklich als laut offizieller Dokumentation gekennzeichnet, damit Sie wissen, worauf Sie sich verlassen können und was Sie in Ihrer eigenen Umgebung noch verifizieren müssen.

Nutzen und Grenzen

Traccar ist ein Tracking-Server, kein vollständiges Flottenmanagement. Er nimmt Positionen entgegen, hält Historie vor, zeigt Karten, Geofences, Reports und Benachrichtigungen. Was er nicht mitbringt, ist eine Abrechnungsschicht, Auftrags- oder Tourenplanung, Lohnabrechnung oder eine Werkstattverwaltung. Wer diese Funktionen braucht, nutzt Traccar als Datenlieferant und setzt eigene Auswertungen auf die API.

Das Projekt ist aktiv. Laut GitHub-API, abgerufen am 23.09.2026, hat das Repository traccar/traccar 7790 Sterne, der letzte Push datiert auf den 22.09.2026, das Repository ist nicht archiviert und steht unter Apache-2.0. Das aktuelle Release ist v6.15.3 vom 26.08.2026. Weitere Popularitäts- oder Wachstumszahlen nennen wir hier bewusst nicht, weil wir sie nicht selbst erhoben haben.

Datenschutz vorher klären, nicht danach

Standortdaten von Mitarbeitenden sind personenbezogene Daten. Wer Firmenfahrzeuge mit Fahrerzuordnung trackt, verarbeitet damit Daten über das Verhalten konkreter Personen. Zweckbindung, Speicherdauer, Zugriffsberechtigungen und die Beteiligung einer vorhandenen Arbeitnehmervertretung gehören vor die technische Inbetriebnahme, nicht danach. Diese Anleitung ist eine technische Anleitung und keine Rechtsberatung; welche Pflichten und Folgen sich in Ihrem konkreten Fall ergeben, klären Sie mit Ihrem Datenschutzbeauftragten und gegebenenfalls anwaltlich. Technisch unterstützen lässt sich das Ganze, indem Sie die Historienaufbewahrung begrenzen, getrennte Benutzerkonten mit eingeschränkter Gerätesicht anlegen und den Zugriff auf die Weboberfläche netzseitig einschränken.

Voraussetzungen und Ressourcenbedarf

• Ein Linux-Server mit Docker Engine und dem Compose-Plugin (docker compose version muss antworten).
• Root- oder sudo-Rechte auf dem Host, weil Verzeichnisse unter /opt angelegt und Ports veröffentlicht werden.
• Freie Ports: 8082/TCP für die Weboberfläche sowie mindestens ein Protokoll-Port aus dem Bereich ab 5000 für die Geräte.
• Traccar ist ein Java-Server. Im Test lief er unter der JVM-Version 25.0.4+7-LTS mit Jetty 12.1.12, beides aus dem Container-Log ./logs/tracker-server.log abgelesen. Sie müssen auf dem Host kein Java installieren, die JVM steckt im Image.
• Planen Sie Arbeitsspeicher für eine JVM ein. Für einen Testbetrieb mit wenigen Geräten reichten im Lauf die Standardwerte ohne zusätzliche Limits; harte Zahlen für größere Installationen haben wir nicht gemessen und nennen daher keine.
• Geduld beim ersten Start: Der Container lief im Test nach 52 Sekunden, die Weboberfläche antwortete erst nach etwa einer Minute. Das ist normal für einen JVM-Dienst und kein Fehler.

Unterstützte Plattformen und getestete Version

Laut offizieller Docker-Dokumentation stellt das Projekt offizielle Images auf Docker Hub bereit, und zwar in drei Basisvarianten: Alpine, Debian und Ubuntu. Alle drei Varianten werden als Multi-Plattform-Images für linux/amd64 und linux/arm64 gebaut. Damit läuft Traccar auf einem klassischen x86-Server ebenso wie auf ARM-Hardware.

Empfohlene Tags laut Dokumentation sind 6.15.3, 6.15, 6, 6.15.3-alpine, 6.15-alpine, 6-alpine und latest, dazu die Debian-Reihe 6.15.3-debian, 6.15-debian, 6-debian, debian und die Ubuntu-Reihe 6.15.3-ubuntu, 6.15-ubuntu, 6-ubuntu, ubuntu. Für Produktivsysteme pinnen Sie den vollen Patchstand, also etwa 6.15.3-alpine, und heben ihn bewusst an, statt latest laufen zu lassen.

Geprüft haben wir genau eine Kombination: traccar/traccar:6.15.3-alpine auf linux/amd64. Der Endpunkt /api/server meldete daraufhin "version":"6.15.3". Debian- und Ubuntu-Variante sowie ARM64 haben wir nicht selbst ausprobiert.

Vollständige compose.yaml

Legen Sie zuerst das Zielverzeichnis samt Unterordnern und der leeren Konfigurationsdatei an. Das ist wichtig: Wenn traccar.xml beim ersten Start nicht als Datei existiert, legt Docker an ihrer Stelle ein Verzeichnis an, und der Container startet nicht sauber.

# Verzeichnisstruktur und leere Konfigurationsdatei anlegen
sudo mkdir -p /opt/traccar/logs /opt/traccar/data
sudo touch /opt/traccar/traccar.xml
cd /opt/traccar

Danach die Datei /opt/traccar/compose.yaml anlegen:

services:
  traccar:
    image: traccar/traccar:6.15.3-alpine
    container_name: traccar
    hostname: traccar
    restart: unless-stopped
    ports:
      # Weboberflaeche, hier nur auf localhost, davor ein Reverse Proxy
      - "127.0.0.1:8082:8082"
      # Nur die Protokoll-Ports der tatsaechlich genutzten Geraete oeffnen
      - "5055:5055"
      - "5055:5055/udp"
    volumes:
      - ./logs:/opt/traccar/logs:rw
      - ./data:/opt/traccar/data:rw
      - ./traccar.xml:/opt/traccar/conf/traccar.xml:ro

Parametererklärungen

• image: fester Patchstand statt latest. Nur so wissen Sie nach einem docker compose pull, was sich geändert hat.
• hostname: traccar: entspricht dem offiziellen Startbeispiel und taucht in Logs und Benachrichtigungen auf.
• restart: unless-stopped: der Dienst kommt nach einem Hostneustart von allein zurück, bleibt aber unten, wenn Sie ihn bewusst gestoppt haben.
• 127.0.0.1:8082:8082: die Weboberfläche ist damit nicht direkt aus dem Netz erreichbar. Den öffentlichen Zugang übernimmt ein Reverse Proxy mit TLS. Wer ohne Proxy testen will, lässt die Bindung an 127.0.0.1 weg, sollte das aber nicht dauerhaft so betreiben.
• 5055 in TCP und UDP: der Port des Traccar-Client-Protokolls (OsmAnd-Protokoll). Welche Portnummer Ihr Gerät braucht, steht in der Protokollliste des Projekts. Nehmen Sie genau die Ports auf, die Sie wirklich einsetzen.
• ./logs, ./data, ./traccar.xml: die von der Dokumentation empfohlenen Mounts. Die Konfiguration wird bewusst nur lesend (:ro) eingebunden.

Zum Vergleich das offizielle Startbeispiel der Dokumentation, das den kompletten Portbereich veröffentlicht:

# Offizielles Beispiel der Traccar-Dokumentation, bewusst mit vollem Portbereich
docker run --name traccar --hostname traccar --detach --restart unless-stopped \
  --publish 80:8082 \
  --publish 5000-5300:5000-5300 \
  --publish 5000-5300:5000-5300/udp \
  traccar/traccar:latest

Warum der volle Portbereich 5000 bis 5300 ein Problem ist

Die offizielle Dokumentation weist ausdrücklich darauf hin: Wer den gesamten Bereich 5000 bis 5300 veröffentlicht, startet für jeden einzelnen Port einen eigenen docker-proxy-Prozess, und zwar getrennt für TCP und UDP. Das verbraucht sehr viel Arbeitsspeicher und kann unter Last Verbindungen lecken.

Die Dokumentation nennt zwei Gegenmittel. Erstens: den Userland-Proxy abschalten, damit Docker stattdessen iptables-NAT verwendet. Dazu trägt man in /etc/docker/daemon.json ein:

# Userland-Proxy abschalten, danach Docker neu starten
sudo tee /etc/docker/daemon.json >/dev/null <<'JSON'
{ "userland-proxy": false }
JSON
sudo systemctl restart docker

Zweitens: nur die Ports der tatsächlich genutzten Protokolle veröffentlichen. Für die meisten KMU-Installationen ist das die bessere Empfehlung, und zwar aus drei Gründen. Die Veränderung bleibt auf den Traccar-Stack beschränkt, während userland-proxy: false das Verhalten des gesamten Docker-Daemons und damit aller anderen Container auf dem Host ändert. Ein Betrieb mit drei oder fünf Gerätemodellen braucht keine 301 offenen Ports, und jeder nicht veröffentlichte Port ist eine Angriffsfläche weniger. Und drittens ist die Portliste in der compose.yaml dokumentiert und nachvollziehbar, während eine Daemon-Einstellung beim nächsten Serverumzug gern vergessen wird. Greifen Sie zum Abschalten des Userland-Proxys erst, wenn Sie wirklich einen großen, gemischten Gerätepark betreiben.

Installation und Start

# Image ziehen und Stack starten
cd /opt/traccar
sudo docker compose pull
sudo docker compose up -d

# Status pruefen und die Startphase im Log mitlesen
sudo docker compose ps
sudo docker compose logs -f traccar

Rechnen Sie mit einer spürbaren Wartezeit. Im Test lief der Container nach 52 Sekunden, die Weboberfläche antwortete erst nach rund einer Minute. Das Log zeigte danach Jetty 12.1.12, die JVM 25.0.4+7-LTS und die Zeile Started oejs.ServerConnector ... 0.0.0.0:8082; die gemeldete Gesamtstartzeit lag bei @6280ms nach dem JVM-Start.

Erstkonfiguration und erstes Konto

Ein wichtiger Punkt gleich vorweg, den wir selbst geprüft haben: Es gibt in dieser Version im Standard-Setup keine funktionierenden Standardzugangsdaten. Ein POST /api/session mit email=admin und password=admin beantwortete der Server im Test mit HTTP 401. Suchen Sie also nicht nach einem vorgegebenen Admin-Passwort in der Dokumentation, es gibt keines.

Stattdessen legen Sie das erste Konto über die Weboberfläche an. Rufen Sie die Oberfläche auf (bei lokaler Bindung per SSH-Tunnel, später über den Reverse Proxy) und nutzen Sie die Registrierung. Ob die Registrierung offen ist, verrät der Server selbst: Im Test meldete /api/server den Wert "registration":false. Steht dort false, müssen Sie die Registrierung zuerst in traccar.xml aktivieren, das erste Konto anlegen und sie danach wieder abschalten. Der Ablauf der Kontoanlage in der Weboberfläche selbst wurde in unserem Testlauf nicht durchgeführt und ist hier nur dokumentiert.

# SSH-Tunnel auf die lokal gebundene Weboberflaeche, vom Arbeitsplatz aus
ssh -L 8082:127.0.0.1:8082 admin@ihr-server.example.com

Die traccar.xml ist eine XML-Properties-Datei. Der Container startete im Test auch ohne eigene Konfigurationsdatei mit den Standardwerten, ein Mount der Datei wurde für den Lauf weggelassen. Für den Produktivbetrieb brauchen Sie sie trotzdem, spätestens für die Datenbankeinstellungen.

Funktions- und Healthcheck

Der zuverlässigste Check ist der Endpunkt /api/server. Er liefert ohne Anmeldung JSON mit der Serverversion und dem Registrierungsstatus und eignet sich damit gut als Monitoring-Check, denn er beweist, dass die JVM steht, Jetty hört und die Anwendung ihre Konfiguration geladen hat.

# Weboberflaeche und API pruefen
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8082/
curl -s http://127.0.0.1:8082/api/server | head -c 400

Im Test antwortete GET / mit HTTP 200 und /api/server lieferte JSON, das unter anderem "version":"6.15.3" und "registration":false enthielt. Ebenfalls geprüft: GET /api/session ohne gültige Sitzung antwortet mit HTTP 404, nicht mit 401. Wer also einen Monitoring-Check gegen /api/session baut und auf 401 prüft, bekommt ein falsches Ergebnis. Nehmen Sie /api/server.

Wenn Sie einen Container-Healthcheck ergänzen wollen, geben Sie ihm wegen der langen Startzeit eine großzügige start_period:

    healthcheck:
      test: ["CMD-SHELL", "wget -qO- http://127.0.0.1:8082/api/server || exit 1"]
      interval: 30s
      timeout: 5s
      retries: 3
      start_period: 120s

Ob das Image wget oder curl mitbringt, prüfen Sie vor dem Einbau mit docker compose exec traccar wget --version. Diesen Healthcheck-Block haben wir im Testlauf nicht mitlaufen lassen; die Startdauer, auf der die start_period beruht, dagegen schon. Wie Sie solche Endpunkte dauerhaft überwachen, zeigt unsere Monitoring-Anleitung weiter unten.

Persistente Daten und Rechte

Alle Nutzdaten liegen im Verzeichnis data. Nach dem ersten Start fanden sich dort im Test die Dateien database.mv.db mit 544768 Bytes und database.trace.db. Das ist die eingebaute H2-Datenbank. Wird dieses Verzeichnis gelöscht, sind alle Geräte, Benutzer und Positionen weg.

Wichtig für Aufräumarbeiten und Backup-Skripte: Die Dateien in ./data gehörten im Test dem Benutzer root, nicht dem Host-Benutzer. Ein rm -rf oder ein tar als unprivilegierter Benutzer scheitert deshalb mit Permission denied. Greifen Sie mit sudo zu oder lassen Sie die Arbeit von einem kurzlebigen Container erledigen.

# Eigentumsverhaeltnisse im Datenverzeichnis ansehen
sudo ls -la /opt/traccar/data

Netzwerkfreigabe und Reverse Proxy mit TLS

Hier liegt der Punkt, an dem Traccar sich von einer gewöhnlichen Webanwendung unterscheidet, und er wird regelmäßig falsch gemacht. Der Reverse Proxy kümmert sich ausschließlich um die Weboberfläche und die REST-API auf Port 8082. Die Geräteprotokoll-Ports ab 5000 laufen nicht über den HTTP-Reverse-Proxy. Viele Tracker sprechen binäre TCP- oder UDP-Protokolle, die ein HTTP-Proxy nicht terminieren kann. Diese Ports gehen direkt an den Container und brauchen deshalb eigene Firewallregeln.

Praktisch heißt das:

• Port 8082 bindet nur auf 127.0.0.1 und wird vom Reverse Proxy bedient. Nach außen sind nur 80 und 443 offen.
• Jeder eingesetzte Protokoll-Port wird einzeln in der Firewall freigegeben, TCP und UDP getrennt, so wie er in der compose.yaml steht.
• Wenn die Tracker aus festen Netzen oder von bekannten Mobilfunk-Gateways kommen, schränken Sie die Freigabe per Quell-IP ein.
• Alles, was Sie nicht einsetzen, bleibt zu. Das ist der gleiche Gedanke, der oben gegen die Freigabe des kompletten Bereichs 5000 bis 5300 spricht.

# Beispiel mit ufw: Web nur ueber den Proxy, Geraeteport einzeln
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 5055/tcp
sudo ufw allow 5055/udp
sudo ufw status numbered

Beachten Sie, dass Docker mit veröffentlichten Ports eigene iptables-Regeln schreibt und ufw dabei je nach Konfiguration umgangen werden kann. Prüfen Sie die Erreichbarkeit deshalb immer von außen nach, statt sich allein auf ufw status zu verlassen.

Für TLS verweist die offizielle Dokumentation auf ihren Secure-Connection-Leitfaden, der einen Caddy-Reverse-Proxy sowohl eigenständig als auch als Compose-Dienst behandelt. Das Vorgehen entspricht dem, was wir in unserer Caddy-Anleitung ausführlich beschreiben, deshalb wiederholen wir es hier nicht. Der relevante Block ist minimal: eine Site mit Ihrem Hostnamen und ein reverse_proxy auf 127.0.0.1:8082. Den HTTPS-Betrieb über Caddy haben wir in diesem Lauf nicht getestet.

Umstieg von H2 auf MySQL oder PostgreSQL

Die eingebaute H2-Datenbank ist praktisch für den ersten Start, wird laut offizieller Dokumentation für den Produktivbetrieb aber ausdrücklich nicht empfohlen. Die Dokumentation empfiehlt stattdessen TimescaleDB für große Installationen und MySQL für kleinere Server, und sie verweist auf fertige Compose-Beispiele für Traccar mit MySQL und für Traccar mit TimescaleDB auf PostgreSQL-Basis.

Der Grund ist die Datenmenge. Ein einzelner Tracker, der alle 30 Sekunden meldet, erzeugt pro Tag einige tausend Positionszeilen. Bei zehn Fahrzeugen und einer Historie über Monate wird aus der H2-Datei schnell ein Klotz, der bei jedem Start gelesen werden will und bei dem eine defekte Datei den kompletten Bestand kostet. Eine echte Datenbank bringt dagegen Online-Dumps, Replikation und getrennte Wartungsfenster mit.

Der Umstieg erfolgt über die Datenbankeinträge in traccar.xml, die dann auf den Datenbankcontainer statt auf die lokale H2-Datei zeigen. Wichtig dabei: Als Hostname gehört der Compose-Servicename in die Verbindungszeichenfolge, nicht localhost. Aus Sicht des Traccar-Containers ist localhost der Container selbst. Planen Sie den Wechsel als Neuaufsetzen mit anschließender Datenmigration ein und nicht als reine Konfigurationsänderung. Wir haben weder den MySQL- noch den TimescaleDB-Betrieb in diesem Lauf getestet; dieser Abschnitt beruht auf der offiziellen Dokumentation.

Backup und Wiederherstellung

Das Backup-Verfahren hängt an der gewählten Datenbank.

Mit H2: Die Datei data/database.mv.db ist die Datenbank. Sichern Sie sie im gestoppten Zustand. Eine Kopie einer laufenden H2-Datei kann inkonsistent sein, und Sie merken das typischerweise erst beim Wiederherstellen.

# Offline-Backup der H2-Datenbank
cd /opt/traccar
sudo docker compose stop
sudo tar czf /var/backups/traccar-$(date +%F).tar.gz data traccar.xml compose.yaml
sudo docker compose start

Mit MySQL oder PostgreSQL: Sichern Sie nicht die Datendateien, sondern einen Datenbankdump, zum Beispiel per mysqldump beziehungsweise pg_dump aus dem Datenbankcontainer heraus. Das funktioniert im laufenden Betrieb und liefert eine konsistente, portable Datei. Die traccar.xml gehört in jedem Fall mit ins Backup, denn ohne sie kennt eine frische Instanz die Datenbank nicht.

Wiederherstellung mit H2: Stack stoppen, das Verzeichnis data beiseitelegen, den Inhalt aus dem Archiv zurückspielen und erst dann starten. Achten Sie darauf, dass die Dateien wieder root gehören, sonst kann der Container sie nicht öffnen.

# Wiederherstellung aus dem Offline-Backup
cd /opt/traccar
sudo docker compose down
sudo mv data data.alt
sudo tar xzf /var/backups/traccar-2026-09-23.tar.gz -C /opt/traccar
sudo docker compose up -d

Eine tatsächliche Wiederherstellung aus einem Backup haben wir in diesem Lauf nicht durchgeführt. Testen Sie den Restore deshalb unbedingt einmal auf einem Zweitsystem, bevor Sie sich im Ernstfall darauf verlassen. Ein Backup, das nie zurückgespielt wurde, ist kein Backup, sondern eine Hoffnung.

Updates und Rollback-Grenzen

# Update auf einen neuen Patchstand
cd /opt/traccar
# 1. Backup wie oben, im gestoppten Zustand
# 2. Image-Tag in compose.yaml auf die neue Version setzen
sudo docker compose pull
sudo docker compose up -d
sudo docker compose logs -f traccar

Der entscheidende Punkt beim Update ist die Datenbank. Traccar führt Schemamigrationen beim Start durch. Eine einmal migrierte Datenbank lässt sich nicht einfach mit einem älteren Image weiterbetreiben; das Zurücksetzen des Image-Tags allein ist kein Rollback. Ein belastbarer Rückweg besteht deshalb immer aus zwei Teilen: altes Image-Tag und die vor dem Update gesicherte Datenbank. Genau deshalb steht das Backup an Schritt eins und nicht an Schritt drei.

Prüfen Sie nach dem Update die gemeldete Version mit curl -s http://127.0.0.1:8082/api/server und sehen Sie vorher in die Release-Notes, ob der Sprung Breaking Changes enthält. Ein Update auf eine neuere Version haben wir in diesem Lauf nicht durchgeführt.

Typische Fehler mit Diagnose und Lösung

• Die Weboberfläche antwortet direkt nach dem Start nicht. Diagnose: curl liefert Exit-Code 7 oder HTTP-Code 000, der Container steht aber laut docker compose ps. Lösung: warten. Im Test lief der Container nach 52 Sekunden und die Oberfläche antwortete erst nach etwa einer Minute. Erst wenn nach zwei bis drei Minuten nichts kommt, ins Log sehen.
• Anmeldung mit admin/admin schlägt fehl. Diagnose: POST /api/session antwortet mit HTTP 401, genau so im Test beobachtet. Lösung: Es gibt keine Standardzugangsdaten. Legen Sie das erste Konto über die Registrierung in der Weboberfläche an. Ob die Registrierung offen ist, zeigt "registration" in /api/server.
• Monitoring-Check gegen /api/session meldet dauerhaft Fehler. Diagnose: GET /api/session ohne Sitzung liefert HTTP 404, nicht 401; im Test bestätigt. Lösung: Check auf /api/server umstellen.
• Der Host frisst nach dem Start auffällig viel Arbeitsspeicher. Diagnose: ps aux | grep docker-proxy zeigt dutzende bis hunderte Prozesse. Ursache laut offizieller Dokumentation: die Veröffentlichung des gesamten Bereichs 5000 bis 5300 startet für jeden Port einen eigenen docker-proxy-Prozess, getrennt für TCP und UDP, und kann unter Last Verbindungen lecken. Lösung: nur die genutzten Protokoll-Ports veröffentlichen oder den Userland-Proxy abschalten.
• Der Container startet nicht, weil traccar.xml ein Verzeichnis ist. Diagnose: ls -la /opt/traccar zeigt traccar.xml als Ordner. Ursache: Die Datei existierte beim ersten Start nicht, Docker hat an ihrer Stelle ein Verzeichnis angelegt. Lösung: Stack stoppen, Verzeichnis entfernen, Datei anlegen, neu starten.
• Backup-Skript scheitert mit Permission denied. Diagnose: Die Dateien in data gehören root, im Test bestätigt. Lösung: Backup mit sudo fahren oder als root-Cronjob einrichten.
• Geräte senden, es kommt nichts an. Diagnose: Prüfen Sie zuerst, ob der Protokoll-Port überhaupt in der compose.yaml steht und ob die Firewall TCP und UDP durchlässt. Denken Sie daran, dass diese Ports nicht über den HTTP-Reverse-Proxy laufen. Die Anbindung echter GPS-Geräte oder der Traccar-Client-App haben wir nicht getestet.
• Portkonflikt beim Start. Diagnose: Docker meldet, dass der Port bereits belegt ist. Lösung: mit sudo ss -tulpn | grep 8082 den Belegen finden und entweder abschalten oder in der compose.yaml einen anderen Host-Port wählen.

Saubere Deinstallation

Der folgende Ablauf entfernt Traccar restlos. Warnung: Schritt drei löscht unwiderruflich alle Geräte, Benutzer und die komplette Positionshistorie. Legen Sie vorher ein Backup an, wenn auch nur die geringste Chance besteht, dass Sie die Daten noch brauchen.

# 1. Stack stoppen und Container entfernen
cd /opt/traccar
sudo docker compose down

# 2. Image entfernen
sudo docker image rm traccar/traccar:6.15.3-alpine

# 3. ACHTUNG: loescht die Datenbank und alle Positionsdaten endgueltig
sudo rm -rf /opt/traccar

# 4. Firewallregeln zuruecknehmen
sudo ufw status numbered
sudo ufw delete allow 5055/tcp
sudo ufw delete allow 5055/udp

Denken Sie daran, auch den Eintrag im Reverse Proxy und den passenden DNS-Datensatz zu entfernen, sonst zeigt ein Hostname ins Leere und Zertifikatserneuerungen laufen weiter auf einen nicht existierenden Dienst.

Passende Anleitungen auf S-EDV

• Caddy als Reverse Proxy mit automatischem HTTPS einrichten zeigt den TLS-Teil, auf den auch die Traccar-Dokumentation verweist.
• Linux-Server absichern mit ufw und fail2ban passt zu den Firewallregeln für die Protokoll-Ports.
• LibreNMS mit Docker Compose als Netzwerk-Monitoring ist die passende Basis, um den Healthcheck auf /api/server dauerhaft zu überwachen.

Quellen

• Traccar: Docker-Dokumentation mit Tags, Mounts und Porthinweis
• GitHub: traccar/traccar (Repository, Lizenz Apache-2.0)
• GitHub: Release-Notes von Traccar