
Should I self-host Plausible Analytics?
The SaaS and the self-host are the same software — the Community Edition removes the pageview cap and the invoice at once. Margin is thinner than it looks: ClickHouse wants real RAM.
The math (nothing hidden, including your time)
| Plausible Analytics (Starter) | $9.00/mo |
| VPS share + storage | −$2.50/mo |
| Your maintenance: 15 min/mo at $20/h | −$5.00/mo |
| Net saving | $1.50/mo |
| Setup: 40 min measured (one-time) | $13.33 |
| Break-even | 8.9 months |
| Markup Index (price ÷ real self-host cost) | 1.2× |
Price: source, checked 2026-08-05. Inputs are stored in git; every number above is derived, never hand-written.
What you lose
- Their infrastructure absorbing traffic spikes — a front-page day is now your ClickHouse's problem
- Funding the developers whose code you're running (their pricing page will tell you the same, correctly)
- Managed email reports and uptime — small, but it's on your pager now
What you're paying Plausible Analytics for
- privacy-friendly web analytics
- goals & custom events
- no pageview caps
- email/Slack reports

Ranked alternatives
The same privacy-first analytics dashboard the vendor sells, on your own domain, with no pageview meter counting against you.
Pageviews, referrers and custom events on a hostname you own, from one container and a PostgreSQL, with no monthly event meter.
Hardware
Runs comfortably on a real VPS (2 GB+).
The tested compose file (our evidence, CI-booted)
# Plausible Community Edition — the rare case where the SaaS and the self-host are the
# same software. Secrets are throwaway test values: openssl rand -base64 48
services:
plausible:
image: ghcr.io/plausible/community-edition:v3
container_name: plausible
restart: unless-stopped
command: sh -c "/entrypoint.sh db createdb && /entrypoint.sh db migrate && /entrypoint.sh run"
depends_on:
plausible-db:
condition: service_healthy
plausible-events-db:
condition: service_healthy
environment:
BASE_URL: http://localhost:8000
SECRET_KEY_BASE: "GLVzDZW04FzuS1gMcmBRVhwgd4Gu9YmSl/k/TqfTUXti7FLBd7aflXeQDdwCj6Cz"
DATABASE_URL: postgres://plausible:plausible@plausible-db:5432/plausible_db
CLICKHOUSE_DATABASE_URL: http://plausible-events-db:8123/plausible_events_db
DISABLE_REGISTRATION: "false"
ports:
- "8000:8000"
healthcheck:
test: ["CMD-SHELL", "wget -qO- http://localhost:8000/api/health || exit 1"]
interval: 5s
timeout: 5s
retries: 36
start_period: 30s
plausible-db:
image: postgres:16-alpine
restart: unless-stopped
environment:
POSTGRES_USER: plausible
POSTGRES_PASSWORD: plausible
POSTGRES_DB: plausible_db
volumes:
- plausible-pg:/var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -U plausible"]
interval: 5s
timeout: 5s
retries: 12
plausible-events-db:
image: clickhouse/clickhouse-server:24.12-alpine
restart: unless-stopped
volumes:
- plausible-ch:/var/lib/clickhouse
ulimits:
nofile:
soft: 262144
hard: 262144
healthcheck:
test: ["CMD-SHELL", "wget -qO- http://localhost:8123/ping || exit 1"]
interval: 5s
timeout: 5s
retries: 24
start_period: 20s
volumes:
plausible-pg:
plausible-ch:
Want a guided install instead? caniselfhostit.com/plausible has AI-agent prompts that assume a bare machine — that's their half of the stool, and it's good.
Verification
Protocol v1 · verified by zernonia on 2026-08-10 · setup measured at 40 min · AI assistant: claude-code (allowed & stated)
What broke
- CE images live on ghcr.io, not Docker Hub — networks that only mirror Docker Hub (ours, during verification) can't pull them; the compose boot for this pair is verified by the CI runner instead
- First boot must run createdb + migrate before serve — the compose command handles it, but a bare `run` exits confusingly
Full timed log
# Timed setup log: Plausible (cloud) → Plausible Community Edition **Protocol:** v1 · **Verified by:** zernonia · **Date:** 2026-08-10 **Assistant:** claude-code · **Environment:** containerized runner, 2 vCPU class, Docker 29.3 / Compose v5.1 ## Timeline | Step | Time | |---|---| | Read CE hosting docs, draft compose (app + postgres + clickhouse, secret, createdb/migrate entry) | 25 min | | Boot attempt in our verification environment: **blocked — ghcr.io unreachable** (see What broke) | 5 min | | Compose boot + health verified by the CI runner instead (`compose-check` workflow) | — | | Workflow review against CE docs: registration, site creation, script snippet | 10 min | | **Total: ~40 min** | | ## Measurements - Verification environment could not pull ghcr.io images; **boot-to-healthy for this pair is certified by CI**, which runs the same `scripts/check-compose.sh` gate on every change and weekly on schedule. Treat the CI badge, not this log, as the boot evidence. - 3 containers; ClickHouse is the heavy one — plan ~1 GB RAM for it alone. This drives the `vps` hardware tier and the honest `vps_share` in the math. ## What broke 1. **CE images live on ghcr.io only.** Networks that mirror just Docker Hub (some CI setups, corporate proxies — and our own verification box today) can't pull them. Nothing wrong with the software; worth knowing before you assume any registry works from your box. 2. **First boot must run `db createdb && db migrate` before `run`** — the compose's `command` handles it; a bare `run` on a fresh volume exits with a confusing DB error. ## Verdict-relevant notes - Same software as the SaaS: capability is 100% by construction, minus their managed spikes. - The YES survives the math but barely — ClickHouse's RAM appetite makes this the thinnest YES margin on the site. Their $9/mo is honestly priced; self-host for the caps and the ownership, not to get rich.
Verdict history
- 2026-08-10: unscored → YES — Initial verdict: same software, no pageview cap; margin thinner than it looks (ClickHouse eats RAM).
