Cómo autoalojar Fathom Lite en 2026: script de seguimiento, SQLite y privacidad

Hay dos versiones de «ejecutar Fathom Lite»: existe un contenedor o el servicio completa su función real. Solo importa la segunda. En este caso, la prueba consiste en añadir un sitio, cargar el script de seguimiento en una página de prueba, generar visitas y confirmar que el dashboard las registra sin cookies.

Fathom Lite está pensado para esto: analítica de visitas de página sin cookies y autoalojada. El despliegue debe conservar los componentes que hacen posible ese comportamiento; un puerto, un volumen y un certificado son elementos necesarios, no el resultado.

Credenciales, roles y superficies expuestas

En Fathom Lite, la superficie de valor no es necesariamente la landing page. El error principal es reutilizar un secreto de ejemplo o exponer el acceso de administración sin TLS. Evítalo de forma deliberada: protege el acceso a la analítica, mantén estable el secreto de la aplicación y publica el script únicamente desde el host HTTPS previsto.

Trata FATHOM_SECRET según su función en Fathom Lite: mantén los valores sensibles fuera de Git, documenta los efectos de la rotación y no sustituyas nunca un ejemplo público en producción. Usa un usuario de contenedor sin privilegios cuando la imagen lo permita y no montes credenciales que no estén relacionadas. Aplica límites de rate o de tamaño en el ingress, ya que el trabajo no confiable puede consumir la tasa de escritura de visitas, los índices de la base de datos, la retención y la ruta de red desde los navegadores de los visitantes.

Separa Fathom Lite de sus dependencias

La topología mínima responsable de Fathom Lite contiene un único listener privado en 8080, una ruta de ingress y un límite de estado documentado. El contrato de red de Fathom Lite consiste en SQLite o una base de datos externa compatible, además de la ubicación correcta del script en el sitio cliente. Mantén los endpoints privados en el DNS interno, permite únicamente las llamadas salientes necesarias y asigna a Fathom Lite una credencial de servicio con permisos limitados.

Valida la topología pidiendo a un cliente limpio que añada un sitio, cargue el script de seguimiento en una página de prueba, genere visitas y confirme que el dashboard las registra sin cookies. Mientras se ejecuta, observa la tasa de escritura de visitas, los índices de la base de datos, la retención y la ruta de red desde los navegadores de los visitantes. El resultado te indicará si la siguiente mejora corresponde a la memoria, el almacenamiento, la red o un worker independiente, en lugar de fomentar un dimensionamiento arbitrario del contenedor.

Una base de Docker para Fathom Lite

Un comando mínimo resulta útil cuando muestra lo que la plataforma gestionará más adelante.

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

Aquí, el puerto 8080 permanece privado en el host y todas las rutas necesarias están especificadas explícitamente. Añade la configuración de conexión revisada para SQLite o una base de datos externa compatible, así como la ubicación correcta del script en el sitio cliente; utiliza nombres privados para los servicios privados. Verifica el arranque tanto con los logs como con la prueba específica de la aplicación: añade un sitio, carga el script de seguimiento en una página de prueba, genera visitas y confirma que el dashboard las registra sin cookies. Una vez verificado, fija la versión de la imagen para que una sustitución rutinaria no cambie el comportamiento de forma silenciosa.

Demuestra el funcionamiento integral del despliegue de Fathom Lite

Crea un fixture pequeño y desechable de Fathom Lite y consérvalo para cada release. El fixture debe probar el flujo real: añadir un sitio, cargar el script de seguimiento en una página de prueba, generar visitas y confirmar que el dashboard las registra sin cookies. Registra el digest de la imagen, el hostname externo, la dirección de la dependencia y el resultado esperado para que otro operador pueda repetir la prueba sin tener que interpretar esta guía.

Ejecuta el fixture tres veces. Primero, utiliza el despliegue recién creado. Después, sustituye el contenedor sin tocar el estado duradero. Por último, restaura la copia de seguridad en un entorno vacío. La tercera ejecución solo es válida cuando se recuperan los sitios, los usuarios y las visitas históricas, y aparece una nueva visita de prueba después de la recuperación. En cada ejecución, captura la latencia y el uso de recursos relacionados con la tasa de escritura de visitas, los índices de la base de datos, la retención y la ruta de red desde los navegadores de los visitantes; esto se convertirá en la base de las alertas, en lugar de un porcentaje de CPU arbitrario.

Por último, prueba deliberadamente la ruta negativa: deniega temporalmente a la identidad de prueba el acceso a SQLite o a una base de datos externa compatible, así como la ubicación correcta del script en el sitio cliente. Confirma que Fathom Lite falla de forma visible sin corromper el estado, restaura la condición correcta y repite la transacción satisfactoria. Un registro del release que contenga esos cuatro resultados aporta pruebas más sólidas que las capturas de un dashboard o una respuesta puntual de curl.

Mantén separadas las URL internas y externas

El límite público de Fathom Lite debe ser un único hostname canónico, TLS automático y un único destino interno en 8080. Configura la dirección del servidor y el endpoint HTTPS público que utiliza el script de seguimiento para que los clientes vuelvan a una dirección reconocida por el servicio.

