Fathom Lite: self-hosted, cookie-based website analytics in Go

What Fathom Lite actually is, and who it is for

Fathom Lite is the first, open-source version of the software behind the paid Fathom Analytics product. The README states it plainly: "Fathom Lite is a previous and open-source version of Fathom Analytics (a paid, hosted Google Analytics alternative)." It is a self-hosted analytics server. You run the binary, point a tracking snippet at it, and read pageviews in a dashboard you host.

The audience is narrow and specific. It suits an operator who already runs a server, wants pageview and referrer numbers without sending them to a third party, and is comfortable with Go binaries and a database. The README's own comparison table lists what Lite does not have: no API, no custom events or ecommerce, no UTM campaign reporting, no EU isolation, no GA import, no email reports or CSV export, and typically one install per site rather than many sites per account. The table also marks Lite as using cookies, which means an analytics consent banner may still be required where you operate. If any of those missing items is the reason you are looking at Fathom at all, the hosted product is the thing you want, not this repository.

The Go server, the SQLite or MySQL store, and the Preact dashboard

The repository layout tells most of the story. main.go is the entry point, pkg/ holds the server code, and assets/ holds the front end. The Go module declares the pieces you would expect: gorilla/mux for routing, gorilla/sessions and gorilla/securecookie for dashboard login, sqlx over lib/pq, go-sql-driver/mysql and mattn/go-sqlite3 for storage, sql-migrate for schema migrations, urfave/cli for the command line, and mssola/user_agent for parsing the browser string on each hit.

The front end is not a separate application. package.json lists preact plus d3, d3-tip and d3-transition for the charts, pikaday for the date picker, classnames and decko. gulpfile.js drives gulp, browserify and babel to bundle those into assets/build, and the Dockerfile copies that build directory into the Go build before packr2 embeds it. That is why the shipped binary can serve the dashboard without a second process or a web server in front of it.

Data flow is conventional. A page load fires the snippet, which sends a request to your Fathom instance. The server resolves the site, parses the user agent and referrer, and writes a row through sqlx into SQLite or MySQL. The dashboard queries those rows and renders them with d3. There is no queue, no external service, and no aggregation pipeline that the material describes. For a single server this is simple and predictable; it also means the database is the whole system, and losing it loses the history.

Installing Fathom Lite and registering the first account

The README points production installs at docs/Installation instructions.md and gives the development path inline. For a development build you need Go and NPM, then clone into your GOPATH and compile:

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

The README notes that custom configuration values are optional and documented in docs/Configuration.md. A user account is not optional: the server will not give you a dashboard until one exists.

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

The README says to visit http://localhost:8080 after starting the server. That is where you create a site and copy the tracking snippet onto the pages you want to measure.

The Docker path is shorter. The README gives a build command and a run command, and there is a pre-built image:

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

The repository also carries a docker-compose.yml that pairs the image with MySQL 5 and sets the connection through environment variables, including FATHOM_DATABASE_DRIVER, FATHOM_DATABASE_NAME, FATHOM_DATABASE_USER, FATHOM_DATABASE_PASSWORD, FATHOM_DATABASE_HOST, FATHOM_SERVER_ADDR, FATHOM_GZIP and FATHOM_DEBUG. Note that the compose file ships a literal FATHOM_SECRET value in plain text. Generate your own before exposing the instance; that value signs session cookies, and the one in the repository is public.

Finally, if your site sets a Content Security Policy, the README says Fathom needs these directives, with your own host substituted for yourfathom.com:

script-src: yourfathom.com;
img-src: yourfathom.com;

Where Fathom Lite stops being the right tool

The README is unusually direct about this, which is worth crediting. It says the project is "no longer adding features" and that the team will "continue to maintain it long-term and fix any bugs that come up." The most recent release listed is v1.3.1 from 2023-01-31, and the last push to the repository was on 2026-03-18. Bugfix maintenance is not the same as active feature development, and you should plan around the feature set you see today.

The larger limitation is cookies. The comparison table marks cookie-free tracking as a hosted-only feature, so a Lite install sets cookies on visitors. If your reason for leaving a hosted analytics product was to avoid a consent banner, Fathom Lite does not get you there. Privacy-focused is not the same as cookie-free, and the README does not blur the two.

The operational gap is the other one. The table assigns you the servers, the updates, the scaling and the backups. There is no API, so anything you want to do programmatically with the collected data means reading the SQLite or MySQL database directly, and the schema is an implementation detail the README does not document. There is no CSV export and no email report. If your team expects to pipe analytics into a warehouse or a BI tool, budget for writing that yourself against a database whose shape is defined by the migrations in the repository.

Fathom Lite against a hosted analytics service

The honest alternative here is the hosted Fathom Analytics product, and the README frames the choice itself. The difference is not the dashboard or the colour scheme; it is who holds the data and who does the work. Hosted Fathom is a managed service with pricing based on monthly pageviews, and the README says the same core capabilities appear on every plan: API access, up to 50 sites, custom events and ecommerce tracking, unlimited email reports and CSV exports, and what the README calls forever data retention. It is also cookie-free, which the README lists as a hosted-only property, and it offers EU isolation and custom first-party script domains.

Lite gives you the opposite trade. You keep the data on your own hardware, you pay for the server rather than per pageview, and you own every failure mode: the database, the backups, the TLS certificate, the upgrades. What you give up is the API, events, ecommerce, exports, reports, multi-site management, and any feature work after v1.3.1.

A self-hosted alternative worth knowing about is a general-purpose analytics stack such as Matomo or Plausible, which target the same self-hosting audience with different scopes. The difference that matters for a decision is that Fathom Lite is a single Go binary with an embedded dashboard, so the deployment surface is small, while those projects typically expect a PHP or Elixir runtime and a separate database to be maintained. If a small binary and an MIT licence are your priorities, that matters more than the feature list.

Maintenance, upgrades and what the MIT licence leaves you

The upgrade cost is low in the sense that there is little to upgrade. Releases are sparse: v1.3.0 and v1.3.1 both landed in the 2022 and 2023 window, and the README describes the project as in bugfix maintenance. You are not tracking a fast-moving dependency graph, but you are also not receiving new work.

The bigger cost is the database. The Go module pins sql-migrate, so schema changes arrive as migrations, and moving between versions means running the binary against your existing SQLite or MySQL store. The README does not document a rollback procedure, and it does not describe a backup command. If you self-host, that is on you, and the practical consequence is that you should decide on a backup method for the database file or the MySQL volume before you have data worth losing.

The licence is MIT, stated in the README and in the LICENSE file, and package.json repeats it for the front-end dependencies. MIT is permissive: you can run it, modify it and redistribute it. It comes with no warranty, which is the standard trade and the reason the README can describe support as community or as-is. One detail that is not a licence matter but sits next to it: the README says Fathom and the Fathom logo are trademarks of Fathom Analytics, so a fork that reuses the name or the logo is a different question from the code licence. None of this is legal advice; if you plan to redistribute a modified build, read the LICENSE file and the trademark line yourself.

Editorial conclusion

Adopt Fathom Lite if you want a small, MIT-licensed Go analytics server you can run yourself and you accept that it uses cookies, has no API, and receives bugfixes rather than features. Do not adopt it if you need cookie-free tracking, custom events, ecommerce, or a managed service. Before committing, verify that the tracking snippet reports pageviews into your own instance, that the FATHOM_SECRET value in your deployment is not the one committed in docker-compose.yml, and that your Content Security Policy allows script-src and img-src from your Fathom host.

Frequently asked questions

Official sources

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