Fathom Lite 2026 selbst hosten: Tracking-Skript, SQLite und Datenschutz

Es gibt zwei Varianten, „Fathom Lite zu betreiben“: Entweder existiert ein Container, oder der Service erfüllt tatsächlich seine Aufgabe. Relevant ist nur die zweite Variante. Der Nachweis besteht darin, eine Website hinzuzufügen, das Tracking-Skript auf einer Testseite zu laden, Besuche zu erzeugen und zu bestätigen, dass das Dashboard sie ohne Cookies erfasst.

Fathom Lite ist für genau diesen Zweck gedacht: cookie-freie, selbst gehostete Page-View-Analytics. Das Deployment muss die Komponenten erhalten, die dieses Verhalten ermöglichen; ein Port, ein Volume und ein Zertifikat sind Voraussetzungen, aber noch kein Ergebnis.

Zugangsdaten, Rollen und Angriffsflächen

Bei Fathom Lite ist die wertvolle Angriffsfläche nicht unbedingt die Landingpage. Der häufigste Fehler besteht darin, ein Beispielpasswort wiederzuverwenden oder den Admin-Login ohne TLS bereitzustellen. Gehe bewusst dagegen vor: Schütze den Analytics-Login, halte das Anwendungspasswort stabil und veröffentliche das Skript nur über den erwarteten HTTPS-Host.

Behandle FATHOM_SECRET entsprechend seiner Rolle in Fathom Lite: Halte vertrauliche Werte aus Git heraus, dokumentiere die Auswirkungen einer Rotation und ersetze in der Produktion niemals ein öffentliches Beispiel. Verwende, sofern vom Image unterstützt, einen nicht privilegierten Container-User und binde keine nicht relevanten Zugangsdaten ein. Setze am Ingress Rate- oder Größenlimits, wenn nicht vertrauenswürdige Anfragen Page-View-Schreibvorgänge, Datenbankindizes, Aufbewahrung und den Netzwerkpfad von den Browsern der Besucher belasten können.

Fathom Lite von seinen Abhängigkeiten trennen

Die kleinste verantwortbare Fathom-Lite-Topologie umfasst einen privaten Listener auf 8080, eine Ingress-Route und eine dokumentierte Zustandsgrenze. Der Netzwerkvertrag von Fathom Lite besteht aus SQLite oder einer unterstützten externen Datenbank sowie der korrekten Einbindung des Client-Site-Skripts. Halte private Endpunkte im internen DNS, erlaube nur erforderliche ausgehende Verbindungen und gib Fathom Lite ein eingeschränktes Service-Credential.

Validiere die Topologie, indem du einen sauberen Client bittest, eine Website hinzuzufügen, das Tracking-Skript auf einer Testseite zu laden, Besuche zu erzeugen und zu bestätigen, dass das Dashboard sie ohne Cookies erfasst. Beobachte dabei Page-View-Schreibvorgänge, Datenbankindizes, Aufbewahrung und den Netzwerkpfad von den Browsern der Besucher. Das Ergebnis zeigt dir, ob die nächste Optimierung den Speicher, das Storage, das Networking oder einen separaten Worker betrifft, statt zu einer beliebigen Dimensionierung des Containers zu verleiten.

Eine Docker-Basis für Fathom Lite

Ein minimaler Befehl ist hilfreich, wenn er sichtbar macht, was die Plattform später verwalten wird.

docker run -d \
  --name fathom-lite \
  --restart unless-stopped \
  -p 127.0.0.1:8080:8080 \
  -v fathom-lite-data:/app \
  -e FATHOM_SECRET=replace-with-a-long-random-value \
  -e FATHOM_SERVER_ADDR=:8080 \
  -e FATHOM_DATABASE_DRIVER=sqlite3 \
  -e FATHOM_DATABASE_NAME=/app/fathom.db \
  usefathom/fathom:latest

Hier bleibt Port 8080 auf dem Host privat, und jeder erforderliche Pfad ist explizit angegeben. Ergänze die geprüften Verbindungsdaten für SQLite oder eine unterstützte externe Datenbank sowie die korrekte Einbindung des Client-Site-Skripts; verwende für private Services private Namen. Überprüfe den Start sowohl anhand der Logs als auch mit dem anwendungsspezifischen Nachweis: Füge eine Website hinzu, lade das Tracking-Skript auf einer Testseite, erzeuge Besuche und bestätige, dass das Dashboard sie ohne Cookies erfasst. Sobald alles verifiziert ist, pinne die Image-Version, damit ein routinemäßiger Austausch das Verhalten nicht unbemerkt verändert.

