Swetrix: cookieless web analytics with error tracking and performance monitoring built in

What Swetrix replaces, and for whom

Swetrix targets the gap between a plain pageview counter and a full product analytics suite. The README frames it as a "privacy-respecting alternative to Google Analytics" and lists what comes bundled: traffic statistics, error tracking, performance monitoring, session replays, funnels and custom events. The pitch is consolidation. A team running a separate error tracker and a separate real-user monitoring tool could, in principle, drop both into the same dashboard as its traffic numbers, provided it is on the Cloud plan.

The audience is narrower than the feature list suggests. Swetrix is built for operators of websites and web apps who care about GDPR posture, and the README states the project is cookieless with no consent banner and no cross-device tracking. That matters most to teams serving EU visitors, or teams that simply do not want a third-party script collecting identifiers. The repository is public and open source since 2021, and the README describes the company as bootstrapped and funded by subscribers, which means the hosted product and the open source code are the same organisation's work rather than a commercial fork of a community project.

How the tracker, API and dashboard fit together

The repository layout tells most of the architecture story. There are three top-level application directories: backend/, web/ and packages/, plus docs/. The topics list names NestJS, ClickHouse, MySQL, Redis and Tailwind, which maps onto a familiar split. The backend is a NestJS API service. ClickHouse holds the analytics event data, the kind of columnar store that suits aggregate queries over large event tables. MySQL handles relational records such as accounts, projects and configuration. Redis sits in front for caching or queueing.

The client side ships as separate tracker packages, and the release list confirms two of them: tracker-js (recently at 4.6.1) and tracker-node (3.4.0). The browser snippet collects pageviews and custom events and posts them to the API; the Node package covers server-side tracking. Because the tracker is described as cookieless, the identification model cannot rely on a stored cookie, so the README's claim of anonymised data is consistent with a design that aggregates rather than profiles visitors across sites. The README does not document the exact anonymisation technique or the identifier lifetime, so anyone with strict data-protection requirements should read the data policy and the tracker source rather than assume.

On the read path, the web/ frontend renders the dashboard against API endpoints, and the README points to a separate statistics API for programmatic access. That endpoint is the same one the dashboard uses, which is why CSV export and the developer API are listed together under data portability.

Self-hosting Swetrix with Docker: install and first event

The README does not inline the install commands. It directs self-hosters to the self-hosting guide at swetrix.com/docs/selfhosting/how-to and describes the shape of the deployment: "Deploy the API and UI with Docker, connect MySQL / ClickHouse / Redis, and you're live." Start there rather than guessing at a Compose file, because the exact service names, ports and environment variables live in that guide and in the repository's backend/ and web/ directories.

The README also names the tracker packages, tracker-js and tracker-node, and the release list gives their current versions, 4.6.1 and 3.4.0. The browser tracker is the piece you embed in a site. The README does not print an install command or an initialisation snippet, so take both from the self-hosting guide and the tracker package's own documentation rather than inventing parameter names. The same applies to the server-side package, which follows the same release cadence.

Once the snippet is on a page, the workflow the README describes is: load the page, then watch the real-time dashboard in web/ update. Custom events are the second step. The README lists custom events and properties as a first-class feature for tracking conversions or sales, and funnels are built on top of them, so a funnel is only as good as the event names you emit. Error tracking and performance monitoring need no extra instrumentation beyond the snippet, according to the feature list, which is the main practical argument for bundling them here.

Where the Community Edition stops

The README is explicit about the split, and it is the single most important thing to read before planning a self-hosted rollout. Swetrix Community Edition ships "the same core analytics: privacy-friendly traffic stats, custom events, sessions, funnels, performance and error tracking." Everything else in the feature list carries a Cloud marker. Session replays, network intelligence (ISP, organisation, usage type, connection type), revenue and MRR analytics, and Ask AI are annotated as Cloud in the feature table and in the bullet list.

That is a real constraint, not a footnote. A team that self-hosts specifically to keep visitor data on its own infrastructure will find that the features most likely to justify Swetrix over a lighter analytics tool are the ones it cannot run locally. The core analytics set is still broader than most cookieless competitors, since error tracking and performance monitoring are included, but the bundle is not identical across the two deployment paths.

A second limitation is operational. Three data stores (MySQL, ClickHouse, Redis) plus an API and a UI is a meaningful footprint for a site that mostly wants pageview counts. ClickHouse in particular is not a database most small teams already run. The README does not discuss backup strategy, upgrade procedure between releases, or how schema migrations are applied, so those are questions to answer from the self-hosting guide and the repository itself before you commit.

Swetrix compared with Plausible and Umami

The README runs its own comparison against Google Analytics 4 and Plausible, and the honest summary is that Swetrix and Plausible agree on the fundamentals. Both are cookieless, both are open source, both are self-hostable, and both avoid sampling. The README states the difference plainly: "the main difference is scope." Swetrix bundles error tracking, performance monitoring and session replays into the same product; Plausible does not, per that table.

Against Google Analytics 4 the split is architectural rather than feature-by-feature. GA4 sets cookies and requires a consent banner, sends data to US infrastructure according to the README's table, and samples at scale. Swetrix claims none of those three. Whether that trade is worth it depends on what you lose: GA4's integration with the wider Google advertising stack has no equivalent here.

Umami and GoatCounter appear in what people search for alongside Swetrix, and both occupy the lighter end of the same category. A single-binary or single-database analytics tool is far cheaper to operate than a NestJS API backed by ClickHouse, MySQL and Redis. If your requirement is pageviews, referrers and a clean dashboard, the heavier stack is a cost with no matching benefit. Swetrix earns its complexity only when you actually use the error tracking, performance metrics or funnels, because those are what you would otherwise buy or build separately.

Maintenance, licensing and the upgrade question

The repository is not archived, and the last push was on 2026-09-07. Tracker releases landed in late August 2026 (tracker-js 4.6.1 on 2026-08-29, tracker-node 3.4.0 on 2026-08-28), so the client packages and the main repository are both moving. That is the extent of what the repository shows about maintenance cadence; the README does not publish a release schedule or a support policy for self-hosted installs.

Upgrade cost is the part the README leaves open. It documents that Cloud subscribers get hosting, maintenance and backups handled for them, and that the subscription funds development. For self-hosters it says nothing about version compatibility between the API and the tracker packages, or about whether a ClickHouse schema change can be applied in place. Treat the tracker version as something you pin deliberately: the release list shows frequent point releases on tracker-js, and a snippet served from a CDN can drift from the API version you run.

The licence is AGPL-3.0, stated in the README badge and in the repository's LICENSE file. The practical consequence, stated as a fact rather than legal advice, is that AGPL-3.0 carries network-use obligations: if you modify Swetrix and let users interact with it over a network, the licence's terms apply to that modified version. Teams that embed analytics in a product they distribute, or that plan to fork and host a modified version commercially, should have counsel read the licence rather than rely on a summary.

Editorial conclusion

Adopt Swetrix if you want traffic stats, client-side error tracking and real-user performance metrics behind one dashboard, and you accept either a subscription or running MySQL, ClickHouse and Redis yourself. Do not adopt it if you need session replays, revenue analytics or Ask AI on your own hardware, because the README marks those as Cloud-only, and do not adopt it if AGPL-3.0 does not fit how you distribute software. Before committing, verify the Cloud versus Community Edition feature table, confirm the self-hosting guide's current Docker Compose file and environment variables, and check whether the developer API exposes the metrics you plan to query.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. Swetrix/swetrix on GitHub