If all you need is pageviews, referrers, and top pages, self-hosting Umami on a small VPS is genuinely cheap and stays cheap. If you need session replay, funnels, and feature flags, self-hosting PostHog is the most expensive "free" decision on this list. Plausible sits in between: pleasant to run, but it drags a ClickHouse instance along with it, and that's the part people underestimate.
I've run all three — Umami and Plausible self-hosted, PostHog on their cloud — on side projects and a small internal product. What follows is the decision I'd hand a colleague, including the failure mode that costs people a week before they notice.
What are you actually buying when you pay for analytics?
Not the dashboard. The dashboard is the easy part, which is why there are a dozen good open-source ones.
You're paying for storage and retention of an append-only event stream, an ingestion endpoint that survives your traffic spikes, and — the underrated one — somebody else owning the upgrade path of a columnar database you don't want to learn. Analytics data is write-heavy, immutable, and queried with wide aggregations, which is exactly the workload that makes people reach for ClickHouse and exactly the workload that makes a single Postgres box feel fine right up until it doesn't.
The honest framing: hosted analytics is a bet that your time is worth more than the subscription, and self-hosting is a bet that it isn't.
Plausible, Umami, PostHog: what is each one actually for?
| Umami | Plausible | PostHog | |
|---|---|---|---|
| Core job | Lightweight web analytics | Web analytics + goals/funnels | Product analytics suite |
| Data store (self-host) | Postgres or MySQL | Postgres and ClickHouse | ClickHouse, Kafka, Redis, Postgres |
| License (self-host) | MIT | AGPL (Community Edition) | MIT core, some features source-available |
| Session replay | No | No | Yes |
| Feature flags / experiments | No | No | Yes |
| Realistic self-host floor | One small VPS | One mid-size VPS | Not a small-VPS workload |
| Cloud pricing model (as of Sep 2026) | Event/site tiers, free tier | Pageview tiers | Usage-based per product, generous free tier |
The shape of that table is the whole decision. Umami answers "what pages do people read." Plausible answers that plus "did they do the thing I care about." PostHog answers "why did this cohort drop off at step three, and what happens if I flip this flag for 10% of them."
If you want the lightest possible self-hosted option that runs next to your app on the database you already operate, Umami is the one that doesn't add a second data store to your stack.
Drawbacks, because every tool gets one:
- Umami: the reporting is deliberately shallow. No funnel debugging worth the name, and once your events table gets large on Postgres you will be the one adding indexes and thinking about partitioning.
- Plausible: the Community Edition is intentionally behind the hosted product on some features, and self-hosting means you now operate ClickHouse — including its memory appetite and its own backup story.
- PostHog: enormous surface area, and as of mid-2026 their self-host guidance steers small teams toward the hobby Docker deployment rather than a supported production cluster. Session replay also makes your event volume — and your bill — grow in a way pageview counting never does.
Takeaway: pick the tool by which question you're going to ask at 11pm, not by which dashboard looks nicest in the screenshots.
Why does my analytics show fewer visits than my server logs?
This is the first real bug everyone hits, and it isn't a bug.
Client-side analytics scripts are blocked by content blockers, and the block rate skews hard by audience — a developer-tools site loses far more than a recipe blog. Your access logs count requests; your analytics counts successfully executed JavaScript. Those numbers will never match, and if they do match exactly, something is double-counting.
The partial fix is to serve the script and the event endpoint from your own domain so they aren't third-party requests. For Plausible on Next.js:
// next.config.js
module.exports = {
async rewrites() {
return [
{
source: '/stats/js/script.js',
destination: 'https://plausible.io/js/script.js',
},
{
source: '/stats/api/event',
destination: 'https://plausible.io/api/event',
},
];
},
};
<script
defer
data-domain="example.com"
data-api="/stats/api/event"
src="/stats/js/script.js"
></script>
The data-api attribute is the part people forget. Proxy the script but leave the event endpoint pointing at the vendor and you've solved nothing — the beacon is still the third-party request that gets blocked.
If you terminate TLS yourself, the Caddy equivalent:
example.com {
handle /stats/js/script.js {
rewrite * /js/script.js
reverse_proxy https://plausible.io {
header_up Host plausible.io
}
}
handle /stats/api/event {
rewrite * /api/event
reverse_proxy https://plausible.io {
header_up Host plausible.io
header_up X-Forwarded-For {remote_host}
}
}
reverse_proxy localhost:3000
}
Here's the failure mode that wastes the week. If you proxy the event endpoint without forwarding the real client IP, every visitor arrives from your proxy's address. Analytics tools that derive country and the daily visitor hash from the client IP will then report your entire audience as one country and collapse distinct visitors together. The dashboard doesn't error — it just quietly goes wrong, and it looks like a traffic change rather than a config change. If your geography chart flattens to a single row on the day you shipped a proxy, that's your bug, not your users.
The same rule applies when self-hosting behind nginx or a CDN: the analytics container must see a trustworthy X-Forwarded-For, and it must be configured to trust that header from your proxy only.
Takeaway: proxying analytics recovers blocked traffic, but it moves client IP handling into your infrastructure — and every downstream metric that depends on IP silently degrades if you get it wrong.
What does self-hosting actually cost?
Not the VPS. The VPS is the cheap part.
- Memory, not CPU. ClickHouse is happy to use whatever RAM you give it, and a Plausible or PostHog stack on an undersized box gets OOM-killed during ingestion bursts, not during queries. Budget for headroom you aren't using yet.
- Backups you've actually restored. An analytics database nobody backs up is a decision, just an unstated one. Restoring ClickHouse is not the same procedure as restoring Postgres, and the time to learn it is not the morning after.
- Upgrades. Minor version bumps are fine. The painful ones are the migrations that change the event schema; those arrive on the maintainer's schedule, not yours.
- Retention. Hosted plans often trim raw event retention on lower tiers. Self-hosting gives you unlimited retention and the corresponding unlimited disk growth — set a TTL on day one instead of discovering it at 90% full.
Rough rule from running these: a self-hosted analytics stack costs a few hours to stand up, then a few hours a year, until the day it breaks — and then it costs whatever your afternoon is worth, at the least convenient moment.
Takeaway: self-hosting analytics isn't free, it's prepaid in hours, and you pay in a currency you can't budget in advance.
When is the paid cloud tier worth it?
| Situation | What I'd do |
|---|---|
| Side project, pageviews only | Self-host Umami, one VPS, done |
| Client sites you bill for | Hosted tier — you're selling reliability, not operating it |
| Privacy/compliance is the reason you're here | Self-host Plausible CE, budget for ClickHouse |
| You need funnels, replay, and flags | PostHog Cloud, and cap your event volume early |
| Traffic is spiky and unpredictable | Hosted — burst ingestion is the hardest part to self-run |
The tipping point isn't traffic volume, it's whether losing a week of data would matter. Hobby projects can absorb a gap; anything you report to someone else can't.
If you want product analytics without operating a multi-service data pipeline, PostHog Cloud is the option that gives you funnels, replay, and feature flags behind one SDK — with the tradeoff that event volume, not user count, drives what you pay.
Takeaway: pay when the data becomes evidence someone else relies on.
FAQ
Is self-hosted Plausible free?
The Community Edition is free software under the AGPL, but running it requires both Postgres and ClickHouse, plus backups and upgrades you perform yourself. It's free of licensing cost, not free of operating cost.
Why does Google Analytics show different numbers than Plausible or Umami?
They count different things. GA4 models sessions and applies its own filtering and modeling; privacy-focused tools typically count a visitor via a daily rotating hash with no cross-day identity. Neither number is wrong — they answer different questions, so never compare them directly.
Can I self-host PostHog on a single small server?
You can run the hobby Docker deployment for evaluation, but as of mid-2026 PostHog directs production users to its cloud rather than supporting large self-hosted clusters. If you're choosing PostHog for its full feature set, plan on the hosted version.
Bottom line
Choose Umami if you want pageviews on infrastructure you already run, and accept shallow reporting in exchange. Choose Plausible when goals and conversions matter and you want a clean, privacy-respecting dashboard — self-host it if compliance demands it, otherwise let them operate the ClickHouse. Choose PostHog when your real question is about product behavior rather than traffic, and pay for the cloud tier instead of assembling the pipeline yourself. Whichever you pick, proxy the script through your own domain on day one and verify your geography chart afterward — that single check catches the most common silent misconfiguration in this entire category.
Top comments (0)