The README's own table says no API, no events, and cookies

The comparison table admits eleven things Lite does not have

The most useful page in this repository is the table the maintainers wrote about their own free version, and it is more honest than the feature claims usually are. Fathom Lite is marked absent for the API. Also absent: custom events, ecommerce tracking and UTMs. Also absent: GA import, email reports, CSV export and shared dashboards. Also absent: EU isolation and custom domains. Also absent: a current dashboard, because the row describes it as an older Lite UI rather than the real-time view with live visitors, filters and details.

The last three rows are about responsibility rather than features. Many sites per account is a typical single install against up to 50 hosted. Email support and an SLA are community and as-is against support on every plan. Global CDN, scaling and backups are your responsibility against included.

So the Lite version is one site, one dashboard, cookies, and no way to get data out of it programmatically. If your reporting process needs a query interface rather than screenshots of a chart, that is the row that decides it.

The development steps still clone into $GOPATH

Production installs are pointed at a document in the tree, docs/Installation instructions.md, and no command is given for them in the README. The development path is spelled out instead, and it starts here:

git clone https://github.com/usefathom/fathom.git $GOPATH/src/github.com/usefathom/fathom
make build

The destination is the interesting part. The repository carries a go.mod declaring module github.com/usefathom/fathom, so it is a module and does not need to live under $GOPATH at all. The documented step is the pre-modules layout, kept because it works, not because it is required.

The rest of the sequence is short. Custom configuration values are optional and live in docs/Configuration.md. A user account is required, and the binary is then started and you visit http://localhost:8080 to see the dashboard. Development gets step-by-step commands while production gets a link to a document in docs/.

Register a user before the server shows you anything

One step in the development sequence is marked required and it is not a build step:

./fathom user add --email=<email> --password=<password>

Then the server:

./fathom server

and the dashboard is at http://localhost:8080. So a fresh binary has no user, and the first thing the interface needs is an account you create from the command line. That is a reasonable design for a single-tenant analytics server and it is worth knowing before you conclude that a blank dashboard is a broken install.

Docker takes the same shape. Building locally is `docker build -t fathom .` followed by `docker run -d -p 8080:8080 fathom`, and the maintainers also publish an image you can run directly:

docker run -d -p 8080:8080 usefathom/fathom:latest

The image is built as `golang:latest` into `alpine:latest` with a health check against http://localhost:8080/health, and the container's command is the same ./fathom server. Tracking itself starts after you create a site in the dashboard and copy the snippet to the pages you want measured.

The compose file commits a database password and a session secret

docker-compose.yml in the repository root is a working example and it is wired to MySQL with credentials written in plaintext:

      - "FATHOM_DATABASE_DRIVER=mysql"
      - "FATHOM_DATABASE_PASSWORD=password01"
      - "FATHOM_DATABASE_HOST=mysql:3306"

The same password appears twice more in the mysql service, as MYSQL_PASSWORD (the password for MYSQL_USER=fathom) and as MYSQL_ROOT_PASSWORD. The database data lives in a bind mount at ./mysql-data, and the MySQL port is published only on 127.0.0.1, so at least the port is not exposed to the network.

Above that block sits a fixed value:

      - "FATHOM_SECRET=TWEn6GXQDx45PZfmJWvyGpXf5M8b94bszgw8JcJWEd6WxgrnUkLatS34GwjPTvZb"

Copying this file as it stands means everyone running it shares the same secret. There is a .env.example in the repository root, which suggests the environment is meant to be moved out of the compose file, and FATHOM_GZIP and FATHOM_DEBUG are in the same list and safe to change.

go.mod pins 1.19 while the Dockerfile builds on golang:latest

The go.mod file declares an old Go version:

go 1.19

The Dockerfile ignores that entirely. Its builder stage is FROM golang:latest, it installs the asset packer with `go install github.com/gobuffalo/packr/v2/packr2@latest`, and the front end is assembled in a node:alpine stage that runs npm install and gulp with NODE_ENV=production before the Go build starts. Both the toolchain and the packer float.

The runtime requirements are older too, and they are pinned in package.json: preact ^8.3.1 for the UI, d3 ^5.7.0 with d3-tip and d3-transition for the charts, pikaday for dates, decko, and a browserify plus gulp toolchain with babelify and uglify for the build.

So the front end is on old major versions and the back end declares a Go version from 2022 while building on whatever Go image is current. That combination is why a from-source build can fail in a way that has nothing to do with your code, and why the pre-built image is the path most people should take.

Three database drivers in go.mod, MySQL 5 in the compose file

The require block in go.mod carries three ways to talk to a database: the MySQL driver, lib/pq for Postgres, and mattn/go-sqlite3. The configuration layer is envconfig, so the choice is made by a variable rather than compiled in, and the compose file sets FATHOM_DATABASE_DRIVER=mysql.

Which brings you to the version. The mysql service in that file is `mysql:5`, a major version that is well past its end of life, with data persisted into ./mysql-data on the host. Running Fathom Lite from the repository's own compose file on a fresh machine means running an unmaintained database major version.

None of that is a criticism of the Go code, which supports three backends. It is a criticism of the path of least resistance. The example a newcomer copies is the one with the old database and the fixed password, and the alternative that supports Postgres is only discoverable by reading go.mod and docs/Configuration.md.

The rest of the require block is small and old in the same way: gorilla mux, gorilla sessions, gorilla handlers, urfave/cli v1.22.10 for the command line, logrus, sql-migrate, godotenv, uuid and x/crypto.

Features are frozen, the newest tag is v1.3.1, and master is three years ahead

The maintenance policy is stated in one sentence near the top: no more features are being added to the Lite version, and it will be kept going with bug fixes. That is the contract, and it is a clear one.

The tag history is where you can see the cost. The three newest releases are v1.3.1 from 2023-01-31, v1.3.0-rc.1 from 2022-11-26 and v1.3.0 from the same day. Nothing has been tagged since January 2023, while the last push to the default branch, master, was on 2026-03-18.

That gap is worth being precise about. There is work in the repository that is not in any release, and there is a .goreleaser.yml in the root that means releases are produced by tooling, so a new tag is a decision rather than a chore. If you want the fixes, build from master and accept that you are ahead of the published artefacts.

Two last details. The tracking snippet needs Content Security Policy allowances if your site uses CSP, specifically script-src and img-src pointing at your instance. And the code is MIT licensed, while Fathom and the Fathom logo are trademarks of Fathom Analytics, which is the boundary a fork has to stay inside.

Editorial conclusion

Take Fathom Lite when you want one self-hosted analytics server for one site, you are willing to run the database and take the backups yourself, and cookie-based tracking is acceptable to the people you report to. Leave it if you need an API, custom events, revenue tracking, more than one site or EU data routing, because the project's own comparison table marks every one of those as absent from the Lite version. Verify three things. Change the database password and FATHOM_SECRET before running docker-compose.yml, since the committed file contains password01 and a fixed secret string. Then read go.mod, which declares go 1.19, against the golang:latest base image the Dockerfile actually builds with, because the two disagree. And check which tag you are building from: the newest release is v1.3.1 from 2023-01-31 while the last push to master was on 2026-03-18, so master is ahead of anything you can download.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. usefathom/fathom on GitHub