Sådan hoster du selv Fathom Lite i 2026: Tracking-script, SQLite og privatliv

Der er to versioner af at “køre Fathom Lite”: Enten findes der en container, eller også udfører servicen faktisk sit arbejde. Det er kun den sidste, der betyder noget. Her er beviset at tilføje et site, indlæse tracking-scriptet på en testside, generere besøg og bekræfte, at dashboardet registrerer dem uden cookies.

Fathom Lite er beregnet til dette formål: cookie-fri, self-hosted page-view analytics. Deploymentet skal bevare de dele, der ligger bag denne funktionalitet; en port, et volume og et certifikat er input, ikke resultatet.

Credentials, roller og eksponerede overflader

For Fathom Lite er den værdifulde overflade ikke nødvendigvis landing page. Den mest almindelige fejl er at genbruge en eksempel-secret eller eksponere admin-login uden TLS. Modvirk det bevidst: Beskyt analytics-login, hold application secret stabilt, og publicér kun scriptet fra den forventede HTTPS-host.

Behandl FATHOM_SECRET i overensstemmelse med dets rolle i Fathom Lite: Hold sensitive værdier ude af Git, dokumentér konsekvenserne af rotation, og brug aldrig et offentligt eksempel i produktion. Brug en container-bruger uden privilegier, når imaget understøtter det, og mount ingen uvedkommende credentials. Anvend rate- eller størrelsesbegrænsninger ved ingress, hvor ikke-betroet arbejde kan forbruge page-view write rate, databaseindekser, retention og netværksstien fra besøgendes browsere.

Adskil Fathom Lite fra dets dependencies

Den mindste ansvarlige Fathom Lite-topologi indeholder én privat listener på 8080, en ingress-route og en dokumenteret state boundary. Netværkskontrakten for Fathom Lite er SQLite eller en understøttet ekstern database samt korrekt placering af client-site-scriptet. Hold private endpoints på intern DNS, tillad kun nødvendige outbound-kald, og giv Fathom Lite en afgrænset service credential.

Validér topologien ved at bede en ren klient om at tilføje et site, indlæse tracking-scriptet på en testside, generere besøg og bekræfte, at dashboardet registrerer dem uden cookies. Overvåg page-view write rate, databaseindekser, retention og netværksstien fra besøgendes browsere, mens det kører. Resultatet fortæller dig, om den næste forbedring hører hjemme i memory, storage, networking eller en separat worker, i stedet for at opfordre til vilkårlig dimensionering af containere.

Et Docker-baseline for Fathom Lite

En minimal kommando er nyttig, når den viser, hvad platformen senere kommer til at administrere.

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

Her forbliver port 8080 privat på hosten, og alle nødvendige paths er eksplicitte. Tilføj de gennemgåede connection settings for SQLite eller en understøttet ekstern database samt korrekt placering af client-site-scriptet; brug private navne til private services. Bekræft startup med både logs og det applikationsspecifikke bevis: Tilføj et site, indlæs tracking-scriptet på en testside, generér besøg, og bekræft, at dashboardet registrerer dem uden cookies. Når det er verificeret, skal du låse image-versionen, så en rutinemæssig udskiftning ikke ændrer adfærden ubemærket.

Bevis Fathom Lite-deploymentet end to end

Opret en lille, midlertidig Fathom Lite-fixture, og behold den til hver release. Fixturen skal teste det rigtige workflow: Tilføj et site, indlæs tracking-scriptet på en testside, generér besøg, og bekræft, at dashboardet registrerer dem uden cookies. Registrér image digest, ekstern hostname, dependency-adresse og det forventede resultat, så en senere operator kan gentage testen uden at skulle fortolke denne guide.

Kør fixturen tre gange. Først med det friske deployment. Derefter ved at udskifte containeren uden at røre durable state. Til sidst ved at restore backuppet til et tomt miljø. Den tredje kørsel består kun, når sites, brugere og historiske page views kommer tilbage, og et nyt testbesøg vises efter recovery. Under hver kørsel skal du indsamle latency og resource use omkring page-view write rate, databaseindekser, retention og netværksstien fra besøgendes browsere; det bliver baseline for alerts i stedet for en vilkårlig CPU-procent.

Test til sidst den negative sti bevidst: Nægt midlertidigt testidentiteten adgang til SQLite eller en understøttet ekstern database og korrekt placering af client-site-scriptet. Bekræft, at Fathom Lite fejler synligt uden at korrumpere state, genskab den korrekte tilstand, og gentag den vellykkede transaktion. En release-record med de fire resultater er stærkere dokumentation end screenshots af et dashboard eller et engangs-svar fra curl.

Hold interne og eksterne URLs adskilt

