Як розгорнути Fathom Lite самостійно у 2026 році: tracking script, SQLite та приватність

Є дві версії «запустити Fathom Lite»: існує контейнер або сервіс виконує свою реальну роботу. Важлива лише друга. Тут доказом є додавання сайту, завантаження tracking script на тестовій сторінці, генерація відвідувань і підтвердження, що dashboard записує їх без cookies.

Fathom Lite призначений саме для цього: аналітики переглядів сторінок без cookies із self-hosting. Під час deployment потрібно зберегти всі компоненти, що забезпечують таку поведінку; порт, volume і сертифікат — це вхідні параметри, а не результат.

Облікові дані, ролі та відкриті поверхні атаки

Для Fathom Lite цінною є не обов’язково landing page. Основна помилка — повторно використовувати секрет із прикладу або відкривати admin login без TLS. Свідомо уникайте цього: захистіть вхід до аналітики, залишайте application secret незмінним і публікуйте script лише з очікуваного HTTPS-хоста.

Використовуйте FATHOM_SECRET відповідно до його ролі у Fathom Lite: не зберігайте чутливі значення в Git, документуйте наслідки rotation і ніколи не підставляйте публічне значення з прикладу в production. Використовуйте непривілейованого користувача контейнера, якщо image це підтримує, і не монтуйте сторонні credentials. Застосовуйте обмеження швидкості або розміру на ingress там, де ненадійні запити можуть споживати ресурси запису переглядів сторінок, database indexes, retention і мережевого шляху від браузерів відвідувачів.

Відокремте Fathom Lite від його залежностей

Найменша відповідальна topology Fathom Lite містить один приватний listener на 8080, маршрут ingress і задокументовану межу стану. Мережевий контракт Fathom Lite — це SQLite або supported external database і коректне розміщення client-site script. Залишайте приватні endpoints у внутрішньому DNS, дозволяйте лише необхідні outbound calls і надавайте Fathom Lite service credential з обмеженими правами.

Перевірте topology, попросивши чистий client додати сайт, завантажити tracking script на тестовій сторінці, згенерувати відвідування й підтвердити, що dashboard записує їх без cookies. Під час роботи стежте за швидкістю запису переглядів сторінок, database indexes, retention і мережевим шляхом від браузерів відвідувачів. Результат покаже, чи потрібне наступне покращення в memory, storage, networking або окремому worker, замість того щоб заохочувати довільне збільшення розміру контейнера.

Базова конфігурація Docker для 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 залишається приватним для host, а всі необхідні шляхи вказано явно. Додайте перевірені connection settings для SQLite або supported external database і коректне розміщення client-site script; для приватних сервісів використовуйте приватні імена. Перевірте запуск за допомогою logs і application-specific proof: додайте сайт, завантажте tracking script на тестовій сторінці, згенеруйте відвідування й підтвердьте, що dashboard записує їх без cookies. Після перевірки зафіксуйте версію image, щоб звичайна заміна не змінила поведінку непомітно.

Перевірте deployment Fathom Lite від початку до кінця

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

Запустіть fixture тричі. Спочатку використайте свіжий deployment. Потім замініть container, не змінюючи durable state. Нарешті відновіть backup у порожньому environment. Третій запуск є успішним лише тоді, коли сайти, користувачі та історичні перегляди сторінок повертаються, а після recovery з’являється нове тестове відвідування. Під час кожного запуску збирайте дані про latency і використання ресурсів навколо швидкості запису переглядів сторінок, database indexes, retention і мережевого шляху від браузерів відвідувачів; це стане baseline для alerts, а не довільним відсотком CPU.

Зрештою навмисно перевірте negative path: тимчасово забороніть test identity доступ до SQLite або supported external database і коректного розміщення client-site script. Переконайтеся, що Fathom Lite помітно завершується з помилкою, не пошкоджуючи state, відновіть правильну умову й повторіть успішну transaction. Release record із цими чотирма результатами є вагомішим доказом, ніж screenshots dashboard або одноразова відповідь curl.

Розрізняйте внутрішні та зовнішні URL

Публічний boundary Fathom Lite має бути одним canonical hostname, автоматичним TLS і однією внутрішньою target-адресою на 8080. Налаштуйте server address і публічний HTTPS endpoint, який використовує tracking script, щоб clients поверталися на адресу, яку розпізнає сервіс.

