Swetrix: cookieless analytics that also carries error tracking and performance monitoring
📈 Open source, privacy-first web analytics — a cookie-less Google Analytics alternative with built-in error tracking and performance monitoring. Self-host it or use our cloud. Get started for free!
At a glance
- What is it?
- Swetrix is an AGPL-3.0, TypeScript web analytics platform that drops cookies and folds error tracking, performance monitoring, funnels and custom events into one dashboard. The judgement: the scope is wider than most privacy-first analytics tools, but the README's own feature table marks several headline capabilities as Cloud-only, which changes what a self-hoster actually gets.
- Who is it for?
- Adopt Swetrix if you want pageviews, funnels, custom events, performance metrics and client-side errors in a single AGPL-3.0 stack you can run yourself, and if you can operate MySQL, ClickHouse and Redis together. Do not adopt it if session replays, ISP-level network intelligence, revenue analytics or Ask AI are the reason you are looking, because the README marks those Cloud-only.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Swetrix targets: one page script instead of four vendors
Most teams running a privacy-first analytics tool still need a separate error tracker and a separate real-user monitoring service. Swetrix's pitch is consolidation. The README describes it as a cookieless, GDPR-compliant analytics platform and states that alongside traffic statistics you get error tracking, performance monitoring, session replays, funnels and custom events, so you can replace several tools with one. The audience is a team that has already decided against Google Analytics, either for consent-banner reasons or for data-residency reasons, and now wants to avoid stitching Plausible plus Sentry plus a synthetic monitoring service together. The README claims no cookies, no consent banner, no cross-device tracking, and says all data is anonymised. It also states the project has been open source since 2021 and is funded by subscribers. That funding model matters when reading the feature list, because it explains the Cloud split described below.
What the data flow looks like: tracker scripts into an API backed by MySQL, ClickHouse and Redis
The repository is TypeScript, and the release feed shows two distinct client packages being versioned separately from the main application: tracker-js and tracker-node. That tells you the integration surface is a browser snippet plus a server-side tracker, not a single embedded script. On the receiving end, the self-hosting section of the README says you deploy the API and the UI with Docker and connect MySQL, ClickHouse and Redis. That is a three-datastore topology. ClickHouse is listed in the repository topics next to mysql and redis, which is consistent with the README's claim that there is no data sampling: columnar storage is the usual way to keep aggregate queries fast when you refuse to sample. Redis presumably sits in front for the real-time path, since the README advertises a real-time dashboard. The README does not document the exact write path or which datastore holds what, so treat the division of labour as inferred from the dependency list rather than stated. What is stated is the outcome: a real-time dashboard, top pages, geolocation with a map view, devices, traffic sources and UTM campaigns.
Getting it running: Docker for API and UI, three backing services
The README points self-hosters at a dedicated guide rather than inlining the steps, so the only concrete instruction available here is the shape of the deployment: deploy the API and UI with Docker, connect MySQL, ClickHouse and Redis. There is no docker compose snippet, no environment variable table, and no port list in the supplied material. The Cloud route is simpler by design: the README says you start a free trial at swetrix.com and that pricing runs from $19 per month after the trial, hosted on Hetzner in Germany with data in the EU. For instrumentation, the two versioned tracker packages are tracker-js (most recently 4.6.1, released 2026-08-29) and tracker-node (3.4.0, released 2026-08-28). The README does not show the snippet itself or the initialisation call, so anyone evaluating the integration cost should read the tracker package READMEs before assuming a single copy-paste line. Data portability is documented at the product level: the README states you can export to CSV and access everything through a developer API, with a statistics API linked from the docs.
The Cloud and Community Edition split is the real adoption decision
This is where the README's own table does the most useful work, and where a reader is most likely to be misled by the feature list. Session replays are marked Cloud in the feature list and again in the comparison table. Network intelligence, which breaks traffic down by ISP, organisation, usage type and connection type, is marked Cloud. Revenue and MRR analytics are marked Cloud. Ask AI is marked Cloud. The self-hosting paragraph is explicit about what the Community Edition does carry: privacy-friendly traffic stats, custom events, sessions, funnels, performance and error tracking. So the honest reading is that self-hosting gives you the analytics core plus the two monitoring features that differentiate Swetrix from Plausible, and withholds replays, network intelligence, revenue analytics and the AI query layer. The README's comparison table also ends mid-row, with the Cloud versus Community Edition table truncated in the supplied text. Anyone planning a self-hosted deployment should read that table in full on the documentation site rather than working from the feature bullets, because the bullets and the table disagree in emphasis.
Where Swetrix is the wrong tool
Three constraints stand out. First, operational weight. A MySQL, ClickHouse and Redis stack behind a Docker API and UI is a real service footprint, and it is a different commitment from a single-binary analytics server. If nobody on the team wants to own ClickHouse upgrades, the Cloud tier is the honest choice, and the README says as much by calling Cloud recommended. Second, the Cloud-only features are not incidental extras. Session replay in particular is the kind of capability teams migrate for, and it is unavailable to self-hosters. Third, the AGPL-3.0 licence is a copyleft licence with a network clause. The README does not discuss what that means for anyone embedding Swetrix in a product they distribute or expose over a network. That is a question for your own legal review, not something this article can settle. Separately, the README makes strong privacy claims, including a data policy link, but the supplied material does not include the anonymisation method, so a compliance reviewer will need to read that policy directly rather than rely on the marketing sentence.
Swetrix against Plausible: same privacy stance, different scope
The README frames the comparison itself, and the framing is fair: Swetrix and Plausible are both privacy-first and open source, and the stated difference is scope. The table shows both as cookieless with no consent banner, both GDPR-compliant and EU-hosted, both open source and self-hostable, and both free of data sampling. Where they diverge is everything layered on top of pageviews. Plausible is marked as having funnels only on paid plans; Swetrix lists funnels, custom events, performance monitoring and error tracking, and adds user profiles and identified users. Against Google Analytics 4 the split is sharper: GA4 is marked as using cookies plus a consent banner, sending data to the US, not self-hostable, and sampling at scale. If your requirement is pageviews and referrers with the smallest possible footprint, Plausible's narrower scope is a feature, not a gap. Swetrix is the better fit when the error and performance data are the reason you are shopping.
Upgrade and maintenance cost
The release feed in the supplied material shows tracker-js at 4.6.1 and tracker-node at 3.4.0, with tracker-js moving from 4.6.0 to 4.6.1 within two days in late August 2026. That is an active client-side release cadence, and it means the snippet you install is a dependency you will be updating, not a fire-and-forget tag. The server side is versioned separately, and the README does not describe a migration process, a database schema policy or a supported upgrade path for the MySQL and ClickHouse stores. For a self-hoster that is the main unknown: ClickHouse schema changes are the expensive kind, and nothing in the supplied material says how they are handled. The licence position is AGPL-3.0, which the README states plainly and the repository topics confirm. The README does not offer a commercial exception or a dual-licence route, so a team that cannot accept copyleft terms should treat the Cloud tier as the only option rather than assuming a workaround exists.
Editorial conclusion
Adopt Swetrix if you want pageviews, funnels, custom events, performance metrics and client-side errors in a single AGPL-3.0 stack you can run yourself, and if you can operate MySQL, ClickHouse and Redis together. Do not adopt it if session replays, ISP-level network intelligence, revenue analytics or Ask AI are the reason you are looking, because the README marks those Cloud-only. Before committing, verify what the Community Edition table on the self-hosting page actually lists, confirm the AGPL-3.0 obligations your distribution model triggers, and check that the tracker-js and tracker-node release cadence matches your upgrade budget.
Community notes