Self-Hosted Web Analytics: Plausible and Umami on a VPS in 2026
Last updated: July 2026
Cookie consent banners have become the tax every visitor pays to load a website, and Google Analytics is usually the reason the tax exists. A self-hosted analytics VPS running Plausible or Umami removes that tax entirely — no cross-site cookies, no consent-mode negotiation, no data shipped to a third-party ad platform. This guide covers what matters before deploying a self-hosted analytics VPS for Plausible or Umami in production: which stack fits which use case, how much VPS capacity is actually needed, and where storage growth quietly catches operators out.
Why site owners are dropping GA4 for self-hosted analytics
GA4 was never designed to be lightweight. It ships a tracking script that trips consent-management platforms, it retains identifiers long enough to fall under GDPR's stricter interpretations, and its UI buries the numbers most site owners actually check daily — visitors, referrers, top pages — behind a reporting model built for ad attribution, not for running a website. Plausible and Umami exist specifically to answer "how is my site doing" without any of that baggage: both are cookie-free by design in their default configuration, both store data on infrastructure the operator controls, and both render a dashboard that loads in under a second because it isn't computing multi-touch attribution models.
The tradeoff is that "self-hosted" means someone has to host it. That's the part this guide is actually about.
Plausible vs Umami: picking the right stack
Both tools solve the same problem with different storage engines, and that difference is the main thing that should drive VPS sizing.
| Factor | Plausible | Umami |
|---|---|---|
| Database | PostgreSQL + ClickHouse | PostgreSQL or MySQL |
| Resource footprint | Heavier — ClickHouse is fast but memory-hungry | Lighter — single relational database |
| Multi-site management | Strong built-in support | Strong built-in support |
| Setup complexity | Moderate (multi-container stack) | Simple (single app + one DB) |
For site owners tracking one or two low-to-medium traffic sites who want the smallest possible footprint, Umami's single-database design is the easier first deploy. For those tracking multiple properties and wanting richer funnel and goal reporting long-term, Plausible's ClickHouse backend scales better once traffic grows — it just asks more of the box from day one.
What kind of VPS actually runs this comfortably
Both stacks ship as Docker containers and run fine via Docker Compose on modest hardware — this isn't a workload that needs a dedicated server. What it needs is full root access to run containers cleanly, and NVMe storage, because both Postgres and ClickHouse are I/O-sensitive under write load. A VPS with slow spinning disk or throttled IOPS will bottleneck analytics ingestion long before CPU or RAM become the constraint, which is why disk type matters more here than it does for a typical web app; every X-Zone Servers VPS tier ships on NVMe by default, which removes that variable entirely.
X-Zone Servers' entry VPS tier — from EUR4/mo at 2GB RAM, 1 vCPU, and 40GB NVMe — runs either Plausible or Umami comfortably for a personal site or small portfolio of low-traffic properties, since every tier is built on NVMe and includes full root KVM access with native Docker support. For anyone tracking several sites, running Plausible's full ClickHouse stack, or expecting sustained traffic, stepping up to the Starter tier (8GB/2vCPU/120GB) gives real breathing room for both the database and the container overhead of a reverse proxy and TLS termination sitting in front of it.
General guidance for self-hosting workloads like this — where the operator owns the whole stack instead of renting a SaaS dashboard — is covered in X-Zone Servers' use case overview, which also walks through the container and root-access considerations that matter for a Docker-based deploy like this one.
Deploying with Docker Compose
Both Plausible and Umami publish official Docker Compose configurations, which is the fastest and most maintainable way to run either on a fresh VPS. The general shape is the same for both:
- Provision the VPS, point a domain's A record at it, and confirm root SSH access
- Install Docker and Docker Compose (a five-minute step on Ubuntu, Debian, or any of the standard distro images)
- Pull the official
docker-compose.ymlfrom the project's repository and set environment variables — database credentials, the site's base URL, and a secret key - Bring the stack up, then place a reverse proxy such as Caddy or Nginx in front of it for automatic TLS
- Drop the tracking snippet into the site and confirm the first pageview lands in the dashboard
Because everything runs in containers, upgrading later is a matter of pulling new images and recreating the stack — no manual dependency wrangling on the host itself. That containment is exactly why full root KVM access matters: it lets Docker manage the application layer without a shared-hosting control panel getting in the way.
Storage growth: what Postgres and ClickHouse actually consume
The most common mistake in self-hosted analytics isn't picking the wrong tool — it's under-provisioning storage for month six instead of week one. Analytics data is append-heavy by nature: every pageview is a row, and rows don't get automatically pruned. A few things to plan around:
- Umami's Postgres/MySQL table grows roughly linearly with pageview volume. A low-traffic site can run for years on the entry tier's 40GB; a busy site with several properties will want more headroom sooner.
- Plausible's ClickHouse store is efficient per-row thanks to columnar compression, but ClickHouse itself wants more RAM than Postgres alone to keep query performance snappy as the dataset grows — this is the main reason Plausible feels heavier than Umami at the same traffic level.
- Database backups (dumps, snapshots) roughly double the effective disk footprint if even one local copy is kept on the same volume, so budget for that separately from the live dataset.
The practical signal to watch is disk usage climbing steadily rather than plateauing — that's the cue to move up a tier before I/O contention starts showing up as dashboard lag. Moving from the entry 40GB tier to Basic (160GB) or Pro (200GB) is a straightforward vertical resize rather than a re-architecture, which is the advantage of staying on general-purpose KVM VPS infrastructure instead of a fixed-spec managed analytics box.
Latency and where to put the VPS
Analytics ingestion is write-heavy but not latency-critical for visitors — the tracking script fires asynchronously — so the main reason location matters here is dashboard responsiveness and where the underlying traffic actually originates. Running the analytics VPS in the same region as the primary audience keeps event ingestion snappy and keeps the admin dashboard responsive on daily checks. With deployment across 12 datacenter cities spanning Europe and the US — including Frankfurt and Amsterdam for European traffic, and Ashburn for North American audiences — there's usually a nearby option regardless of where the audience is concentrated.
Verdict
Self-hosted analytics is one of the cleanest wins in self-hosting: a small, predictable workload that removes a cookie banner, a third-party data-sharing relationship, and a recurring SaaS line item in one move. Umami is the simpler first deploy for a handful of low-traffic sites; Plausible earns its heavier footprint once multiple properties and deeper reporting are in play. Either way, the requirements are the same — full root access, Docker support, and NVMe storage that won't choke under database writes — and X-Zone Servers' KVM VPS lineup covers that from the EUR4/mo entry tier up through Business-grade specs as traffic and storage grow, with deploys live in under 60 seconds.