Google Analytics is powerful. It’s also heavy, increasingly blocked, and often at odds with privacy-first policies.
If you want clean traffic numbers without turning analytics into a compliance project, self-host Plausible Analytics on your own VPS. You keep the data, set retention on your terms, and stop shipping user activity to somebody else’s infrastructure.
This is an open-source spotlight, not a “become a data engineer” bootcamp. The goal is simple: run Plausible on real infrastructure.
That means a VPS, proper HTTPS, sensible backups, and a maintenance routine you’ll actually follow.
Why self-host Plausible Analytics instead of Google Analytics
Plausible focuses on the metrics most teams use day to day: pageviews, referrers, top pages, and device breakdowns. It’s open-source (AGPL-3.0) and built to run without a dedicated analytics team.
Compared to Google Analytics, three differences show up quickly:
- Less script overhead: Plausible’s tracking script is small. It often loads faster than suites that pull in multiple tags and integrations.
- A simpler operational story: Your data lives in your own databases. You decide backups, encryption at rest, and retention.
- Fewer “mystery gaps”: Many teams see GA requests blocked by privacy tools and network filtering. Self-hosting won’t defeat ad blockers. It can, however, avoid third-party request blocks aimed at well-known analytics domains.
If you run client sites, the trust angle matters. You can tell clients exactly where analytics data is stored and who can access it.
You’re not asking them to rely on a third-party policy page.
Self-host Plausible Analytics: who it’s for (and who should skip it)
Self-host Plausible Analytics fits best if you already operate at least one server. It also helps if you’re comfortable owning basic maintenance.
You’ll get the most value if:
- You want privacy-friendly analytics served under your own domain.
- You’re tired of dashboards that take a training session just to answer “where did this traffic come from?”
- You manage multiple sites and want one place to see them.
- You want predictable costs that aren’t tied to event volume.
Skip self-hosting if you know you won’t keep up with updates, backups, and basic incident response. In that case, Plausible’s hosted offering (or another managed environment) is usually the smarter move.
A quick comparison: Plausible vs hosted/proprietary analytics
Here’s the trade-off, without hand-waving.
- Plausible (self-hosted): Your VPS, your databases, your backups. Less vendor dependency. You own operations.
- Plausible (hosted): Same product feel, minimal ops. You pay to outsource uptime and maintenance.
- Google Analytics: Feature-rich and tied closely to ad products. Data is processed offsite. For many teams, it also brings more complexity and more compliance work.
If you need heavier reporting and a larger feature surface, Matomo is the usual open-source comparison.
Plausible’s edge is that it stays small. That means fewer moving parts and a dashboard you can explain in two minutes.
What you’ll run on your VPS (architecture in one minute)
A typical Plausible self-hosted setup includes:
- The Plausible web app
- A PostgreSQL database (for core app data)
- A ClickHouse database (for analytics event storage and fast queries)
- A reverse proxy (commonly Nginx) to terminate HTTPS and route traffic
Docker Compose keeps the stack contained. You get one directory, one compose file, and persistent volumes for the databases.
For most VPS deployments, that’s the sweet spot.
Resource requirements and sizing (what actually matters)
Plausible runs fine on a modest VPS. Database performance matters more than raw CPU.
Slow disks and tight memory hit ClickHouse first. You’ll usually notice it in the dashboard.
- Small sites (up to a few hundred thousand pageviews/month): 2 vCPU, 2–4 GB RAM, 40+ GB NVMe storage.
- Multiple sites / higher traffic: 4 vCPU, 8 GB RAM, 80+ GB NVMe storage.
- Very high traffic: Consider separating databases onto a dedicated server or a larger VPS class with more RAM and faster storage.
If the VPS already hosts your app (WordPress, APIs, workers), don’t squeeze analytics into the leftover 1 GB. It may look “fine” until a traffic spike arrives.
That’s usually when you need the data most.
For a clean foundation, a HostMyCode VPS is a practical fit: predictable resources, full root access, and enough headroom to keep the databases responsive.
Deploy Plausible with Docker Compose on Ubuntu or Debian
This section shows the production shape you’ll use. You’ll adjust details for your environment.
The core parts stay the same.
Baseline assumptions: Ubuntu or Debian VPS, a domain or subdomain (for example, analytics.example.com), and Docker + Docker Compose installed.
If you’re still tightening server basics, add these to your setup checklist:
- Set Up UFW Firewall on Ubuntu for a Web Server
- VPS Reverse Proxy Setup Tutorial (2026): Nginx Front-End for Multiple Sites, SSL, and Real IP Logging
Directory layout
Keep Plausible isolated. A simple pattern:
sudo mkdir -p /opt/plausible
sudo chown -R $USER:$USER /opt/plausible
cd /opt/plausibleDocker Compose (what to copy, what to edit)
Plausible publishes an official self-hosting setup using Docker Compose. Start with the upstream compose file.
Then tailor environment variables and volumes so your backup plan is clear and repeatable.
Decide these before you deploy:
- Base URL: the public URL users will visit (e.g.
https://analytics.example.com) - Secrets: long, random values stored outside shell history (use a password manager)
- SMTP: Plausible needs outbound email for invites, password resets, and notifications
Two choices prevent most “why is this weird?” incidents later:
- Pin volumes deliberately: you want persistent storage for PostgreSQL and ClickHouse, not anonymous volumes you lose track of.
- Don’t expose databases to the internet: keep them on the Docker network only. The reverse proxy should be the only public entry point.
Bring the stack up
Once your compose file and .env are in place:
docker compose pull
docker compose up -dDo a quick health check:
docker compose ps
docker compose logs --tail=100 plausibleIf the app starts but sign-in or invites don’t work, it’s usually SMTP. A mismatched BASE_URL is the other common cause.
Reverse proxy + HTTPS (Nginx + Let’s Encrypt)
Put Plausible behind a reverse proxy, even if it’s the only service on the VPS. You get consistent logging and tighter TLS control.
You also get a cleaner path to hosting more services later.
If you already use Nginx as a front-end, create a server block such as:
# /etc/nginx/sites-available/analytics.example.com
server {
listen 80;
server_name analytics.example.com;
location / {
proxy_pass http://127.0.0.1:8000; # or the container-bound port you expose
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}Then enable it and reload:
sudo ln -s /etc/nginx/sites-available/analytics.example.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginxFor TLS, use Certbot (or your preferred ACME client). HostMyCode has a detailed 2026 walkthrough you can follow end-to-end:
One detail operators miss: only set a long HSTS policy after you’ve confirmed renewals work.
A failed renewal plus strict HSTS creates an outage you didn’t need to have.
Data retention, backups, and restore reality
Self-hosting only makes sense if you can restore. With Plausible, you’re protecting two datastores: PostgreSQL and ClickHouse.
Back them up as separate jobs, even if you store the archives in the same place.
A workable approach on a single VPS:
- Nightly logical dumps for PostgreSQL (
pg_dump) and ClickHouse (native backup method or export approach you standardize). - Offsite copies to object storage or another server.
- Retention that matches your business needs (common: 7 daily + 4 weekly + 6 monthly).
Keep backups out of /opt/plausible. Keep them off the root filesystem if you can.
A full disk is an easy way to corrupt databases and stall containers.
If Docker storage has already burned you, this HostMyCode guide shows how to clean up safely:
Backup commands you can actually schedule
Example PostgreSQL dump (adjust container/service names):
# create a backup directory
sudo mkdir -p /var/backups/plausible
sudo chown -R $USER:$USER /var/backups/plausible
# postgres dump
docker compose exec -T postgres pg_dump -U postgres plausible_db \
| gzip > /var/backups/plausible/plausible-postgres-$(date +%F).sql.gzClickHouse backups vary by deployment and version. What matters is repeatability.
Choose one method, document it, and test restores.
If your ClickHouse data is truly mission-critical, consider filesystem-level snapshots (LVM/ZFS) plus offsite replication.
Schedule backups with cron or systemd timers. If you prefer timers (better logs, more predictable behavior), use this guide:
Test restores (or you don’t have backups)
Once a month, run a restore drill to a throwaway VM/VPS. Time the process and write the steps down.
If you manage client analytics, treat restore drills as part of your operating checklist.
For a structured way to make restore testing routine, keep this handy:
Updating Plausible safely (without breaking your dashboard)
Docker makes updates straightforward. You still want a habit you can repeat.
For most operators:
- Take backups (or confirm last night’s backups succeeded).
- Pull new images.
- Restart with Compose.
- Check logs and do a quick UI smoke test.
cd /opt/plausible
./your-backup-script.sh
docker compose pull
docker compose up -d
docker compose logs --tail=100 plausibleAvoid “latest” tag roulette if you run this for clients. Pin images to known-good tags when you can.
Upgrade during a maintenance window.
Operational hardening that pays off quickly
Plausible isn’t difficult to run. It still benefits from basic server hygiene.
- Firewall: allow only SSH (ideally restricted) and web ports 80/443. Keep everything else private.
- SSH: disable password logins, use keys, and consider a jump host if this VPS is internet-facing.
- Rate limiting: if your analytics endpoint gets hammered, your databases will feel it first.
If you already use Nginx as a reverse proxy, basic rate limiting helps. It keeps noisy bots from turning into a resource incident.
This guide stays practical and production-focused:
Common pitfalls (things that look like “Plausible is broken”)
- Wrong BASE_URL: results in bad redirects, broken login links, or cookie issues behind HTTPS.
- SMTP not working: invites and password resets fail until you check logs.
- Disk pressure: ClickHouse will punish slow disks and full filesystems. Watch free space and I/O wait.
- Proxy headers missing: the app may think requests are HTTP, not HTTPS, and generate incorrect links.
If you think the VPS is running out of headroom, don’t guess. Measure CPU steal, RAM pressure, and disk I/O.
This troubleshooting guide walks you through the signals that matter:
Where Plausible fits in a real hosting stack
For many site owners, the cleanest split is simple: your app on one VPS, analytics on another. That separation keeps analytics writes from competing with page rendering.
It also limits blast radius if one service is compromised.
If you manage a portfolio of sites, a dedicated Plausible VPS makes onboarding easier. You get one domain, one dashboard, and clean boundaries.
If you outgrow the box later, you can migrate the analytics host without touching production websites.
If you don’t want to deal with OS patching and monitoring, that’s a solid reason to choose managed VPS hosting and stay focused on the application layer.
Summary: self-hosting that stays boring
Plausible is a strong self-hosted option because the stack stays understandable. Docker Compose keeps the pieces contained.
Nginx gives you a standard HTTPS edge. Routine backups keep the setup honest.
For stable performance, size your VPS for ClickHouse memory needs and sustained disk writes.
A right-sized HostMyCode VPS will handle Plausible cleanly for most small-to-mid deployments, with room to scale as traffic grows.
If you’re planning to self-host Plausible, run it on infrastructure that won’t bottleneck on disk I/O, networking, or tight resource limits. Start with a HostMyCode VPS for full control, or choose managed VPS hosting if you’d rather outsource patching and baseline hardening while you focus on your sites.
FAQ
Do I need a separate VPS to self-host Plausible Analytics?
No, but it’s often a good idea. If you already run busy sites on the same server, analytics databases will compete for RAM and disk I/O.
Separate hosts keep performance more predictable.
Can I put Plausible behind an existing Nginx reverse proxy?
Yes. It’s a common setup. Make sure the proxy sets X-Forwarded-Proto and related headers so Plausible generates correct HTTPS URLs.
What should I back up for Plausible?
At minimum: PostgreSQL and ClickHouse data, plus your .env (secrets) and the Compose file. Store backups offsite, and run restore tests.
How do I update Plausible without downtime?
Most upgrades are a docker compose pull + docker compose up -d cycle. Do it during a low-traffic window, and take fresh backups first.
Will ad blockers block Plausible?
Sometimes. Self-hosting under your own subdomain helps, but it won’t bypass every blocking rule.
The upside is that you avoid third-party analytics calls that are commonly blocked by default.