Das Fathom-Lite-Deployment durchgängig verifizieren

Erstelle eine kleine, kurzlebige Fathom-Lite-Testumgebung und behalte sie für jedes Release. Die Testumgebung sollte den echten Workflow abbilden: eine Website hinzufügen, das Tracking-Skript auf einer Testseite laden, Besuche erzeugen und bestätigen, dass das Dashboard sie ohne Cookies erfasst. Dokumentiere den Image-Digest, den externen Hostnamen, die Adresse der Abhängigkeit und das erwartete Ergebnis, damit ein späterer Operator den Test wiederholen kann, ohne diesen Leitfaden interpretieren zu müssen.

Führe den Test dreimal aus. Verwende zunächst das frische Deployment. Ersetze anschließend den Container, ohne den persistenten Zustand anzutasten. Stelle im dritten Durchlauf das Backup in einer leeren Umgebung wieder her. Dieser dritte Durchlauf ist nur dann erfolgreich, wenn Websites, Benutzer und historische Page Views zurückkehren und nach der Wiederherstellung ein neuer Testbesuch erscheint. Erfasse während jedes Durchlaufs Latenz und Ressourcennutzung rund um Page-View-Schreibvorgänge, Datenbankindizes, Aufbewahrung und den Netzwerkpfad von den Browsern der Besucher; daraus entsteht die Grundlage für Alerts statt eines willkürlich gewählten CPU-Prozentsatzes.

Teste abschließend bewusst den negativen Pfad: Entziehe der Testidentität vorübergehend den Zugriff auf SQLite oder eine unterstützte externe Datenbank und auf die korrekte Einbindung des Client-Site-Skripts. Bestätige, dass Fathom Lite sichtbar fehlschlägt, ohne den Zustand zu beschädigen, stelle die korrekten Bedingungen wieder her und wiederhole die erfolgreiche Transaktion. Ein Release-Eintrag mit diesen vier Ergebnissen ist ein stärkerer Nachweis als Screenshots eines Dashboards oder eine einmalige curl-Antwort.

Interne und externe URLs korrekt auseinanderhalten

Die öffentliche Grenze von Fathom Lite sollte aus einem kanonischen Hostnamen, automatischem TLS und einem internen Ziel auf 8080 bestehen. Setze die Serveradresse und den öffentlichen HTTPS-Endpunkt, den das Tracking-Skript verwendet, damit Clients zu einer Adresse zurückkehren, die der Service erkennt.

Wenn die Abnahmetransaktion fehlschlägt, klassifiziere den ersten Fehler. DNS-, Zertifikats- und 502-Probleme gehören auf die TLS-Validierungscheckliste. Die Bedingung „das Tracking-Skript verweist auf den falschen Hostnamen oder der Datenbankpfad ist flüchtig“ gehört auf die Anwendungsseite, nachdem eine Anfrage Fathom Lite erfolgreich erreicht hat.

Fehlerübungen für Fathom Lite

Kapazitätstests sollten Page-View-Schreibvorgänge, Datenbankindizes, Aufbewahrung und den Netzwerkpfad von den Browsern der Besucher testen – nicht wiederholte Anfragen an /. Führe das Szenario „eine Website hinzufügen, das Tracking-Skript auf einer Testseite laden, Besuche erzeugen und bestätigen, dass das Dashboard sie ohne Cookies erfasst“ mit realistischer Parallelität aus und dokumentiere Latenz, Fehlerrate und Storage-Wachstum.

Die Upgrade-Planung muss dieses Risiko berücksichtigen: Das Datenbankschema von Fathom und das Tracking-Skript sollten gemeinsam getestet werden, damit keine Events unbemerkt verloren gehen. Teste das neue Release mit repräsentativen Eingaben, wiederhole anschließend die Abnahmetransaktion und vergleiche das Ergebnis. Wenn das Tracking-Skript auf den falschen Hostnamen verweist oder der Datenbankpfad flüchtig ist, erfasse die fehlschlagende Transaktion und untersuche die zuerst betroffene Grenze, statt automatisch den Ingress verantwortlich zu machen.

