Self hosted web analytics

Self-hosting analytics is the only way to be certain where your data is, and it is bought far more often than it is successfully operated. The software is free. The server, the database, the patching, the backups and the person who notices when it stops working are not.

This page is about that second list, because the first one is the part everybody already understands.

The three good reasons

There are three arguments for self-hosting that survive contact with reality.

The first is regulatory. If your organisation has determined that visitor data must not leave its infrastructure, this is not a preference to be traded off, it is a requirement, and self-hosting is the only thing that satisfies it completely. Hospitals, banks, government departments and law firms end up here regularly.

The second is cost at scale. Above a few million pageviews a month, hosted pricing on any tool becomes a real line item, and a self-hosted instance on a server you already run does not. The crossover point is usually higher than people expect, because it has to cover the operational time as well as the hosting.

The third is control of the raw data. A hosted tool gives you its reports; a self-hosted one gives you the event table. If you want to join analytics to your own database, or run queries nobody designed a report for, self-hosting is the only route.

What it actually costs to run

Matomo is the capable option and the demanding one. It is a PHP and MySQL application, and the failure mode is not dramatic: archiving jobs fall behind as the database grows, the dashboard goes quietly stale, and nobody notices for a quarter. Budget for archiving configuration, a patching cadence, backups you have actually tested restoring, and capacity planning when a post does well.

Umami is the lighter option by a wide margin. It is a Node application against Postgres or MySQL, deployable with Docker in an afternoon, small enough to read. You still own backups and upgrades, but nobody has ever been surprised by its operational demands.

GoatCounter is lighter still, a single Go binary, and Shynet is a Django application whose distinguishing feature is that it works with no client-side JavaScript at all, counting with a tracking pixel. Swetrix needs ClickHouse and Postgres and gives you funnels, session recording and error monitoring in exchange.

Plausible's community edition is free and genuinely supported, but it expects a ClickHouse cluster, which is a meaningfully larger commitment than Umami's Postgres.

When not to self-host

If nobody's job description includes operating this, do not self-host. That is the whole test and it is worth being blunt about, because the cost of getting it wrong is not a bad dashboard, it is a year of decisions made on stale data that nobody knew was stale.

Also reconsider if the real motivation is privacy rather than sovereignty. A hosted tool that stores no IP address and rotates identifiers daily gives you a stronger privacy position than a self-hosted tool configured carelessly, because there is nothing in the database to leak in the first place. Self-hosting guarantees you know where the data is. It does not guarantee the data is harmless.

And reconsider if the motivation is cost at a small scale. A $9 subscription against a $20 server plus your own time is not a saving.

The arrangement most organisations actually want

In practice the requirement is usually narrower than self-hosting solves. Most buyers want three things: the data not going to an advertising company, a choice about which jurisdiction it sits in, and the ability to export it.

A hosted cookieless tool with a published jurisdiction option and CSV or API export delivers all three without anybody carrying a pager. If your compliance requirement is written as data sovereignty, read it carefully before you commit to running a database: it often turns out to say something a hosted tool can satisfy.

The rest of the field

Common questions

Related guides