Den offentlige grænse for Fathom Lite bør være ét canonical hostname, automatisk TLS og ét internt target på 8080. Indstil server address og det offentlige HTTPS-endpoint, som tracking-scriptet bruger, så klienterne vender tilbage til en adresse, servicen genkender.

Hvis acceptance-transaktionen fejler, skal du klassificere den første fejl. DNS-, certifikat- og 502-problemer hører hjemme i TLS-validationstjeklisten. Betingelsen “tracking-scriptet peger på det forkerte hostname, eller database-pathen er ephemeral” hører til på applikationssiden, efter at en request er nået frem til Fathom Lite.

Failure drills for Fathom Lite

Kapacitetstests skal teste page-view write rate, databaseindekser, retention og netværksstien fra besøgendes browsere – ikke en gentagen request til /. Kør scenariet “tilføj et site, indlæs tracking-scriptet på en testside, generér besøg, og bekræft, at dashboardet registrerer dem uden cookies” med realistisk concurrency, og registrér latency, error rate og storage growth.

Upgrade-planlægningen skal tage højde for denne risiko: Fathoms database schema og tracking-script skal testes sammen for at undgå, at events går tabt ubemærket. Test den nye release med repræsentativt input, gentag derefter acceptance-transaktionen, og sammenlign resultatet. Hvis tracking-scriptet peger på det forkerte hostname, eller database-pathen er ephemeral, skal du gemme den fejlslagne transaktion og undersøge den første involverede boundary i stedet for at antage, at ingress er ansvarlig.

Bevis, at Fathom Lite overlever en udskiftning

Et container-image kan downloades igen; analytics-database, site-konfiguration og administrator-state kan ikke. Mount /app før bootstrap, skriv harmløse sample-data, og udskift containeren for at bevise, at pathen faktisk er persistent. Kontrollér det effektive mount i stedet for at stole på et Compose-filnavn, og tjek, at runtime-brugeren kan skrive dér, hvor Fathom Lite forventer det.

Vælg retention og en destination uden for hosten, og øv recovery uden at røre produktionen. Drillet består kun, når sites, brugere og historiske page views kommer tilbage, og et nyt testbesøg vises efter recovery. For databasebaseret state skal storage snapshots kombineres med application-consistent exports som beskrevet i point-in-time recovery versus snapshots.

Knyt Fathom Lite til Dockups lifecycle

Dockups one-click Fathom Lite-deployment skal gøre udskiftning sikker: Routen fortsætter med at pege på 8080, secrets er ikke baked ind i imaget, og persistente paths kommer tilbage i den nye container. Det samme deployment kan køre på Dockup compute eller en tilknyttet maskine.

Afslut det appspecifikke arbejde ved at forbinde og teste SQLite eller en understøttet ekstern database samt korrekt placering af client-site-scriptet, anvende den canonical offentlige adresse og køre dette acceptance-tjek: Tilføj et site, indlæs tracking-scriptet på en testside, generér besøg, og bekræft, at dashboardet registrerer dem uden cookies. Tilføj restore-resultatet til runbooken, før de rigtige brugere ankommer.

Ofte stillede spørgsmål

Hvad kræver Fathom Lite til et production-deployment?

Route Fathom Lite-containeren på port 8080 gennem én HTTPS-origin. Det understøttende netværkskrav er SQLite eller en understøttet ekstern database samt korrekt placering af client-site-scriptet. Betragt ikke Fathom Lite som klar, før du kan tilføje et site, indlæse tracking-scriptet på en testside, generere besøg og bekræfte, at dashboardet registrerer dem uden cookies.

Hvilke Fathom Lite-data skal med i et backup?

Persistér /app, og medtag analytics-database, site-konfiguration og administrator-state i det samme recovery-manifest. En ren Fathom Lite-restore består kun, når sites, brugere og historiske page views kommer tilbage, og et nyt testbesøg vises efter recovery.

Kræver Fathom Lite HTTPS bag en reverse proxy?

Brug HTTPS til den offentlige Fathom Lite-origin, og behold port 8080 på den interne route. Anvend Fathom Lite-indstillingen korrekt: Indstil server address og det offentlige HTTPS-endpoint, som tracking-scriptet bruger. For Fathom Lite beskytter HTTPS credentials eller brugerindhold under transport og sikrer ensartet origin-følsom klientadfærd.

Hvordan skal en Fathom Lite-upgrade testes?

Restore den aktuelle Fathom Lite-state til et isoleret deployment, anvend kandidatversionen, og gentag dens acceptance-transaktion. Vær særligt opmærksom, fordi Fathoms database schema og tracking-script skal testes sammen for at undgå, at events går tabt ubemærket. Behold det tidligere Fathom Lite-image, indtil dets data-migration og rollback-boundary er forstået.