How to self-host web analytics

Self-hosting web analytics is appealing for obvious reasons: you own the data, you control retention, there is no per-event bill and no vendor can change the terms under you. It is also more work than the marketing pages suggest. This article is an honest look at what self-hosting actually involves, which tools support it and when it makes sense.

Full disclosure: Lumenlytic is a managed product and does not offer self-hosting. If self-hosting is a hard requirement, the tools below are where to look. The goal here is to help you decide whether self-hosting is worth it for your situation, not to talk you out of it.

What self-hosting actually means

At minimum you need a server or container platform, a database, a way to apply schema migrations, backups, monitoring and a plan for upgrades. For a low-traffic site, a single small VPS is plenty. For anything larger, you are now operating a service: disk fills up, migrations fail, a release introduces a bug, and someone has to notice at 2am because you are the vendor now.

The cost is rarely the server. A $5–10 per month VPS can handle a lot of analytics traffic. The real cost is the hours: initial setup, ongoing upgrades, security patches, backups and the occasional outage. If you already run infrastructure and enjoy it, that cost is low. If this is your first server, it is higher than the monthly bill of a managed tool by a wide margin.

Tools that support self-hosting

• Umami — open source, event-billed on the managed side, straightforward to run.
• Matomo — the most mature self-hosted platform, with deep reporting and heavier infrastructure.
• Pirsch — open-source core, privacy-focused, good fit for smaller deployments.
• Plausible — an open-source core alongside its managed cloud offering.

Each of these is a legitimate choice. Umami and Pirsch are lighter and easier to get running; Matomo is heavier but far more feature-complete. Plausible has the longest track record among the privacy-first options. All of them are cookie-free or offer a cookie-free mode, which is the main reason people choose them over a hosted ad-tech-adjacent tool.

A realistic setup with Docker

Most self-hosted tools ship a Docker image and expect a Postgres database. A typical first deploy looks like this, though you should follow the tool's own docs rather than copying a generic snippet.

# Illustrative only — use the vendor's official compose file.
docker run -d --name analytics \
  -p 3000:3000 \
  -e DATABASE_URL=postgres://user:pass@db:5432/analytics \
  -e BASE_URL=https://analytics.example.com \
  ghcr.io/example/analytics:latest

Then you need TLS (usually a reverse proxy such as Caddy or Traefik), a backup schedule for the database, and a way to apply upgrades without losing data. None of that is hard individually; together it is a small operations job that never quite goes away.

When self-hosting is the right call

• You have a hard data-residency or procurement requirement.
• You already operate servers and the marginal cost is low.
• You want full control over retention and deletion.
• You are willing to own upgrades, backups and monitoring long term.

When managed wins

Managed tools exist so you can spend your time on the product rather than the analytics server. A managed, cookie-free tool gives you the privacy benefits without the operations burden. Lumenlytic's free plan covers 200k events a month, and paid plans start at $15 — which is often less than the value of the hours you would spend maintaining a self-hosted instance, even before you count the occasional outage.

The honest summary: self-host if you have the requirement and the appetite for operations. Choose managed if you want the data and the privacy without becoming a sysadmin. Both are reasonable; the mistake is underestimating the ongoing time cost of the self-hosted path.

The security work nobody mentions

Self-hosting analytics means you are storing data that describes your visitors, so the security bar is not zero even for a cookie-free tool. You need TLS, a firewall, timely dependency updates, a database that is not exposed to the internet and backups that you have actually tested restoring. A misconfigured instance can leak referrers, paths and device data, and an unpatched container can become someone else's problem. None of this is unique to analytics, but it is easy to forget when the install takes ten minutes. Budget time for the boring parts, because they are the parts that matter when something goes wrong.

Backups deserve special attention. Analytics history is only valuable if it survives a bad migration or a lost volume, and many self-hosted setups have no tested backup at all. Decide how often you need a snapshot, where it lives and how you would restore it, and write it down before you need it. A managed tool folds this into the subscription; self-hosting makes it your job. Neither is wrong, but the responsibility is real and should be part of the decision rather than a surprise six months in.

A checklist before you commit

• Do you have a server and the skills to keep it patched?
• Will you actually test a backup restore, or just assume it works?
• Is there a hard data-residency requirement, or is control a preference?
• Who gets paged if the instance goes down at the weekend?
• Have you compared the all-in hours with the cost of a managed plan?

If your answers point toward self-hosting, start small and boring. Use a single container and a managed database, automate backups, pin versions and write down the restore steps before you need them. Resist the urge to customise deeply in the first month; a plain install that you understand is more reliable than a clever one you have to debug under pressure. If your answers point toward managed, that is not a failure of ambition. The point of privacy-first analytics is to get trustworthy numbers with less machinery, and for most teams a managed cookie-free tool reaches that goal faster and with fewer surprises than running the server themselves. That is a legitimate engineering trade, not a compromise on privacy or quality, and it is worth saying so plainly. Pick the model your team can actually sustain, and revisit it as the team and traffic change.