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

Есть две версии «запустить Fathom Lite»: контейнер существует или сервис действительно выполняет свою работу. Важна только вторая. Проверка здесь проста: добавить сайт, загрузить tracking script на тестовую страницу, сгенерировать посещения и убедиться, что dashboard фиксирует их без cookies.

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

Учётные данные, роли и открытые поверхности

В случае Fathom Lite ценной поверхностью не обязательно является landing page. Главная ошибка — повторно использовать примерный secret или открыть admin login без TLS. Предотвратите это намеренно: защитите доступ к аналитике, сохраняйте application secret неизменным и публикуйте script только с ожидаемого HTTPS-хоста.

Обращайтесь с FATHOM_SECRET с учётом его роли в Fathom Lite: храните чувствительные значения вне Git, документируйте последствия ротации и никогда не подставляйте публичный пример в production. Используйте непривилегированного пользователя контейнера, если image это поддерживает, и не монтируйте посторонние credentials. Настройте ограничения rate или size на ingress, где недоверенная нагрузка может потреблять ресурсы записи просмотров страниц, database indexes, retention и сетевого пути от браузеров посетителей.

Отделите Fathom Lite от его зависимостей

Минимальная ответственная topology Fathom Lite включает один private listener на 8080, ingress route и документированную границу состояния. Network contract Fathom Lite — это SQLite или поддерживаемая external database и корректное размещение client-site script. Оставляйте private endpoints во внутреннем DNS, разрешайте только необходимые исходящие подключения и предоставляйте Fathom Lite service credential с ограниченными правами.

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

Базовая конфигурация Fathom Lite в Docker

Минимальная команда полезна, когда она показывает, чем платформа будет управлять впоследствии.

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, а каждый необходимый path указан явно. Добавьте проверенные connection settings для SQLite или поддерживаемой external database и корректного размещения client-site script; для private services используйте private names. Проверьте запуск по logs и с помощью application-specific проверки: добавьте сайт, загрузите tracking script на тестовую страницу, сгенерируйте посещения и убедитесь, что dashboard фиксирует их без cookies. После проверки зафиксируйте version image, чтобы обычная замена не изменила поведение незаметно.

Проверьте deployment Fathom Lite от начала до конца

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

Запустите fixture три раза. Сначала используйте fresh deployment. Затем замените container, не затрагивая durable state. После этого восстановите backup в пустом environment. Третий запуск считается успешным только тогда, когда sites, users и historical page views восстановились, а после recovery появилось новое тестовое посещение. Во время каждого запуска фиксируйте latency и resource use для rate записи просмотров страниц, database indexes, retention и сетевого пути от браузеров посетителей; это станет базой для alerts вместо произвольного процента CPU.

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

Не путайте внутренние и внешние URL

Public boundary Fathom Lite должна состоять из одного canonical hostname, automatic TLS и одного internal target на 8080. Настройте server address и public 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 должны проверять rate записи просмотров страниц, database indexes, retention и сетевой путь от браузеров посетителей, а не повторяющийся request к /. Запустите сценарий «добавить сайт, загрузить tracking script на тестовую страницу, сгенерировать посещения и убедиться, что dashboard фиксирует их без cookies» при realistic concurrency и зафиксируйте latency, error rate и storage growth.

При планировании upgrade необходимо учитывать этот риск: database schema и tracking script Fathom следует тестировать вместе, чтобы избежать незаметной потери events. Протестируйте новый release на representative input, затем повторите acceptance transaction и сравните результат. Если tracking script указывает на неправильный hostname или database path является ephemeral, сохраните failing transaction и изучите первую задействованную boundary вместо того, чтобы считать ingress ответственным.

Убедитесь, что Fathom Lite переживает замену

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

Определите retention и off-host destination, затем отрепетируйте recovery, не затрагивая production. Проверка считается успешной только тогда, когда sites, users и historical page views восстановились, а после recovery появилось новое тестовое посещение. Для database-backed state сочетайте storage snapshots с application-consistent exports, как описано в материале point-in-time recovery и snapshots.

Подключите Fathom Lite к lifecycle Dockup

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

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

Часто задаваемые вопросы

Что нужно Fathom Lite для production deployment?

Направьте container Fathom Lite через один HTTPS origin на порт 8080. Supporting network requirement — это SQLite или поддерживаемая external database и корректное размещение client-site script. Не считайте Fathom Lite готовым, пока не сможете добавить сайт, загрузить tracking script на тестовую страницу, сгенерировать посещения и убедиться, что dashboard фиксирует их без cookies.

Какие данные Fathom Lite нужно включить в backup?

Сохраняйте /app и включайте analytics database, site configuration и administrator state в один recovery manifest. Чистое восстановление Fathom Lite считается успешным только тогда, когда sites, users и historical page views восстановились, а после recovery появилось новое тестовое посещение.

Требуется ли Fathom Lite HTTPS за reverse proxy?

Используйте HTTPS для public origin Fathom Lite, а порт 8080 оставляйте во внутреннем route. Корректно примените setting Fathom Lite: задайте server address и public HTTPS endpoint, который использует tracking script. Для Fathom Lite HTTPS защищает credentials или user content при передаче и обеспечивает согласованное client behavior, зависящее от origin.

Как тестировать upgrade Fathom Lite?

Восстановите текущее state Fathom Lite в isolated deployment, примените candidate version и повторите его acceptance transaction. Уделите этому особое внимание: database schema и tracking script Fathom следует тестировать вместе, чтобы избежать незаметной потери events. Сохраняйте предыдущий image Fathom Lite, пока не будут понятны границы data migration и rollback.