Fathom Lite zelf hosten in 2026: tracking script, SQLite en privacy
Een praktische handleiding voor het zelf hosten van Fathom Lite, met aandacht voor Docker, poorten, persistente data, TLS, beveiliging, back-ups en problemen die productiegebruik in de weg staan.
Er zijn twee versies van “Fathom Lite draaien”: er bestaat een container, of de service voert zijn echte taak uit. Alleen het tweede is relevant. Het bewijs bestaat hieruit dat je een site toevoegt, het tracking script op een testpagina laadt, bezoeken genereert en bevestigt dat het dashboard deze zonder cookies registreert.
Fathom Lite is hiervoor bedoeld: cookievrije, zelf gehoste pageview-analyse. De deployment moet de onderdelen achter dit gedrag intact houden; een poort, een volume en een certificaat zijn invoer, niet het resultaat.
Inloggegevens, rollen en blootgestelde oppervlakken
Bij Fathom Lite is het waardevolle oppervlak niet noodzakelijk de landingspagina. De grootste fout is het hergebruiken van een voorbeeldsecret of het blootstellen van de admin-login zonder TLS. Ga dit bewust tegen: bescherm de analytics-login, houd het applicatiesecret stabiel en publiceer het script alleen vanaf de verwachte HTTPS-host.
Behandel FATHOM_SECRET volgens de rol ervan in Fathom Lite: houd gevoelige waarden uit Git, documenteer de gevolgen van rotatie en vervang een publiek voorbeeld nooit in productie. Gebruik een containergebruiker zonder verhoogde rechten wanneer de image dit ondersteunt en mount geen niet-gerelateerde inloggegevens. Pas bij de ingress limieten voor rate of omvang toe wanneer onbetrouwbare acties de schrijfsnelheid van pageviews, database-indexen, retentie en het netwerkpad vanaf browsers van bezoekers kunnen belasten.
Scheid Fathom Lite van zijn dependencies
De kleinste verantwoordelijke Fathom Lite-topologie bevat één private listener op 8080, een ingress-route en een gedocumenteerde state-grens. Het netwerkcontract voor Fathom Lite bestaat uit SQLite of een ondersteunde externe database en een correcte plaatsing van het script op de clientsite. Houd private endpoints op interne DNS, sta alleen vereiste uitgaande verbindingen toe en geef Fathom Lite een servicecredential met beperkte scope.
Valideer de topologie door een schone client een site te laten toevoegen, het tracking script op een testpagina te laten laden, bezoeken te laten genereren en te bevestigen dat het dashboard deze zonder cookies registreert. Houd tijdens het uitvoeren de schrijfsnelheid van pageviews, database-indexen, retentie en het netwerkpad vanaf browsers van bezoekers in de gaten. Het resultaat vertelt je of de volgende verbetering thuishoort in geheugen, storage, networking of een afzonderlijke worker, in plaats van willekeurige containergrootten aan te moedigen.
Een Docker-baseline voor Fathom Lite
Een minimaal commando is nuttig wanneer het laat zien wat het platform later zal beheren.
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 blijft poort 8080 private op de host en is elk vereist pad expliciet. Voeg de gecontroleerde connection settings voor SQLite of een ondersteunde externe database en de correcte plaatsing van het script op de clientsite toe; gebruik private namen voor private services. Controleer het opstarten met zowel logs als het applicatiespecifieke bewijs: voeg een site toe, laad het tracking script op een testpagina, genereer bezoeken en bevestig dat het dashboard deze zonder cookies registreert. Zodra dit is geverifieerd, pin je de imageversie zodat een routinevervanging het gedrag niet stilletjes verandert.
Bewijs de Fathom Lite-deployment end-to-end
Maak een kleine, tijdelijke Fathom Lite-fixture en behoud deze voor elke release. De fixture moet de echte workflow doorlopen: voeg een site toe, laad het tracking script op een testpagina, genereer bezoeken en bevestig dat het dashboard deze zonder cookies registreert. Leg de image digest, externe hostname, het dependency-adres en het verwachte resultaat vast, zodat een latere operator de test kan herhalen zonder deze handleiding te hoeven interpreteren.
Voer de fixture drie keer uit. Gebruik eerst de verse deployment. Vervang daarna de container zonder de duurzame state aan te raken. Herstel ten slotte de back-up in een lege omgeving. De derde run slaagt alleen wanneer sites, gebruikers en historische pageviews terugkeren en na het herstel een nieuw testbezoek verschijnt. Leg tijdens elke run latency en resourcegebruik vast rond de schrijfsnelheid van pageviews, database-indexen, retentie en het netwerkpad vanaf browsers van bezoekers; dit wordt de baseline voor alerts in plaats van een willekeurig CPU-percentage.
Test ten slotte bewust het negatieve pad: ontzeg de testidentiteit tijdelijk de toegang tot SQLite of een ondersteunde externe database en de correcte plaatsing van het script op de clientsite. Bevestig dat Fathom Lite zichtbaar faalt zonder de state te beschadigen, herstel de juiste toestand en herhaal de geslaagde transactie. Een releaserecord met die vier uitkomsten levert sterker bewijs dan screenshots van een dashboard of een eenmalige curl-respons.
Houd interne en externe URL's uit elkaar
De publieke grens voor Fathom Lite moet bestaan uit één canonieke hostname, automatische TLS en één intern doel op 8080. Stel het serveradres en het publieke HTTPS-endpoint in dat door het tracking script wordt gebruikt, zodat clients terugkeren naar een adres dat de service herkent.
Als de acceptatietransactie mislukt, classificeer dan de eerste fout. Problemen met DNS, certificaten en 502 horen thuis in de TLS-validatiechecklist. De toestand “het tracking script verwijst naar de verkeerde hostname of het databasepad is ephemeral” hoort aan de applicatiekant thuis nadat een request Fathom Lite succesvol heeft bereikt.
Failure drills voor Fathom Lite
Capacity-tests moeten de schrijfsnelheid van pageviews, database-indexen, retentie en het netwerkpad vanaf browsers van bezoekers testen, niet een herhaald request naar /. Voer het scenario “voeg een site toe, laad het tracking script op een testpagina, genereer bezoeken en bevestig dat het dashboard deze zonder cookies registreert” uit met realistische concurrency en leg latency, error rate en storagegroei vast.
Bij het plannen van upgrades moet je met dit risico rekening houden: het databaseschema van Fathom en het tracking script moeten samen worden getest om te voorkomen dat events stilletjes verloren gaan. Test de nieuwe release met representatieve input, herhaal daarna de acceptatietransactie en vergelijk het resultaat. Als het tracking script naar de verkeerde hostname verwijst of het databasepad ephemeral is, leg dan de mislukte transactie vast en onderzoek de eerste betrokken grens in plaats van aan te nemen dat ingress verantwoordelijk is.
Bewijs dat Fathom Lite vervanging overleeft
Een containerimage kan opnieuw worden gedownload; de analytics-database, siteconfiguratie en administratorstate niet. Mount /app vóór de bootstrap, schrijf onschadelijke voorbeelddata en vervang de container om te bewijzen dat dit pad daadwerkelijk persistent is. Controleer de effectieve mount in plaats van op een Compose-bestandsnaam te vertrouwen, en controleer of de runtimegebruiker kan schrijven op de locatie die Fathom Lite verwacht.
Kies een retentieperiode en een bestemming buiten de host en oefen het herstel zonder productie aan te raken. De drill slaagt alleen wanneer sites, gebruikers en historische pageviews terugkeren en na het herstel een nieuw testbezoek verschijnt. Koppel voor state in databases storage-snapshots aan application-consistente exports, zoals beschreven in point-in-time recovery versus snapshots.
Koppel Fathom Lite aan de lifecycle van Dockup
De one-click Fathom Lite-deployment van Dockup moet vervanging veilig maken: de route blijft naar 8080 wijzen, secrets worden niet in de image ingebakken en persistente paden keren terug in de nieuwe container. Dezelfde deployment kan op Dockup compute of op een gekoppelde machine draaien.
Rond het applicatiespecifieke werk af door SQLite of een ondersteunde externe database en de correcte plaatsing van het script op de clientsite te verbinden en te testen, het canonieke publieke adres toe te passen en deze acceptatiecheck uit te voeren: voeg een site toe, laad het tracking script op een testpagina, genereer bezoeken en bevestig dat het dashboard deze zonder cookies registreert. Voeg het herstelresultaat aan het runbook toe voordat echte gebruikers arriveren.
Veelgestelde vragen
Wat heeft Fathom Lite nodig voor een deployment in productie?
Routeer de Fathom Lite-container op poort 8080 via één HTTPS-origin. De ondersteunende netwerkvereiste bestaat uit SQLite of een ondersteunde externe database en een correcte plaatsing van het script op de clientsite. Noem Fathom Lite pas gereed wanneer je een site kunt toevoegen, het tracking script op een testpagina kunt laden, bezoeken kunt genereren en kunt bevestigen dat het dashboard deze zonder cookies registreert.
Welke Fathom Lite-data hoort in een back-up?
Maak /app persistent en neem de analytics-database, siteconfiguratie en administratorstate op in hetzelfde recovery manifest. Een schoon Fathom Lite-herstel slaagt alleen wanneer sites, gebruikers en historische pageviews terugkeren en na het herstel een nieuw testbezoek verschijnt.
Heeft Fathom Lite HTTPS nodig achter een reverse proxy?
Gebruik HTTPS voor de publieke Fathom Lite-origin en houd poort 8080 op de interne route. Pas de Fathom Lite-instelling correct toe: stel het serveradres en het publieke HTTPS-endpoint in dat door het tracking script wordt gebruikt. Voor Fathom Lite beschermt HTTPS inloggegevens of gebruikerscontent tijdens transport en blijft origingevoelig clientgedrag consistent.
Hoe moet een Fathom Lite-upgrade worden getest?
Herstel de huidige Fathom Lite-state in een geïsoleerde deployment, pas de kandidaatversie toe en herhaal de acceptatietransactie. Let hier extra op, omdat het databaseschema van Fathom en het tracking script samen moeten worden getest om te voorkomen dat events stilletjes verloren gaan. Bewaar de vorige Fathom Lite-image totdat de grenzen van datamigratie en rollback duidelijk zijn.
