Как да хоствате самостоятелно Fathom Lite през 2026 г.: tracking script, SQLite и поверителност

Има две версии на „стартиране на Fathom Lite“: съществува контейнер или услугата изпълнява реалната си задача. Важна е само втората. Тук доказателството е да добавите сайт, да заредите tracking script на тестова страница, да генерирате посещения и да потвърдите, че dashboard-ът ги записва без cookies.

Fathom Lite служи именно за това: cookie-free, self-hosted analytics за преглеждания на страници. Deployment-ът трябва да запази компонентите зад това поведение; порт, volume и сертификат са входни данни, а не крайният резултат.

Credentials, роли и изложени повърхности

При Fathom Lite ценната повърхност не е непременно landing page-ът. Основната грешка е да използвате повторно примерен secret или да изложите admin login-а без TLS. Противодействайте умишлено: защитете analytics login-а, запазете application secret-а стабилен и публикувайте script-а само от очаквания HTTPS host.

Третирайте FATHOM_SECRET според ролята му във Fathom Lite: пазете чувствителните стойности извън Git, документирайте ефектите от rotation и никога не заменяйте публичен пример с production стойност. Използвайте непривилегирован container user, когато image-ът го поддържа, и не mount-вайте несвързани credentials. Прилагайте rate или size limits на ingress ниво, където непроверена работа може да изразходва page-view write rate, database indexes, retention и network path-а от браузърите на посетителите.

Разделете Fathom Lite от dependencies

Най-малката отговорна топология на Fathom Lite съдържа един private listener на 8080, ingress route и документирана state boundary. Network contract-ът за Fathom Lite е SQLite или поддържана external database и правилно поставяне на client-site script-а. Дръжте private endpoints във вътрешен DNS, разрешавайте само необходимите outbound calls и предоставете на Fathom Lite service credential с ограничен обхват.

Потвърдете топологията, като помолите чист client да добави сайт, да зареди tracking script на тестова страница, да генерира посещения и да потвърди, че dashboard-ът ги записва без cookies. Наблюдавайте page-view write rate, database indexes, retention и network path-а от браузърите на посетителите, докато системата работи. Резултатът показва дали следващото подобрение трябва да бъде в memory, storage, networking или в отделен worker, вместо да насърчава произволно оразмеряване на контейнера.

Docker baseline за Fathom Lite

Минималната команда е полезна, когато показва какво по-късно ще управлява платформата.

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

Тук порт 8080 остава private за host-а, а всеки необходим path е зададен изрично. Добавете прегледаните connection settings за SQLite или поддържана external database и правилното поставяне на client-site script-а; използвайте private names за private services. Проверете startup-а както чрез logs, така и с application-specific proof: добавете сайт, заредете tracking script на тестова страница, генерирайте посещения и потвърдете, че dashboard-ът ги записва без cookies. След като потвърдите, фиксирайте image версията, за да не промени routine replacement поведението незабелязано.

Докажете deployment-а на Fathom Lite от край до край

Създайте малък, disposable Fathom Lite fixture и го запазете за всеки release. Fixture-ът трябва да упражнява реалния workflow: добавяне на сайт, зареждане на tracking script на тестова страница, генериране на посещения и потвърждение, че dashboard-ът ги записва без cookies. Запишете image digest-а, external hostname-а, dependency address-а и очаквания резултат, за да може по-късен operator да повтори теста, без да интерпретира това ръководство.

Стартирайте fixture-а три пъти. Първо използвайте новия deployment. След това заменете контейнера, без да променяте durable state. Накрая възстановете backup-а в празна среда. Третото изпълнение е успешно само когато сайтовете, потребителите и историческите page views се върнат и след recovery се появи ново тестово посещение. По време на всяко изпълнение измервайте latency и resource use около page-view write rate, database indexes, retention и network path-а от браузърите на посетителите; това става baseline за alerts, вместо произволен CPU процент.

Накрая тествайте умишлено negative path-а: временно откажете на test identity достъп до SQLite или поддържана external database и правилното поставяне на client-site script-а. Потвърдете, че Fathom Lite се проваля видимо, без да поврежда state-а, възстановете правилното условие и повторете успешната transaction. Release record с тези четири резултата е по-силно доказателство от screenshots на dashboard или еднократен curl response.

Поддържайте вътрешните и външните URL адреси отделно

