Self-hosting your analytics stack used to mean accepting trade-offs: either a bloated PHP application that needs a dedicated sysadmin, or a stripped-down tool that can barely tell you which pages your users are actually visiting. That gap has closed substantially. By 2026, there's a genuinely strong set of open-source analytics platforms that developers can run on their own infrastructure — each with different performance characteristics, licensing terms, and feature depth.
This breakdown covers the tools that are actually worth deploying, with specific technical details on stack requirements, resource sizing, and compliance posture — so you can match the platform to your workload instead of just picking whatever shows up first in a GitHub search.
Why self-host at all?
The motivations are well-documented but worth stating clearly. Data sovereignty is the biggest one: when analytics data lives in your own database, you're not subject to a vendor's data retention policy, subpoena response process, or unexpected pricing change. For teams handling user data under GDPR, CCPA, or sector-specific regulations, self-hosting can significantly simplify your DPA obligations — your analytics processor is your own infrastructure, not a third party.
There's also the compliance side-effect that many developers don't initially anticipate. Tools like Matomo using first-party cookies still need a consent banner in most EU jurisdictions. Cookieless alternatives running on your own server often don't. If you want to ditch cookie consent forms entirely, the tracking methodology matters as much as the hosting model.
Finally, cost at scale. Cloud analytics pricing is event-based, and at a few million pageviews per month, the bills get uncomfortable quickly. A $12/month VPS running Umami on PostgreSQL can handle the same load for a fraction of the cost.
The major platforms, compared honestly
Umami — the developer's default
Umami is probably the most-recommended self-hosted analytics tool in developer communities right now, and the reputation is earned. The tracking script comes in under 2KB — more than 20x smaller than GA4's ~45KB payload — with zero cookies and no fingerprinting. Deploying it takes a Docker Compose file and about 15 minutes.
The stack is Node.js + PostgreSQL, which most developers already know how to operate. v3, released in late 2025, improved the data collection pipeline and added more reliable session handling. The MIT license is permissive: you can fork it, modify it, embed it, or ship it as part of a commercial product without restriction.
Umami doesn't need a cookie consent banner because it collects no personally identifiable information. All visitor data is anonymized and aggregated. The GitHub project's maintainers have explicitly confirmed GDPR and CCPA compliance in public discussions, and the design of the system — no cross-site tracking, no persistent identifiers — backs that up structurally.
Resource requirements: A 1-2 vCPU VPS with 1-2GB RAM runs Umami comfortably for sites under ~1M pageviews/month. PostgreSQL is the only dependency, and it's well-understood at every scale.
What it lacks: No heatmaps, no session recording, no A/B testing, and no retention cohort analysis. If you need behavioral analytics beyond pageviews, events, and basic user journeys, you'll hit the ceiling quickly. You can explore how Umami compares to Databuddy if you need more depth alongside cookieless compliance.
Matomo — the feature-complete enterprise option
Matomo is the most feature-rich open-source analytics platform available. Heatmaps, session recordings, A/B testing, funnel analysis, e-commerce reporting, SEO metrics — it's essentially a full GA4 replacement. The European Commission uses it. If depth of reporting is the requirement, Matomo delivers.
The tradeoffs are real, though. The stack is PHP + MySQL/MariaDB, which means more moving parts and higher operational overhead compared to modern Node or Go-based tools. Matomo's own documentation recommends a minimum of 4 CPU cores and 8GB RAM for production deployments, though lower-traffic sites can run on a 2 vCPU / 2GB VPS. High-traffic installs need a dedicated database server and a Redis cache.
On the privacy side: Matomo uses cookies by default. You can configure it for cookieless operation, but the opt-in cookieless mode doesn't track the same data and requires additional configuration to comply cleanly with GDPR without a consent banner. Many advanced features (heatmaps, session recordings, A/B testing) are only available as paid premium plugins even when self-hosting — which catches some teams off guard after they've committed to the deployment.
Best fit: Regulated industries, agencies managing multiple client sites, or teams that genuinely need the full GA4 feature set and have an ops team to maintain it. For teams comparing infrastructure cost, see the detailed Matomo vs Databuddy breakdown.
Plausible CE — lightweight and privacy-native
Plausible Community Edition (CE) is the self-hosted version of Plausible Analytics, licensed under AGPL-3.0. It's cookieless, the tracking script is under 1KB, and the single-page dashboard is genuinely elegant — less intimidating than Matomo for non-technical stakeholders.
The backend runs on Elixir with ClickHouse handling the analytics data store. That's where the complexity lives. ClickHouse has substantial memory requirements: Railway's deployment documentation specifies a minimum of 1GB RAM just for ClickHouse, with 2-4GB recommended, plus additional resources for the Plausible app and PostgreSQL metadata store. On a 2GB VPS you're right at the edge; 4GB is the practical floor for comfortable operation.
The AGPL license also deserves attention. If you modify the source code and expose it to users over a network, the AGPL requires you to make those modifications available. For most self-hosting use cases this is irrelevant, but if you're building a commercial SaaS product on top of Plausible CE, you need to think through the licensing implications.
Note: Plausible's team has historically been somewhat ambiguous about the long-term trajectory of the CE (community edition) versus their cloud product. Community discussions on Elixir Forum in mid-2025 raised questions about CE's official support status. Worth verifying the current documentation before committing to a production deployment.
Best fit: Developer-led teams wanting a clean, fast dashboard with no cookies. Works well when you have the VPS headroom for ClickHouse and don't need heatmaps or session replay.
PostHog — if you need product analytics, not just web analytics
PostHog is a different beast from the other tools in this list. It combines product analytics, session replay, feature flags, A/B testing, error tracking, and user surveys in a single platform. It raised a $75M Series E in September 2025, and the company has surpassed 100,000 active deployments. Self-hosting is free under MIT license via Docker Compose.
The catch: PostHog's self-hosted stack is heavyweight. A Medium article from a developer who benchmarked self-hosted configurations noted that a minimum PostHog deployment needs 32GB RAM due to ClickHouse, Kafka for event ingestion, Postgres, and Redis all running together. That's not a VPS workload — it's a dedicated server or a Kubernetes cluster.
For teams with the infrastructure to support it, though, PostHog's value proposition is compelling. You get feature flag management with controlled rollouts, session recordings with console log capture, and direct integration between your feature experiments and behavioral analytics. If your analytics requirements go well beyond pageviews into full product instrumentation, check how PostHog stacks up against Databuddy for a clearer picture of the trade-offs.
Best fit: Product teams at well-funded startups or mid-size companies who need the full stack and have dedicated infrastructure. Not appropriate for lean VPS deployments.
GoatCounter — when simplicity is the priority
GoatCounter gets less press than the others, but it solves a specific problem well: it's a single compiled Go binary with SQLite or PostgreSQL as the datastore. No Docker Compose file with six services. No database migrations to manage. You download the binary, point it at a database, and it runs. The script is tiny, cookieless by default, and the dashboard is minimal.
It's free for non-commercial use; commercial users need to pay or self-host. For solo developers, open source projects, or internal tools where you just want page hit counts without any infrastructure overhead, GoatCounter is worth considering. It won't scale to enterprise workloads and lacks event tracking depth, but that's not what it's designed for.
Choosing based on your actual constraints
Here's a pragmatic decision framework:
| Constraint | Best fit |
|---|---|
| Minimal ops burden, modern stack | Umami |
| Full GA4 feature parity | Matomo |
| Clean UI, small VPS with 4GB+ RAM | Plausible CE |
| Product analytics + feature flags | PostHog |
| Single binary, minimal infrastructure | GoatCounter |
| Cloud-hosted privacy-first alternative | Databuddy |
The self-hosting vs. managed service question also deserves consideration. Self-hosting puts you in control, but it also puts you on the hook for backups, updates, scaling decisions, and uptime. A managed privacy-first platform like Databuddy provides cookieless, GDPR-compliant analytics — including real-time sessions, conversion funnel tracking, feature flags, and error tracking — without the operational overhead of running ClickHouse on your own VPS. The Databuddy vs Google Analytics comparison breaks down exactly what you gain on the privacy and performance side moving away from GA4.
The GDPR picture across all tools
Cookieless tracking is necessary but not sufficient for GDPR compliance. The full picture also includes where data is processed, who has access to it, and whether you have a valid DPA in place.
Self-hosted tools move all of that onto your own infrastructure — which is clean from a controller/processor perspective but means you're responsible for data security, retention limits, and subject access request handling. If you're operating in jurisdictions with strict data transfer requirements (Germany, France, Austria — where national DPAs have historically targeted US-based analytics infrastructure), self-hosting on a European VPS is the cleanest position.
For more detail on how these platforms compare under actual regulatory frameworks, the GDPR compliance guide for web analytics covers the key requirements across tool categories. The 7 privacy-first Google Analytics alternatives guide also provides a broader comparison that includes cloud-hosted options alongside self-hosted ones.
What developers actually care about: deployment experience
Beyond the feature matrix, the day-two experience matters. Some notes from practical deployments:
- Umami deploys with a single
docker compose upand runs on any VPS. Schema migrations are handled automatically. Updates require pulling a new image tag and restarting. - Matomo has a web-based installer but requires configuring a cron job for archiving reports — critical for sites over ~50K pageviews/month, and easy to miss in initial setup.
- Plausible CE requires configuring ClickHouse separately and tuning memory limits via
low-resources.xmlif you're on a small VPS. Theplausible-conf.envconfiguration is well-documented but has a long list of required environment variables. - PostHog ships a
docker-compose.ymlthat pulls 15+ services. The official docs recommend a minimum of 4 vCPUs and 8GB RAM, though community reports suggest significantly more is needed for stability in production.
For the developer-focused analytics workflow — where the goal is getting a lightweight, compliant tracking script deployed quickly and reliably — Umami and Plausible CE represent the practical sweet spot on the self-hosted side. PostHog and Matomo are the right call when you genuinely need the extra surface area, not just when you think you might need it someday.
Whatever you choose, the shift away from Google Analytics toward tools that don't require cookie banners or third-party data transfers is the right direction. The tooling in 2026 is mature enough that there's no good reason to keep sending pageview data to Mountain View.