Swetrix

Last reviewed Sep 13, 2026 · 757 words

Swetrix is the analytics tool for people who looked at Plausible's dashboard, liked the cookieless posture, and then wanted user flows, funnels, performance metrics and error tracking on top. The cost of that extra depth is the same as Plausible's: a ClickHouse instance, plus Redis, plus the API and frontend containers. Four containers and 512 MB as a floor is the honest sizing, which puts it above Umami (one container and Postgres) and level with Plausible, so the decision is about features, not footprint.

Four containers, one of them a column store

The self-hosted stack is the API, the frontend, ClickHouse for the event data and Redis for caching and rate limiting. The compose file in the repository wires them up with working defaults; the values you must change are the secrets, the public URLs the frontend and API answer on, and the email settings if you want password resets to work. ClickHouse is the one worth respecting: it is fast at the aggregate queries analytics needs and it is memory-hungry when it merges parts, so give the host 1 GB of headroom and do not put it beside another database that is already tight. On a few thousand page views a day it is bored; the 512 MB in the listing is for a personal blog, not a busy shop.

Cookieless the same way Plausible is

There are no cookies and no persistent identifiers. A visitor is counted by a hash of IP, user agent and a salt that rotates daily, which gives usable unique-visitor and session counts within a day and nothing that links days together. That is the argument for skipping the consent banner in most EU readings, with the usual caveat that your lawyer, not a self-hosting site, signs off on it. The tracking script is small, loads asynchronously, and the API accepts events from your own backend if you want to skip the script entirely.

What you get that the smaller tools do not ship

User flows: a diagram of which pages visitors move between, which is the feature people miss most after leaving Google Analytics. Funnels with named steps. Performance metrics per page, drawn from the browser's timing APIs, so you can see which template got slow after a deploy. Error tracking that captures unhandled JavaScript exceptions with the page and browser, light enough to replace a separate error tool for a small site. Custom events with properties, alerts on traffic thresholds, and a session view that walks through an individual anonymous visit. The self-hosted edition is built from the same repository as the cloud service, and I have not hit a feature gate in it, which is a point in its favour against Plausible, whose community edition trails its cloud.

The younger project risk

Swetrix launched in 2021 and has 1,196 stars against Plausible's tens of thousands. The company behind it is small, the product is their cloud service, and the self-hosted edition is maintained alongside it. In practice that has meant regular releases and a compose file that works; in principle it means the bus factor is low and you should keep an export path. Analytics data is not precious the way photos are, so my tolerance here is high, but do not make Swetrix the only place a metric you report to someone else lives.

Picking between the three

Plausible vs Umami covers the two bigger options in detail. The short version: Umami if you want the simplest possible thing and a Postgres you already run; Plausible if you want the most battle-tested cookieless option and do not need flows; Swetrix if flows, funnels, performance or error tracking would replace another tool you currently pay for. Matomo remains the answer if you need the full Google Analytics feature set with cookies and consent management, and the leaving Google Analytics piece walks through that trade.

What I'd do

For a personal site, Umami. For a small business site where I wanted to see user paths and catch JavaScript errors without paying for a separate error tracker, Swetrix, on a 2 GB VPS with the compose stack as shipped, ClickHouse data on a volume that gets backed up weekly, behind Caddy with the API and frontend on separate hostnames. Set retention once, put the script on the site, and check the flows report a week later; it is the report that justifies the fourth container.