Why self-host your web analytics
Benefits of self-hosted analytics
- Native GDPR compliance: no third-party data transfer, no consent banner required when no cookie is used
- 100% data ownership: CSV/SQL export at any time, long-term retention with no expiry
- Fixed cost: a €6/month VPS handles millions of pageviews
- Lightweight script (< 2 KB): negligible impact on Core Web Vitals
- No sampling: every pageview is counted, even at high volumes
- Open source: auditable code, no vendor lock-in
Plausible vs Umami: key criteria comparison
Scroll the table
| Criterion | Plausible 3.2 | Umami 3.4 |
|---|---|---|
| Language / stack | Elixir + ClickHouse | Node.js + PostgreSQL |
| Database | ClickHouse (columnar) | PostgreSQL only (MySQL dropped in v3) |
| Interface | Very minimal, single-page | Multi-site, configurable dashboards |
| Funnels | Yes, multi-step with revenue tracking | Yes, via custom reports |
| Custom events | Yes, with props API | Yes, with props API + TypeScript SDK |
| Heatmaps / Session replay | No | Yes (v3.4, 2026) |
| Advanced segmentation | Combined filters | Session segments, property filters |
| Recommended min RAM | 2 GB (ClickHouse) | 512 MB |
| License | AGPL-3.0 | MIT |
Prerequisites by tool
Plausible requires ClickHouse, a columnar database built for time-series data. ClickHouse is powerful but RAM-hungry: plan for at least 2 GB, ideally 4 GB for a comfortable instance. Umami runs on PostgreSQL, which is far lighter: 512 MB is enough for moderate-traffic sites. If your VPS already runs PostgreSQL for another application, Umami integrates without additional resources. As of Umami v3, MySQL is no longer supported; if migrating from an older MySQL install, export and reimport to PostgreSQL first.
Deploying Plausible (or Umami) on a VPS
Clone the official repo (
plausible/community-editionorumami-software/umami) and copy.env.exampleto.envFill in required variables:
SECRET_KEY_BASE(Plausible) orAPP_SECRET(Umami), public URL, database credentialsRun
docker compose up -d— the image pulls ClickHouse/PostgreSQL and auto-migrates the schemaConfigure an nginx reverse proxy with HTTPS (Let's Encrypt) on your chosen domain, and ensure
X-Forwarded-Foris forwarded correctlyAdd the tracking script to your site and verify the first pageview in the dashboard
Block bots at the nginx level (if ($http_user_agent ~* "(bot|crawler|spider)")) to keep your stats clean without any analytics-side configuration.
Decision tree: Plausible or Umami?
Choose Plausible if…
- You want an interface any teammate understands in 5 minutes without training
- Your team doesn't need session replay or heatmaps
- You have at least 4 GB of RAM on the VPS (ClickHouse earns it)
- You manage several sites from a single minimalist dashboard
- You need multi-step funnels with built-in revenue tracking (Plausible 3.2)
Choose Umami if…
- You have a resource-constrained VPS (512 MB–1 GB RAM) or PostgreSQL is already installed
- You need heatmaps and session replay (Umami 3.4, 2026)
- Your team builds custom integrations via the official TypeScript API (
@umami/api-client) - You manage many sites for different clients (native multi-tenant)
- You want to query your data in natural language via an AI assistant using MCP (Umami 3.4)
GDPR, CNIL, and ePrivacy compliance: what each tool actually covers
Both tools are designed to work without tracking cookies and without storing complete IP addresses. Plausible hashes the IP with a daily rotating salt; Umami uses a similar approach. Result: no persistent identifier is stored server-side, which allows you to skip the consent banner for analytics alone — provided the script is not combined with other trackers. The French CNIL, in its 2024 recommendations on GA4 alternatives, explicitly cites self-hosted cookieless analytics as exempt from consent when data stays on servers under EU jurisdiction. The ePrivacy Directive points the same way. Caveat: if you host outside the EU or aggregate with a third-party advertising solution, the exemption no longer applies. Documenting hosting details (VPS location, retention policy) in your processing register remains mandatory.
Migrating from Google Analytics 4
Steps to move from GA4 to Plausible or Umami
Export GA4 history as CSV via Google Analytics > Reports > Export, or via the GA4 Data API for large volumes — neither Plausible nor Umami imports this history natively, but you can keep it as an archive
Run the Plausible/Umami script alongside the GA4 tag for 2–4 weeks to compare metrics (numbers will differ: GA4 samples, Plausible/Umami count everything)
Verify that critical custom events (forms, clicks, purchases) are replicated via
plausible('goal')orumami.track()Remove the GA4 tag and its
_gacookie once satisfied — update your privacy policy accordinglyDocument the new metrics in your GDPR register: legal basis, retention period, server location
Traffic numbers will be consistently higher with Plausible or Umami than with GA4 on the same site: GA4 filters some bot traffic and handles short sessions differently. Expect +10% to +25% pageviews — this is not a bug, it is unsampled accuracy.
Advanced features: funnels, segments, events and API
Plausible 3.2 (January 2026) introduced editable multi-step funnels with revenue tracking. Segmentation relies on combined filters (source, country, device, event properties) with a new 'does not contain' filter added in 2026. The Plausible API is RESTful and documented. Umami 3.4 (August 2026) goes further with session segments — you can group visitors by session properties and replay their journey. Heatmaps and session replay, added in June 2026, enable visual behavior analysis. The TypeScript @umami/api-client SDK (generated from OpenAPI) simplifies data pipeline integration. Umami also supports session identity stitching: if a visitor returns on another device and authenticates, sessions are merged into a single profile.
Common troubleshooting
Frequent issues and solutions
- ClickHouse won't start (Plausible): check available RAM (
free -h) — ClickHouse needs at least 1.5 GB free at startup. If the VPS is tight, add a 2 GB swap file. Check logs withdocker compose logs clickhouse. - Umami migrations stuck: after an update, if the app refuses to start with
relation does not exist, force migrations manually viadocker compose exec umami node node_modules/.bin/db-migrate up. - Pageviews not recorded: verify your site's CSP header allows the analytics domain (
script-src 'self' https://analytics.yourdomain.com). Ad blockers may also block the script — consider proxying it from your own domain. - ClickHouse error after hard restart: if ClickHouse reports a corrupted table, run
SYSTEM RELOAD DICTIONARYviaclickhouse-clientthen restart the container. - Umami v3: errors after migrating from MySQL: Umami v3 dropped MySQL support. If upgrading from v2 with MySQL, export all data first, provision PostgreSQL, then reimport using the official migration scripts.
Backing up and restoring your analytics data
Backup strategy for Plausible and Umami
Plausible / ClickHouse: use
clickhouse-backup createor export critical tables to Parquet viaclickhouse-client --query "SELECT * FROM plausible_events_db.events FORMAT Parquet" > events_$(date +%Y%m%d).parquetUmami / PostgreSQL: a standard
pg_dumpis enough —docker compose exec db pg_dump -U umami umami > umami_$(date +%Y%m%d).sql. Schedule daily via cron and upload to object storage (S3, Backblaze B2)Test restoration at least quarterly on a staging VPS:
docker compose exec db psql -U umami umami < umami_backup.sqlFor Plausible, also back up the Docker volume holding the app's PostgreSQL data (separate from ClickHouse)
Document the restoration procedure in your runbook — an untested backup is not a backup
