Open-source analytics tools — auditable code, owned data

What "open-source" should mean for analytics

Half the tools advertised as "open-source" in this category are open-core teasers: a stripped public repo, a vendor-managed cloud, and the features that actually matter living behind a proprietary EE license. That's a valid business model, but it's not what an open-source-first developer is buying. Below are the tools where the source on GitHub IS the product — whether you self-host or use the vendor cloud.

The four facts checked for each: (1) the public repo runs the same code the vendor cloud runs; (2) the license is a recognized OSI license (AGPL-3.0, MIT, GPL-3.0, EUPL-1.2) without a brand-restriction trojan clause; (3) there's real commit activity from people other than the founder; (4) a self-host deployment is a documented first-class path, not a footnote.

Web analytics or data analytics? Two different "open-source analytics"

"Open-source analytics" means two unrelated categories, and search results mix them freely. If you want to measure website traffic — pageviews, referrers, campaigns, conversions — you want open-source web analytics. That's this page. If you want to run SQL against a warehouse you already own and build internal dashboards from business data, you want open-source BI / data analytics — Apache Superset, Metabase, Redash, Grafana. Different problem, different stack, different shortlist.

The two overlap just enough to confuse: a BI tool can chart your traffic if you pipe events into a warehouse first, and several web-analytics tools advertise product-analytics features. The clean test: if the tool ships a JavaScript snippet you paste into your site, it's web analytics. If its setup starts with a database connection string, it's BI. Everything reviewed on this site is the first kind.

The license spectrum, ranked by your freedom

1. MIT / Apache-2.0 (Umami, Litlyx) — Most permissive. You can fork, modify, ship as part of a closed product, sell. The license barely constrains you.
2. EUPL-1.2 (GoatCounter) — EU-equivalent of GPL-3.0 but explicitly compatible with GPL/AGPL/CDDL/etc. Copyleft, but with clean compatibility. Solo-dev favorite.
3. AGPL-3.0 (Plausible, Matomo, OpenPanel) — Strongest copyleft. If you self-host AGPL software on a public service, you must publish your modifications. Locks vendors into open-source forever; some commercial users back away.
4. AGPL with brand restriction (Countly, some forks) — A real AGPL with a clause prohibiting commercial use of the brand name. Technically still OSI-compliant; ethically debated.

Pick by stack — the database decides your ops

License gets the attention, but the runtime stack decides what self-hosting actually feels like. The database is the part you'll back up, tune, and migrate — choose it as deliberately as the license:

The pattern: let your existing infrastructure pick the tool. A PHP shop that already administers MariaDB will run Matomo for years without thinking about it — and the same team will fight ClickHouse every quarter. If you have no infrastructure opinions at all, single-binary GoatCounter is the hardest to break.

The maintenance reality

Going open-source is a license decision, but the production decision is bus factor. Here's what that means in practice:

• Multi-maintainer projects — Matomo (15 years, dozens of contributors), Plausible (active team), OpenPanel (early but well-resourced). If the founder leaves, the project survives.
• Solo-developer projects — Umami, GoatCounter, Ackee. Excellent code, but the bus factor is 1. If the maintainer burns out, your self-host stays running but stops getting security patches. Mitigate with a fork-friendly license + a backup plan.
• Vendor-led with public source — Plausible CE, OpenPanel. The cloud is the business; the source is the trust signal. You'll get security patches because the vendor needs them for their own SaaS, but expect feature gates between CE and EE. Newer entrants like Rybbit, Databuddy and Swetrix sit in this class too — run the repo audit below before betting on one.

How to audit a repo before you bet on it

Twenty minutes on GitHub tells you more than any review — including this one. Before you commit to a tool, check five things:

1. Commit cadence on the default branch. Weekly activity is healthy; a repo quiet for six months is on life support no matter what the marketing site says.
2. Time-to-response on issues. Open a few recent bug reports and look at how long maintainers took to answer. Silence on bug reports today predicts silence when your upgrade breaks next year.
3. Release notes with upgrade paths. A project that documents breaking changes respects self-hosters. A changelog that's auto-generated commit spam doesn't.
4. Contributor spread. Insights → Contributors. One name owning 95% of commits is the bus-factor warning from the previous section, drawn as a graph.
5. A security policy. A SECURITY.md with a disclosure contact. Analytics endpoints ingest untrusted traffic from your visitors' browsers — you want maintainers who have thought about that.

The honest cost of self-hosting OSS

The "free" in "open-source and free" only covers the license. Self-hosting any of these tools costs you ops time, infrastructure, and an upgrade cadence. Realistic numbers for a 100k-pageview/mo site:

• Cheap path: Umami on a $5 VPS + managed Postgres ($15/mo) = $20/mo + ~2 hours/month of ops. Total cost: $20/mo + $200/year of your time at $100/hr.
• Standard path: Matomo on a Hetzner CPX12 (€11.99/mo — the cheaper CX line is not available to order) + dedicated MariaDB + nightly backups, plus ~6 hours/month for archive cron and plugin updates.
• Scaled path: Plausible CE on ClickHouse cluster needs 4+GB RAM minimum = $30-50/mo VPS + ClickHouse tuning expertise. Significant ops.

When NOT to pick OSS

Open-source is the wrong call if any of these are true: you have zero ops capacity, you need vendor support with an SLA, your buyers (legal/procurement) require a real DPA from a real legal entity. The vendor-managed cloud version of these tools (Matomo Cloud, Plausible Cloud, etc.) gives you the OSS code path with managed ops — at a price. Most teams should pay it.

Open-source analytics FAQ

Is Google Analytics open source?

No. GA4 is proprietary, closed-source SaaS — the collection pipeline, the processing, and the reporting UI are all Google's, and you can't inspect or self-host any of it. The gtag.js snippet you paste into your site is a loader for that closed system, not open code. If auditable code and owned data are the requirement, the tools on this page are the way out.

Which open-source tool is closest to Google Analytics?

Matomo, and it isn't close — it's the only one that competes on feature breadth: goals, funnels, ecommerce, custom dimensions, even a tag manager, plus an official Google Analytics importer for your historical data. If what you actually want is less than GA4 — one clean dashboard instead of 200 reports — start with Plausible or Umami instead.

Are open-source analytics tools actually free?

The license is free; production isn't. Budget the realistic numbers from the cost section above: a VPS, backups, and your ops hours every month. If that math doesn't work for you, the managed cloud of the same tool keeps the open code path and hands the ops bill to the vendor.

Can I run these without a cookie banner?

Mostly yes — much of this list is cookieless by default, and Matomo has a documented cookieless configuration. But cookieless is its own set of trade-offs and tests, and it's a different question than the license. That's a separate list: cookieless analytics tools.