If you run a website and you are tired of shipping your visitors to Google, you have probably looked at privacy-first analytics. Umami is the open-source answer. It is a web analytics platform with roughly 38,000 GitHub stars, licensed under MIT, built with Next.js and TypeScript, and designed around one principle: capture useful traffic data without cookies and without personally identifiable information. That single design choice removes the consent-banner requirement under GDPR and CCPA and eliminates the 30–50% traffic undercounting that cookie-consent-dependent tools suffer.
Umami's appeal is concrete. A roughly 2 KB tracking script, a Docker container plus a database, and you have dashboards showing visitors, page views, bounce rate, referrers, devices, and events — all stored in your own PostgreSQL. No per-seat fee, no data sent to a vendor, no surveillance-capitalism baggage. It is the default answer for self-hosters who want GA-style insight without GA.
But Umami is also a smaller, more focused tool than its marketing-adjacent comparisons suggest. It is not a full product-analytics suite; its cookie-less model means it cannot do cross-site identity tracking or ad-retargeting audiences; and as of v3 it dropped MySQL support, so PostgreSQL is mandatory. This is a long, honest teardown of what Umami delivers, where the sharp edges are, and precisely where your visitor data goes. If you are weighing Umami against Plausible (the AGPL cousin in this space) or against Google Analytics, this article tells you exactly what you are buying and what you are giving up.
1. What Umami Is
Umami is an open-source, privacy-friendly web analytics platform. You add a small tracking script to your site, Umami collects events as visitors browse, and you view them in a clean dashboard. It is written in TypeScript on Next.js, with a database backend, and it positions itself as an alternative to Google Analytics, Mixpanel, and Amplitude — but lighter and without the surveillance.
The project is developed by Umami Software, Inc. (a Delaware C-corp with San Francisco roots) and carries the
umami-software/umami GitHub path. It reports in the mid-30-thousands to 38,000 stars and is among the most actively maintained projects in the self-hosted analytics space, with a steady release cadence through 2026 (v3.1.0 in April, v3.2.0 in June, v3.3.0 in August). The current major line is v3, a substantial rewrite that introduced a new UI, link and pixel tracking, boards, session replay, and web vitals.
Umami's licence is MIT — about as permissive as it gets. Unlike Plausible's AGPL, MIT lets you modify and embed Umami in a proprietary product with no copyleft obligation. For a self-hoster that mainly means there is no licence trap and no feature tier hidden behind a subscription; the self-hosted build is complete and free.
2. The Cookie-Less, No-PII Model
The architectural decision that defines Umami is what it does
not collect. It sets no cookies, and it does not store personally identifiable information — no names, emails, or stable cross-site identifiers in the default configuration. Visitor data is anonymized at the point of capture. That has two big consequences.
First, under GDPR and CCPA, consent banners are generally not required, because you are not processing PII or relying on consent-based cookies. This removes a whole category of compliance friction and the ugly banner that costs you 30–50% of measurable traffic when visitors decline. Second, because there are no cookies to block and no consent to decline, Umami captures effectively 100% of visits — including the cohort that ad blockers and consent tools would otherwise hide from GA4. For accurate, compliant traffic measurement, that is a genuine advantage over the incumbent.
The trade is identity. Without cookies or PII, Umami cannot follow a user across sites, cannot build the cross-site profiles that ad retargeting depends on, and cannot produce the "this visitor is the same person who saw your ad on platform X" linkage. If your use case is ad-tech or lookalike audiences, Umami is the wrong tool by design. If your use case is "how many people visited, from where, what did they do on my site," it is exactly right.
3. The Tracking Script and Event Model
Umami's tracking script is tiny — around 2 KB — which means negligible page-weight impact and fast load. You place it on your site (or use the guided setup added in v3.3.0), and it sends page-view and event data to your Umami instance via a simple API. Beyond page views, Umami tracks custom
events — button clicks, sign-ups, purchases — and
goals derived from them, so you can measure conversions, not just traffic.
Two v3 additions extend the model.
Link tracking gives you short URLs with click-through analytics — useful for measuring the reach of a shared link.
Pixel tracking is an invisible image beacon for tracking email opens and traffic from places where you cannot drop a script. Both are differentiating features that push Umami beyond "lightweight GA clone" into lightweight product-analytics territory, though still short of a full suite.
The event model is the part to design deliberately. A well-instrumented Umami install fires meaningful events (signed up, upgraded, hit error page) rather than just counting page loads; the difference between "I have analytics" and "I have answers" is whether you tracked the actions that matter. Plan your event taxonomy before you deploy, not after.
4. The PostgreSQL Requirement (MySQL Dropped in v3)
Here is the operational fact the quick-start understates: as of v3, Umami requires
PostgreSQL. Earlier versions supported MySQL as well; v3 dropped MySQL, and the supported, recommended, and tested backend is PostgreSQL. If you are migrating from a v2 MySQL install, that is a real migration step, not a config toggle.
So your "free" analytics tool requires a Postgres instance — the same pattern we have seen across this series (Superset needs a metadata Postgres; Umami needs its primary Postgres). For a team already running Postgres this is trivial; for someone hoping for a zero-dependency container it is a surprise. Size the database for your event volume: millions of monthly events are handled comfortably by a well-tuned Postgres with connection pooling, but a tiny instance under a high-traffic site will bottleneck on the database, not on Umami's app layer.
The migration lesson generalizes: when a project drops a database backend, your upgrade plan must include a data move. Read the v3 upgrade notes, dump from MySQL, load into Postgres, verify event counts, and keep the old database until you are certain. Umami's own docs cover this; the failure mode is assuming
docker pull handles it.
5. Deployment: Container Plus Database
Umami deploys as a single Docker container backed by PostgreSQL (or, historically, MySQL). The standard
docker-compose pairs the Umami image with a Postgres image and a volume. There is no separate worker, no Redis, no broker — Umami is simpler to operate than Superset on this axis. It can also run on Node.js or serverless (Vercel) in under ten minutes, and the self-hosted build has no event limits, website limits, or team-member restrictions.
The simplicity is real but has a ceiling. A single container plus Postgres is the right shape for one site or a handful. As event volume grows, you scale the stateless Next.js app layer horizontally (it is stateless — sessions and data live in Postgres) while the database becomes the scaling focus. Connection pooling (PgBouncer or equivalent) matters at high throughput, because each app instance opens connections to Postgres and unpooled growth will exhaust the database's connection limit. Plan the pool before you need it.
6. Dashboards, Boards, and Filters
Umami's dashboard shows the standard analytics surface: visitors, page views, bounce rate, average visit time, countries, devices, browsers, referrers, UTM parameters, events, funnels, user journeys, and revenue tracking. v3.1.0 added
Boards — composed dashboards of charts, tables, metrics, and text blocks bound to one or more websites, sharable with a team. This is the feature that makes Umami genuinely multi-site friendly rather than merely multi-site capable.
Filtering is strong: universal filters passed via URL query parameters (easy to share a filtered view with a teammate), OR logic across filters, segments, and cohorts, plus regex operators for pattern matching. For a small team this is enough analytical depth for daily growth work. The honest limit, repeated from the privacy model, is that "user journey" here means within your site and within a visit session — not a cross-site, cross-device identity graph. Umami stitches a visitor's sessions when they identify themselves (via an identify call), but it does not resurrect a profile from a third-party cookie it never set.
7. Session Replay: Powerful, and Stored
v3.1.0 added
Session Replay, built on the open-source rrweb library. It records real user sessions so you can watch how visitors actually use your site, with configurable privacy masking (the default masks sensitive form fields while keeping layout visible). For a self-hoster the key advantage over third-party replay tools is that the recordings stay on your own infrastructure — no session data sent to a vendor.
But "stored on your infrastructure" is also a responsibility. Session replay is the one Umami feature that retains detailed behavioral data — effectively a video of user interaction — and that has privacy weight even without PII. If you operate under GDPR, replay recordings are personal-data-adjacent and should be covered by your privacy notice and retention policy. Use the masking levels deliberately, set a retention window, and document it. Replay is a feature where Umami's "no PII" default does not automatically make everything privacy-free; the recording itself is the sensitive artifact.
8. Web Vitals and Performance Monitoring
Also in v3.1.0, Umami added
Web Vitals — LCP, INP, CLS, FCP, TTFB — collected from visitors' browsers and shown with industry-standard rating badges. This pulls basic real-user-monitoring (RUM) into the same tool as traffic analytics, so you do not need a separate RUM product for the essentials. For a site owner who wants "is my site fast and who is coming" in one place, that consolidation is convenient.
The caveat is depth: Umami's vitals are the headline metrics, not a full APM. If you need distributed tracing, backend latency breakdowns, or deep front-end profiling, you will still reach for a dedicated observability tool. Umami covers the 80% case — am I meeting Core Web Vitals, and is it slipping — and deliberately stops short of the 20% that an APM owns.
9. Two-Factor Authentication Arrives in v3.3.0
A notable v3.3.0 addition is built-in
TOTP two-factor authentication. Until then, protecting an Umami login meant a reverse proxy with its own auth or a strong password and hope. Now Umami supports standard TOTP (Google Authenticator, Authy, 1Password), with a scannable QR, backup codes, team-level enforcement, and rate limiting on the login flow to blunt brute force.
This matters because Umami dashboards are often shared across a team and sometimes exposed to the internet. 2FA closes a real gap. If you run Umami with more than one login, enforce 2FA at the team level and treat backup-code redemption as the recovery path. The release also made backup-code redemption transactional, fixing a race where one code could be used twice quickly — a small but correct security hardening worth having.
10. Umami vs Plausible: The Licence and the Database
The comparison readers actually want is Umami versus Plausible, the other privacy-first analytics darling. Two axes differ sharply.
Licence: Umami is MIT; Plausible is AGPL. MIT is more permissive — no network-clause copyleft, easier to embed in a proprietary product.
Database: Umami v3 uses PostgreSQL; Plausible uses ClickHouse, which handles very large datasets with better performance. Plausible's cloud bot detection is also more robust than Umami's self-hosted default.
The verdict follows your constraints. If you value the most permissive licence and a PostgreSQL backend you may already run, Umami fits. If you anticipate very high event volumes and want ClickHouse's scale, or you prefer Plausible's polished cloud, Plausible fits. Both are sovereign, cookie-less, and consent-banner-free; the choice is licence philosophy plus database fit, not privacy posture — they agree on privacy.
11. Umami vs Google Analytics: The Sovereignty Trade
Against Google Analytics, Umami's advantage is custody and accuracy. Your visitor data lives in your Postgres, not in Google's warehouse; you capture 100% of traffic regardless of consent or blockers; and you avoid the US-data-transfer exposure that makes GA4 a GDPR liability for EU operators. For a data-sovereign deployment this is decisive.
GA's advantage is depth and ecosystem: cross-device identity, Google Ads integration, massive benchmarking, and a feature surface Umami does not attempt. If you need ad-retargeting audiences or Google's machine-learning insights, GA4 (or a CDP) is the tool; Umami will not do it by design. The decision is whether you prioritize data sovereignty and accurate first-party measurement (Umami) or the surveillance-adjacent depth of the incumbent (GA). Most privacy-conscious site owners have already made that call.
12. Scaling: Stateless App, Stateful Database
Umami scales by separating the stateless Next.js app from the stateful Postgres. The app layer holds no session or event state, so you can run multiple app instances behind a load balancer (or Caddy, which we covered) and scale them independently. The database is where scale lives: event writes are the hot path, and at high volume you need a tuned Postgres, connection pooling, and possibly read replicas for dashboards.
The practical guidance: start with one app container and one Postgres; add app replicas behind your reverse proxy as traffic grows; introduce PgBouncer before connection exhaustion bites; and consider partitioning or retention pruning on the events table so it does not grow without bound. Umami does not auto-prune by default in a way that suits every operator, so set a retention policy that matches your storage and your analysis needs. Unbounded event growth is the quiet way a small analytics install becomes a large database problem.
13. Security Posture and Hardening
Umami is a web app holding visitor data, so the hardening checklist is standard but mandatory. Run the latest patched version; put it behind TLS (a reverse proxy with automatic HTTPS, as covered); restrict the admin login, now with 2FA; set strong
APP_SECRET and database credentials stored in secrets management, not committed config; and never expose the admin surface directly to the internet without auth. The v3.3.0 hardening (rate-limited login, transactional backup codes) shows the project takes app security seriously — match it with your deployment hygiene.
A Umami-specific note: because the tracking endpoint is public (that is how sites report events), ensure it is not an open relay for arbitrary data injection that pollutes your stats. Umami scopes events to configured websites and their tracking IDs, but review your configuration and monitor for anomalous event volume that could indicate spoofed tracking. Analytics you cannot trust is worse than no analytics; protect the ingestion path.
14. The Cloud Offering and Jurisdiction
Umami offers a managed
Umami Cloud with US and EU (Germany) hosting regions and pay-as-you-go pricing. If you use Cloud, your metadata and event data live with the vendor, and the US region carries US CLOUD Act exposure while the EU region removes it for EU-only processing. This article is about self-hosting, where Umami's data holding is eliminated entirely — you run the container and the Postgres, and Umami Software sees none of your visitor data.
The jurisdiction point matters for the self-hosted build only indirectly: the company is US-based, but because the software is MIT and you run it yourself, the company's jurisdiction does not reach your data. That is the structural protection of self-hosting an MIT tool — the vendor's legal exposure is their problem, not a lever on your deployment. Choose self-hosted if data custody is the reason you left GA in the first place.
15. Where Your Data Goes
This is the question this series always answers, and Umami's answer is the cleanest in this batch. Your
visitor events — page views, events, session replays, web vitals — are stored in the PostgreSQL you provision, on infrastructure you control. No visitor data is sent to Umami Software when self-hosted. Your
dashboard definitions and users live in that same Postgres. Session replay recordings, the most sensitive artifact, also stay in your Postgres under your retention policy.
The only data that leaves your network is the tracking beacon from your visitors' browsers to your Umami instance — and that is the whole point, it is your instance, not a vendor's. There is no analytics pipeline shipping to a third party, no profiling feed, no ad network handoff. For a privacy-first deployment, Umami's data flow is about as sovereign as web analytics gets: the only externality is the certificate-issuance handshake if your instance is public, and that reveals nothing about your visitors.
16. What It Costs (The Real TCO)
Umami the software is free under MIT. The TCO is the Postgres plus the compute. Concretely: a Postgres instance (small for modest volume, larger and pooled for high volume) and an app container, on a VPS or Kubernetes — call it $5 to $30 a month of compute for a small-to-mid site, scaling with event volume and retention. The human cost is low: Umami is among the lightest to operate in this series, with no worker tier or broker to babysit.
Compare that to GA (free but your data is the product) or Plausible Cloud (per-event pricing) or a commercial APM. Umami's economics are excellent once you already run Postgres; the only "cost" is the database discipline — backups, pooling, retention — that any stateful deployment requires. For a self-hoster who values custody and accuracy, the price is right and the bill is yours to control.
17. Who Should Run It, and Who Shouldn't
Run Umami if: you want accurate, consent-banner-free traffic measurement; you value data sovereignty and MIT licensing; you already run or can easily run Postgres; and your analytics needs are traffic, events, funnels, and lightweight RUM rather than cross-site ad identity. It is the best general-purpose privacy-first analytics for the self-hosting world.
Do not run Umami if: you need cross-site user identity, ad-retargeting audiences, or Google-Ads linkage (use GA4 or a CDP by design); you cannot provide or operate a PostgreSQL database; or you anticipate event volumes where ClickHouse's scale would serve you better and you would rather not tune Postgres. And be honest that v3's MySQL drop means a v2 MySQL install is a migration project, not a silent upgrade. Umami rewards operators who accept its privacy model and its Postgres requirement; it frustrates those who expected a cookie-based, multi-DB, zero-dependency widget.
18. A Minimal Deployment Recipe
To make the operational shape concrete, a typical self-hosted Umami is a
docker-compose with two services: the
umami image (pointed at
DATABASE_TYPE=postgresql and a
DATABASE_URL) and a
postgres image with a named volume. You set
APP_SECRET to a strong random value, expose Umami behind your reverse proxy with TLS, and add the tracking script to your site. That is the entire footprint — no worker, no Redis, no broker.
The details that bite:
APP_SECRET must be stable across restarts or sessions invalidate; the Postgres volume must be backed up or your event history is lost; and the
DATABASE_URL must point at the Postgres service, not a stale SQLite default some old guides still show. Use the official current docs, not a blog post from the v2 era, because the MySQL default is gone and the env keys have shifted. A correct compose file, a backed-up volume, and a secret in your secrets manager is a ten-minute, durable install.
19. Identify, Session Stitching, and the Limits of Privacy
v3.3.0 added
session identity stitching: when a visitor identifies themselves (say, by logging into your app and triggering Umami's identify call), their sessions across devices and visits link into one continuous profile, surfaced in the session view. This is the closest Umami comes to "user journey" tracking, and it is opt-in via your own identify call — Umami does not infer identity from cookies it never sets.
The limit is the point: stitching only works for visitors you explicitly identify, and it stitches within your first-party context, not across the open web. You cannot reconstruct a stranger's cross-site history; you can only connect the sessions of a user who told you who they are. This is the right privacy boundary — identity is something the visitor grants, not something Umami harvested. Use identify for logged-in product analytics; do not mistake it for the cross-site graph a cookie-based tool builds without consent.
20. Funnels, Goals, and Conversion Honesty
Umami supports
funnels — sequences of steps (pages or events) that measure where visitors drop off before converting — and
goals derived from events. These let you answer "of the people who landed on pricing, how many started signup, and how many finished?" which is the question that actually drives a business. Funnels are a genuine product-analytics capability, not just a traffic counter.
The honesty caveat: a funnel is only as good as the events you fire. A funnel built on page views assumes your URLs map cleanly to steps; a funnel built on explicit events (signed_up, paid) is far more reliable. Design events as the source of truth and build funnels on them, not on URL guessing. And remember the privacy model — funnels describe behavior within your site, not a retroargetable audience. Umami tells you where users drop; it does not hand you a list to advertise at.
21. Bot Detection: The Self-Hosted Gap
One area where Umami's self-hosted build is thinner than Plausible's cloud is
bot detection. Plausible's managed offering applies robust server-side bot filtering; self-hosted Umami relies more on your configuration and the inherent noise resistance of first-party tracking. Untuned, a self-hosted Umami can show inflated numbers from crawlers, preview bots, and synthetic traffic that a cloud filter would have stripped.
The mitigation is operational: filter known bot user-agents at ingestion or at the reverse proxy, exclude internal IPs, and periodically sanity-check your totals against server logs. Umami's filters help, but bot detection is not a solved default in the self-hosted build the way it is in a mature cloud. If clean numbers matter for reporting to stakeholders, invest in the filtering layer rather than trusting the raw count. Analytics you present should be human, not crawler.
22. Teams, Sharing, and the Public Share Page
Umami supports multiple team members with no hard limit in self-hosted, and v3.1.0 rebuilt the
public share page with mobile support, a collapsible sidebar, and per-share display options — you can name a share link and choose exactly which sections (overview, events) a visitor sees. This is how you show a client a dashboard without exposing your whole account, and it is a small but real multi-tenant feature for agencies and consultants.
The access-control note: a public share link is, by definition, open to anyone with the URL. Treat share links as semi-public, scope them to the minimum sections, and rotate or revoke them when a engagement ends. For internal team access, use Umami's own user accounts (now with 2FA) or wire OIDC through your IdP so offboarding is centralized. Share links are convenience; your identity layer is the real boundary.
23. Retention, Pruning, and the Events Table
Because Umami stores every event in Postgres, the events table grows continuously, and unbounded growth is the quiet way a small install becomes a large database problem. Umami does not aggressively auto-prune by default in every configuration, so you should set a
retention window that matches your analysis needs and your storage budget, and prune expired events on a schedule.
Practical sizing: a low-traffic site generates trivial volume and can keep years; a high-traffic site generating millions of events a month will need retention of weeks or months and regular pruning to keep queries fast and storage bounded. Pair retention with connection pooling and, at scale, consider partitioning the events table by time. The database discipline here is the same as anywhere else in this series — stateful data needs a lifecycle, or it owns you.
24. Upgrading: The v2 to v3 MySQL Migration
The upgrade that deserves its own section is v2 → v3, because v3 dropped MySQL. A v2 install on MySQL cannot simply pull v3; you must move the data to PostgreSQL first. The path is: stand up a Postgres, dump the v2 MySQL data, load it into Postgres, point Umami at the new
DATABASE_URL, run v3, and verify event counts and dashboard integrity before decommissioning the old database.
Two errors to avoid: assuming
docker pull migrates the backend (it does not), and deleting the MySQL database before confirming the Postgres copy is complete and correct. Keep the old database until you have compared totals and spot-checked recent events. The v3 line is a clear improvement — better UI, replay, vitals, 2FA — but crossing the MySQL-to-Postgres line is a planned migration, not a background pull. Budget it as such.
25. A Practical Hardening and Sizing Checklist
To close the loop, a concrete checklist for production Umami: run the latest patched version; put it behind TLS via your reverse proxy; enforce 2FA on team logins; store
APP_SECRET and DB credentials in secrets management; back up the Postgres volume on a real schedule with a restore drill; set an event retention window and prune; add bot and internal-IP filtering; review the public share-link scope; and scale the app layer (stateless) behind your proxy while tuning Postgres with connection pooling. None of these are exotic; together they turn "I dropped in a script" into "I run analytics I can trust and defend."
26. Umami vs Matomo: The Other Open-Source Choice
Matomo is the other serious open-source analytics option, and the contrast is worth a line. Matomo is heavier and more feature-rich — it can do heatmaps, session recording, A/B testing, and a broader report suite in its paid tiers — but it is a larger operational footprint and a more complex install. Umami is deliberately lighter: fast to stand up, privacy-first by default, and focused on the traffic-and-events core rather than the full Matomo suite.
The choice follows maturity of need. If you want a broad analytics platform with heatmaps and deep reporting and you can run the heavier stack, Matomo is the fuller tool. If you want accurate, consent-free, first-party traffic and event measurement with minimal operational weight, Umami is the leaner fit. Both are self-hostable and sovereign; Umami wins on simplicity, Matomo on breadth. Most self-hosters who start with Umami do so precisely because they do not want Matomo's weight.
27. The 2 KB Script and Page-Weight Reality
A small but real advantage is the tracking script size — around 2 KB. On a performance-sensitive site, a 2 KB async beacon is effectively free: no measurable layout shift, no meaningful load cost, and no third-party round trip to a vendor CDN that itself costs latency. Compare that to GA4's larger tag plus its dependent libraries, and Umami is the kinder choice for the visitor's experience as well as their privacy.
This matters more than it sounds for a privacy-first operator, because the argument "privacy tools slow my site" fails here. Umami's light footprint means you can measure everything without trading page speed — and since it captures 100% of visitors (no consent drop-off), the data you get is both complete and gathered without costing your Core Web Vitals. The script is the visible expression of Umami's "do less, do it privately" philosophy.
28. The Bottom Line
Umami is the privacy-first analytics tool that actually respects the word: no cookies, no PII, 100% capture, and your data in your own Postgres under MIT licensing. It is the cleanest data-sovereignty story in this batch — nothing about your visitors leaves your infrastructure when self-hosted. The things to accept going in are the Postgres requirement (mandatory since v3, MySQL gone), the deliberate absence of cross-site identity and ad-retargeting, the self-hosted bot-detection gap you must close yourself, and the database discipline (backups, pooling, retention) that any stateful tool demands. Do those, and Umami gives you GA-style insight without GA's custody cost — which is exactly the trade a sovereign operator wants to make. It is not the heaviest or the most feature-rich analytics tool available; it is the one that asks the least of your visitors and the least of your conscience.
29. GDPR Deletion Requests and the Honest Operational Cost
A privacy-first tool still has to answer the hard privacy question: when a visitor invokes their right to erasure, can you actually delete their data? Because Umami is first-party and stored in your Postgres, you can — but "can" is not "automatic." A deletion request means finding the visitor's sessions (by IP, by identified user, or by session id if you issued one) and removing or anonymizing their rows, including any session replay recordings, before your retention window would have purged them.
Umami's v3.3.0 session delete feature for relational databases makes this more tractable, but the workflow is still yours to operationalize: you need a process, a mapping from request to records, and a confirmation that replay and event rows were both cleared. The lesson generalizes across this series — self-hosting gives you custody, which means you own the deletion too, not a vendor's "submit a ticket" flow. If you operate under GDPR, document the erasure procedure before you get the first request, not during it. Sovereignty is real; the responsibility is real too.
Related
For the rest of a sovereign, self-hosted stack, these pieces from our series travel with Umami:
Comments (0)
No comments yet. Be the first to comment!