Nachweisen, dass Fathom Lite einen Austausch übersteht

Ein Container-Image kann erneut heruntergeladen werden; Analytics-Datenbank, Website-Konfiguration und Administratorzustand jedoch nicht. Binde /app vor dem Bootstrap ein, schreibe harmlose Beispieldaten und ersetze den Container, um zu beweisen, dass dieser Pfad tatsächlich persistent ist. Prüfe das tatsächlich aktive Mount, statt einer Compose-Datei zu vertrauen, und stelle sicher, dass der Runtime-User an der von Fathom Lite erwarteten Stelle schreiben kann.

Lege Aufbewahrungsfristen und ein Off-Host-Ziel fest und übe die Wiederherstellung, ohne die Produktion anzutasten. Die Übung ist nur dann erfolgreich, wenn Websites, Benutzer und historische Page Views zurückkehren und nach der Wiederherstellung ein neuer Testbesuch erscheint. Bei datenbankgestütztem Zustand kombinierst du Storage-Snapshots mit anwendungskonsistenten Exporten, wie unter Point-in-Time-Recovery im Vergleich zu Snapshots beschrieben.

Fathom Lite in den Lifecycle von Dockup integrieren

Das One-Click-Deployment von Fathom Lite auf Dockup sollte einen sicheren Austausch ermöglichen: Die Route zeigt weiterhin auf 8080, Secrets sind nicht in das Image eingebrannt und persistente Pfade stehen im neuen Container wieder zur Verfügung. Dasselbe Deployment kann auf Dockup-Compute oder einer angebundenen Maschine ausgeführt werden.

Schließe die anwendungsspezifischen Arbeiten ab, indem du SQLite oder eine unterstützte externe Datenbank sowie die korrekte Einbindung des Client-Site-Skripts verbindest und testest, die kanonische öffentliche Adresse anwendest und diese Abnahmeprüfung ausführst: Füge eine Website hinzu, lade das Tracking-Skript auf einer Testseite, erzeuge Besuche und bestätige, dass das Dashboard sie ohne Cookies erfasst. Ergänze das Ergebnis der Wiederherstellung im Runbook, bevor echte Benutzer eintreffen.

Häufig gestellte Fragen

Was benötigt Fathom Lite für ein produktives Deployment?

Leite den Fathom-Lite-Container auf Port 8080 über eine einzige HTTPS-Origin. Die unterstützende Netzwerkanforderung besteht aus SQLite oder einer unterstützten externen Datenbank sowie der korrekten Einbindung des Client-Site-Skripts. Erkläre Fathom Lite erst dann für einsatzbereit, wenn du eine Website hinzufügen, das Tracking-Skript auf einer Testseite laden, Besuche erzeugen und bestätigen kannst, dass das Dashboard sie ohne Cookies erfasst.

Welche Fathom-Lite-Daten gehören in ein Backup?

Mache /app persistent und nimm Analytics-Datenbank, Website-Konfiguration und Administratorzustand in dasselbe Recovery-Manifest auf. Eine saubere Wiederherstellung von Fathom Lite ist nur dann erfolgreich, wenn Websites, Benutzer und historische Page Views zurückkehren und nach der Wiederherstellung ein neuer Testbesuch erscheint.

Benötigt Fathom Lite hinter einem Reverse Proxy HTTPS?

Verwende HTTPS für die öffentliche Fathom-Lite-Origin und halte Port 8080 auf der internen Route. Setze die Fathom-Lite-Einstellung korrekt: Lege die Serveradresse und den öffentlichen HTTPS-Endpunkt fest, den das Tracking-Skript verwendet. Bei Fathom Lite schützt HTTPS Zugangsdaten oder Benutzerinhalte bei der Übertragung und sorgt für ein konsistentes, originabhängiges Verhalten des Clients.

Wie sollte ein Fathom-Lite-Upgrade getestet werden?

Stelle den aktuellen Fathom-Lite-Zustand in einem isolierten Deployment wieder her, wende die geplante Version an und wiederhole die Abnahmetransaktion. Gehe dabei besonders sorgfältig vor, weil das Datenbankschema von Fathom und das Tracking-Skript gemeinsam getestet werden sollten, damit keine Events unbemerkt verloren gehen. Behalte das bisherige Fathom-Lite-Image, bis die Grenzen für Datenmigration und Rollback verstanden sind.