Si la transacción de aceptación falla, clasifica el primer error. Los problemas de DNS, certificados y 502 pertenecen a la lista de comprobación de validación de TLS. La condición «el script de seguimiento apunta al hostname equivocado o la ruta de la base de datos es efímera» pertenece al lado de la aplicación, después de que una solicitud haya llegado correctamente a Fathom Lite.

Pruebas de fallo para Fathom Lite

Las pruebas de capacidad deben ejercitar la tasa de escritura de visitas, los índices de la base de datos, la retención y la ruta de red desde los navegadores de los visitantes, no una solicitud repetida a /. Ejecuta el escenario «añadir un sitio, cargar el script de seguimiento en una página de prueba, generar visitas y confirmar que el dashboard las registra sin cookies» con una concurrencia realista y registra la latencia, la tasa de errores y el crecimiento del almacenamiento.

La planificación de upgrades debe tener en cuenta este riesgo: el esquema de la base de datos de Fathom y el script de seguimiento deben probarse conjuntamente para evitar perder eventos de forma silenciosa. Prueba el nuevo release con datos representativos, repite después la transacción de aceptación y compara el resultado. Si el script de seguimiento apunta al hostname equivocado o la ruta de la base de datos es efímera, captura la transacción fallida e inspecciona el primer límite implicado, en lugar de asumir que el ingress es el responsable.

Demuestra que Fathom Lite sobrevive a una sustitución

Una imagen de contenedor se puede descargar de nuevo; la base de datos de analítica, la configuración de los sitios y el estado del administrador no. Monta /app antes del bootstrap, escribe datos de muestra inocuos y sustituye el contenedor para demostrar que esa ruta es realmente persistente. Inspecciona el mount efectivo en lugar de confiar en el nombre de un archivo de Compose y comprueba que el usuario del runtime puede escribir donde Fathom Lite lo necesita.

Elige una política de retención y un destino externo al host, y ensaya la recuperación sin tocar producción. La prueba solo es válida cuando se recuperan los sitios, los usuarios y las visitas históricas, y aparece una nueva visita de prueba después de la recuperación. Para el estado respaldado por una base de datos, combina snapshots del almacenamiento con exports coherentes con la aplicación, tal como se describe en recuperación point-in-time frente a snapshots.

Integra Fathom Lite en el ciclo de vida de Dockup

El despliegue de Fathom Lite con un clic de Dockup debe hacer que las sustituciones sean seguras: la ruta debe seguir apuntando a 8080, los secretos no deben estar incluidos en la imagen y las rutas persistentes deben recuperarse en el nuevo contenedor. El mismo despliegue puede ejecutarse en el compute de Dockup o en una máquina conectada.

Completa el trabajo específico de la aplicación conectando y probando SQLite o una base de datos externa compatible, así como la ubicación correcta del script en el sitio cliente; aplica la dirección pública canónica y ejecuta esta comprobación de aceptación: añade un sitio, carga el script de seguimiento en una página de prueba, genera visitas y confirma que el dashboard las registra sin cookies. Añade el resultado de la restauración al runbook antes de que lleguen usuarios reales.

Preguntas frecuentes

¿Qué necesita Fathom Lite para un despliegue de producción?

Enruta el contenedor de Fathom Lite en el puerto 8080 a través de un único origen HTTPS. El requisito de red complementario es SQLite o una base de datos externa compatible, además de la ubicación correcta del script en el sitio cliente. No consideres que Fathom Lite está listo hasta que puedas añadir un sitio, cargar el script de seguimiento en una página de prueba, generar visitas y confirmar que el dashboard las registra sin cookies.

¿Qué datos de Fathom Lite deben incluirse en una copia de seguridad?

Persiste /app e incluye la base de datos de analítica, la configuración de los sitios y el estado del administrador en el mismo manifiesto de recuperación. Una restauración limpia de Fathom Lite solo es válida cuando se recuperan los sitios, los usuarios y las visitas históricas, y aparece una nueva visita de prueba después de la recuperación.

¿Fathom Lite necesita HTTPS detrás de un reverse proxy?

Usa HTTPS para el origen público de Fathom Lite y mantén el puerto 8080 en la ruta interna. Aplica correctamente la configuración de Fathom Lite: establece la dirección del servidor y el endpoint HTTPS público que utiliza el script de seguimiento. En Fathom Lite, HTTPS protege las credenciales o el contenido de los usuarios durante el tránsito y mantiene coherente el comportamiento del cliente sensible al origen.

¿Cómo se debe probar un upgrade de Fathom Lite?

Restaura el estado actual de Fathom Lite en un despliegue aislado, aplica la versión candidata y repite su transacción de aceptación. Presta especial atención, porque el esquema de la base de datos de Fathom y el script de seguimiento deben probarse conjuntamente para evitar perder eventos de forma silenciosa. Conserva la imagen anterior de Fathom Lite hasta comprender los límites de migración de datos y rollback.