Public boundary-то за Fathom Lite трябва да бъде един canonical hostname, automatic TLS и една internal target на 8080. Задайте server address-а и public HTTPS endpoint-а, използван от tracking script-а, така че clients да се връщат към address, който услугата разпознава.

Ако acceptance transaction се провали, класифицирайте първата грешка. DNS, certificate и 502 проблемите принадлежат към TLS validation checklist. Условието „tracking script-ът сочи към грешен hostname или database path-ът е ephemeral“ принадлежи към application side, след като заявката успешно е достигнала Fathom Lite.

Failure drills за Fathom Lite

Capacity тестовете трябва да упражняват page-view write rate, database indexes, retention и network path-а от браузърите на посетителите, а не повтаряща се заявка към /. Стартирайте сценария „добавете сайт, заредете tracking script на тестова страница, генерирайте посещения и потвърдете, че dashboard-ът ги записва без cookies“ при реалистична concurrency и записвайте latency, error rate и storage growth.

Планирането на upgrade трябва да отчита този риск: database schema-ата на Fathom и tracking script-ът трябва да се тестват заедно, за да се избегне незабелязана загуба на events. Тествайте новия release с representative input, след което повторете acceptance transaction и сравнете резултата. Ако tracking script-ът сочи към грешен hostname или database path-ът е ephemeral, запишете failing transaction и проверете първата засегната boundary, вместо да приемате, че ingress е отговорен.

Докажете, че Fathom Lite преживява replacement

Container image може да бъде изтеглен отново; analytics database, site configuration и administrator state не могат. Mount-нете /app преди bootstrap, запишете безвредни примерни данни и заменете контейнера, за да докажете, че path-ът действително е persistent. Проверете effective mount-а, вместо да разчитате на име на Compose файл, и се уверете, че runtime user-ът може да записва там, където Fathom Lite очаква.

Изберете retention и off-host destination, след което репетирайте recovery, без да докосвате production. Drill-ът е успешен само когато сайтовете, потребителите и историческите page views се върнат и след recovery се появи ново тестово посещение. За database-backed state комбинирайте storage snapshots с application-consistent exports, както е описано в point-in-time recovery versus snapshots.

Свържете Fathom Lite с lifecycle-а на Dockup

One-click deployment-ът на Fathom Lite в Dockup трябва да прави replacement-а безопасен: route-ът продължава да сочи към 8080, secrets не са вградени в image-а, а persistent paths се възстановяват в новия контейнер. Същият deployment може да работи върху Dockup compute или върху свързана машина.

Завършете app-specific работата, като свържете и тествате SQLite или поддържана external database и правилното поставяне на client-site script-а, приложите canonical public address и изпълните тази acceptance проверка: добавете сайт, заредете tracking script на тестова страница, генерирайте посещения и потвърдете, че dashboard-ът ги записва без cookies. Добавете резултата от restore-а към runbook-а, преди да пристигнат реални потребители.

Често задавани въпроси

Какво е необходимо на Fathom Lite за production deployment?

Насочете Fathom Lite container-а през порт 8080 към един HTTPS origin. Поддържащото network изискване е SQLite или поддържана external database и правилно поставяне на client-site script-а. Не считайте Fathom Lite за готов, докато не можете да добавите сайт, да заредите tracking script на тестова страница, да генерирате посещения и да потвърдите, че dashboard-ът ги записва без cookies.

Кои данни на Fathom Lite трябва да бъдат включени в backup?

Persist-нете /app и включете analytics database, site configuration и administrator state в един и същ recovery manifest. Чистият Fathom Lite restore е успешен само когато сайтовете, потребителите и историческите page views се върнат и след recovery се появи ново тестово посещение.

Необходим ли е HTTPS за Fathom Lite зад reverse proxy?

Използвайте HTTPS за public Fathom Lite origin-а и запазете порт 8080 във вътрешния route. Приложете правилно Fathom Lite setting-а: задайте server address-а и public HTTPS endpoint-а, използван от tracking script-а. При Fathom Lite HTTPS защитава credentials или user content при пренос и поддържа последователно client behavior, зависимо от origin-а.

Как трябва да се тества upgrade на Fathom Lite?

Възстановете текущия Fathom Lite state в изолиран deployment, приложете candidate version-а и повторете acceptance transaction. Обърнете особено внимание, защото database schema-ата на Fathom и tracking script-ът трябва да се тестват заедно, за да се избегне незабелязана загуба на events. Запазете предишния Fathom Lite image, докато не изясните границите на data migration-а и rollback-а.