Якщо acceptance transaction завершується помилкою, класифікуйте першу помилку. Проблеми з DNS, certificate і 502 належать до чекліста перевірки TLS. Умова «tracking script вказує на неправильний hostname або database path є ephemeral» належить до application side після того, як request успішно досяг Fathom Lite.

Тести відмов для Fathom Lite

Capacity tests мають перевіряти швидкість запису переглядів сторінок, database indexes, retention і мережевий шлях від браузерів відвідувачів, а не повторювані requests до /. Запустіть сценарій «додати сайт, завантажити tracking script на тестовій сторінці, згенерувати відвідування й підтвердити, що dashboard записує їх без cookies» за реалістичної concurrency та зафіксуйте latency, error rate і зростання storage.

Планування upgrade має враховувати цей ризик: database schema Fathom і tracking script потрібно тестувати разом, щоб уникнути непомітної втрати events. Протестуйте новий release на representative input, потім повторіть acceptance transaction і порівняйте результат. Якщо tracking script вказує на неправильний hostname або database path є ephemeral, зафіксуйте transaction із помилкою та перевірте перший задіяний boundary, замість того щоб припускати, що відповідальним є ingress.

Переконайтеся, що Fathom Lite переживає заміну

Container image можна завантажити повторно, а analytics database, site configuration і administrator state — ні. Змонтуйте /app до bootstrap, запишіть нешкідливі sample data і замініть container, щоб довести, що цей path справді persistent. Перевірте фактичний mount, а не покладайтеся на назву Compose-файлу, і переконайтеся, що runtime user може записувати туди, де цього очікує Fathom Lite.

Визначте retention і off-host destination, а потім відрепетируйте recovery, не торкаючись production. Тест успішний лише тоді, коли сайти, користувачі та історичні перегляди сторінок повертаються, а після recovery з’являється нове тестове відвідування. Для state, що зберігається в database, поєднуйте storage snapshots з application-consistent exports, як описано в матеріалі відновлення до певного моменту часу та snapshots.

Додайте Fathom Lite до життєвого циклу Dockup

One-click deployment Fathom Lite у Dockup має робити заміну безпечною: route продовжує спрямовувати на 8080, secrets не вбудовуються в image, а persistent paths відновлюються в новому container. Той самий deployment може працювати на Dockup compute або під’єднаній machine.

Виконайте специфічні для application кроки: під’єднайте й протестуйте SQLite або supported external database і коректне розміщення client-site script, застосуйте canonical public address і запустіть цю acceptance check: додайте сайт, завантажте tracking script на тестовій сторінці, згенеруйте відвідування й підтвердьте, що dashboard записує їх без cookies. Додайте результат restore до runbook до появи реальних користувачів.

Поширені запитання

Що потрібно Fathom Lite для deployment у production?

Спрямуйте container Fathom Lite через порт 8080 до одного HTTPS origin. Необхідна мережева умова — SQLite або supported external database і коректне розміщення client-site script. Не вважайте Fathom Lite готовим, доки не зможете додати сайт, завантажити tracking script на тестовій сторінці, згенерувати відвідування й підтвердити, що dashboard записує їх без cookies.

Які дані Fathom Lite потрібно включити до backup?

Зберігайте /app і включіть analytics database, site configuration та administrator state до того самого recovery manifest. Чистий restore Fathom Lite є успішним лише тоді, коли сайти, користувачі та історичні перегляди сторінок повертаються, а після recovery з’являється нове тестове відвідування.

Чи потрібен Fathom Lite HTTPS за reverse proxy?

Використовуйте HTTPS для публічного Fathom Lite origin і залишайте порт 8080 у внутрішньому route. Правильно застосуйте налаштування Fathom Lite: задайте server address і публічний HTTPS endpoint, який використовує tracking script. Для Fathom Lite HTTPS захищає credentials або user content під час передавання та забезпечує узгоджену client behavior, чутливу до origin.

Як тестувати upgrade Fathom Lite?

Відновіть поточний state Fathom Lite в ізольованому deployment, застосуйте candidate version і повторіть його acceptance transaction. Приділіть цьому особливу увагу, оскільки database schema Fathom і tracking script потрібно тестувати разом, щоб уникнути непомітної втрати events. Зберігайте попередній Fathom Lite image, доки не буде зрозумілою межа data migration і rollback.