Self-Hosting Plausible: What It Costs and What It Takes
Self-hosting Plausible means running Plausible Community Edition v3.2.1 as three Docker containers: the Elixir app, PostgreSQL, and ClickHouse. There is no fourth. You clone the plausible/community-edition repo at a version tag, set two environment variables, and run docker compose up -d. The install is not the hard part. The question worth an hour of your time is whether it saves you any money, and below 100,000 pageviews a month on a single site, it does not.
Every price, version and requirement on this page was fetched live on 2026-09-09 from Plausible's own repo, wiki and pricing page, and from Liquid Web's plan pages. Sources are linked inline.
What changed since the last version of this guide
This page previously documented a hand-written Docker Compose file pinned to Plausible v2.1.4. Four things about it were wrong. The second row is the one that cost readers money, and it was our error, not a vendor change.
| Was | Now | Verified |
|---|---|---|
| Latest release v2.1.4, dated 2026-04-08 | v2.1.4 actually shipped 2024-10-09. Current release is v3.2.1, shipped 2026-05-15 | GitHub releases |
| Self-hosted "~$14/mo VPS" alongside a link to Liquid Web's Managed VPS | Managed 4 GB is $72/mo list. The ~$14 figure only resembles the Self-Managed 4 GB tier, a different product at $17/mo list | liquidweb.com |
A forked compose.yml with a Caddy service | Upstream ships its own compose.yml; a reverse proxy has been unnecessary since v2.1.2 | CE wiki |
CLICKHOUSE_MAX_SERVER_MEMORY_USAGE env var as the small-VPS fix | Upstream now ships four ClickHouse XML config files that do this properly | compose.yml |
The v2 to v3 jump renamed services. db became plausible_db, clickhouse became plausible_events_db, ClickHouse moved from 24.3 to 24.12, and the app gained a plausible-data volume plus a TMPDIR. Any compose file copied from a 2024-era guide will not merge cleanly with v3.
On the security question, precisely. v3.2.1 is a security patch: it removes an exposed /storybook endpoint that allowed remote code execution (CVE-2026-8467 / GHSA-55hg-8qxv-qj4p). The advisory's affected list is v3.0.0 through v3.2.0. v2.1.4 is not on that list. But Plausible's own upgrade wiki states that "security patches and bug fixes are not backported," so sitting on a two-year-old 2.x tag is still the wrong place to be. Move to v3.2.1.
Is self-hosting Plausible actually cheaper than Plausible Cloud?
Below about 100k pageviews a month on a single site, no. Plausible Cloud's Starter plan is $9/mo subject to change · verified 2026-09-09 at 10k pageviews. The cheapest Liquid Web tier that runs ClickHouse comfortably is $17/mo subject to change · verified 2026-09-09, and that price buys you the hardware only. You still patch the OS and own the backups.
Here is the arithmetic in 2026. Plausible Cloud prices are per month, taken from the pricing slider on plausible.io, fetched 2026-09-09. Annual billing is two months free.
| Pageviews/mo | Starter (1 site) | Growth (3 sites) | Business (10 sites) |
|---|---|---|---|
| 10k | $9 | $14 | $19 |
| 100k | $19 | $29 | $39 |
| 200k | $29 | $44 | $59 |
| 500k | $49 | $74 | $99 |
| 1M | $69 | $104 | $139 |
| 10M | $169 | $254 | $339 |
Against those, two Liquid Web 4 GB tiers, both 2 vCPU / 80 GB SSD / 3 TB transfer, verified 2026-09-09:
| Tier | List | First 2 months | Who patches the OS |
|---|---|---|---|
| Self-Managed VPS 4 GB | $17/mo | $8.50/mo | You |
| Managed VPS 4 GB | $72/mo | $36/mo | Liquid Web |
The crossovers, on the self-managed tier at $17/mo:
- One site, under 100k pageviews. Cloud Starter is $9. Self-hosting costs more and adds work. Use Cloud.
- One site, 100k+ pageviews. Starter is $19 and climbing. Self-hosting is flat at $17. Self-hosting wins from here up, until you outgrow the hardware.
- Three or more sites, any volume. Self-hosted Plausible has no per-site cost. Growth starts at $14 for three sites and Business at $19 for ten. Self-hosting is level with Business at 10k pageviews and pulls ahead immediately after.
- You want the managed tier at $72/mo. It only beats Business past 200k pageviews, and only beats Starter somewhere between 1M and 2M. Buy it for the support relationship, not to save money on analytics.
What this table cannot price is your time. ClickHouse major upgrades, PostgreSQL major upgrades, disk growth and TLS renewals are yours now. If half an hour a month of that is worth more than $10 to you, Cloud is the better deal at every volume in the table, and Plausible funds Community Edition out of those subscriptions.
What do you actually deploy?
Do not write your own compose file. Plausible CE ships one, along with the four ClickHouse config files that make it fit on a small server, and the documented upgrade path is git pull against that repo. A fork conflicts on every upgrade.
The full install, from Plausible CE's own README at the v3.2.1 tag:
# 1. Clone the repo at a pinned version tag
git clone -b v3.2.1 --single-branch \
https://github.com/plausible/community-edition plausible-ce
cd plausible-ce
# 2. Two required environment variables
touch .env
echo "BASE_URL=https://plausible.yourdomain.com" >> .env
echo "SECRET_KEY_BASE=$(openssl rand -base64 48)" >> .env
# 3. Let Plausible terminate TLS itself
echo "HTTP_PORT=80" >> .env
echo "HTTPS_PORT=443" >> .env
cat > compose.override.yml << 'EOF'
services:
plausible:
ports:
- 80:80
- 443:443
EOF
# 4. Start
docker compose up -d
# 5. Visit https://plausible.yourdomain.com and create the first user
BASE_URL must be the real domain with a DNS A record already pointing at the server, because Let's Encrypt issuance depends on it. SECRET_KEY_BASE must be at least 64 bytes.
Everything else you want to change goes in compose.override.yml, never in compose.yml. Docker Compose merges the two with the override taking precedence, and the override file is untracked, so upgrades stay clean. That is upstream's documented recommendation, and it is the single biggest difference between a Plausible instance that upgrades in 30 seconds and one you dread touching.
Prerequisites
- A VPS with at least 4 GB RAM. Plausible's README recommends "at least 2 GB," but our own measurement of the v2.1.4 stack came in at 1.8 GB idle, which leaves nothing on a 2 GB box. Buy 4 GB.
- A CPU supporting SSE 4.2 or NEON, a hard ClickHouse requirement stated in the README. Check with
grep -c sse4_2 /proc/cpuinfobefore you pay for anything. - Docker Engine and Docker Compose V2.
- A domain with an A record pointing at the server.
Do you still need Caddy or Nginx?
No. Plausible CE has issued and renewed its own Let's Encrypt certificates since v2.1.2, and the CE wiki says plainly that "a reverse proxy is no longer necessary." Setting HTTP_PORT=80 and HTTPS_PORT=443 is the whole configuration.
Add a proxy only if you have a reason: you are terminating TLS for several apps on one box, or you already run Caddy. In that case set HTTP_PORT=8000, expose 127.0.0.1:8000 in your override file, and point the proxy at it. The wiki notes that its Nginx and Apache examples are community contributions the maintainers have not tested. Its Caddy example is four lines.
Why does ClickHouse dominate the memory footprint?
Plausible stores events in ClickHouse, a column-store built for analytical aggregation. That is why the dashboard is fast on millions of rows and why the memory floor is high: ClickHouse allocates caches and parallel-parsing buffers sized for servers, not for a 4 GB VPS.
Upstream's answer ships in the repo. clickhouse/low-resources.xml caps mark_cache_size at 500 MB, and default-profile-low-resources-overrides.xml sets max_threads to 1, max_block_size to 8192, and turns off parallel parsing and formatting. Both files cite ClickHouse's own guidance for using less than 16 GB of RAM. Two more files quiet the logs and force IPv4 binding. Mount all four, which the official compose file already does.
Our measurement of the older stack, for scale:
| Service | Idle RAM | Peak RAM (500 events/min) |
|---|---|---|
| plausible (Elixir) | 350 MB | 600 MB |
| clickhouse | 1,200 MB | 1,550 MB |
| db (postgres 16) | 210 MB | 280 MB |
| caddy | 15 MB | 20 MB |
| Total | 1,775 MB | 2,450 MB |
Measured 2026-05-02 on local Docker (4 vCPU / 8 GB RAM) running Plausible v2.1.4, PostgreSQL 16, ClickHouse 24.3 and Caddy, across three sites. We have not re-run this on v3.2.1, which ships ClickHouse 24.12 and drops the Caddy container. Read it as the order of magnitude, not as a v3 benchmark: ClickHouse is roughly two thirds of your RAM, and that is what pushes the practical minimum to 4 GB.
How do you add tracking and custom events?
After adding a site in the dashboard, copy the snippet from its settings:
<script defer data-domain="yourdomain.com"
src="https://plausible.yourdomain.com/js/script.js"></script>
The script is 2,841 bytes raw and 1,290 bytes gzipped, measured against plausible.io/js/script.js on 2026-09-09. Plausible's marketing calls it "lightweight," and it is, but the "under 1 KB" figure that circulates in older write-ups no longer matches the file on disk.
For WordPress, the official Plausible plugin injects it. For Docusaurus, Next.js or React, put it in your head component. Custom events go through the global:
window.plausible('Signup', { props: { method: 'email' } });
window.plausible('Purchase', {
props: { plan: 'pro', revenue: { currency: 'USD', amount: 49 } },
});
How do you upgrade without breaking the database?
Because you cloned the repo instead of forking the compose file, an upgrade is a fetch and a restart:
cd plausible-ce
git fetch --tags
git checkout v3.2.1 # or whatever the current tag is
docker compose pull
docker compose up -d
docker compose logs plausible -f --tail 20 # watch migrations finish
Migrations run automatically from the container's start command. Read the release notes before every jump: Plausible follows Intended Effort Versioning, so a major bump signals that upgrading will take effort, not that features were removed. Major PostgreSQL upgrades have their own wiki page and are not automatic. Snapshot the volumes first.
When should you not self-host Plausible?
- You run one site under 100k pageviews. Cloud Starter at $9/mo is cheaper than any VPS that runs ClickHouse, and it comes with a 30-day trial and no credit card. Self-hosting here buys you data residency and nothing else.
- You need session replay or heatmaps. Plausible aggregates by design and cannot reconstruct an individual session. PostHog self-hosted has replay, heatmaps, feature flags and experiments, but PostHog's own docs call self-hosted deployments "officially unsupported," size them at "something equivalent to a Hetzner VM with 4 vCPU, 16GB RAM, and more than 30GB storage," and keep all paid-plan features Cloud-only. That is 16 GB, not the 32 GB an earlier version of this page claimed. If you only want replay and heatmaps and do not need to own the data, Microsoft Clarity advertises itself as "free forever" with "no limits on traffic" (fetched 2026-09-09). It is cloud-only and it is Microsoft's, and for a lot of people that trade is fine.
- You need user-level funnels or retention cohorts. Plausible deliberately does not track individuals. If your analysis needs a user ID, PostHog or Mixpanel is the right tool and Plausible never will be.
- Your box is under 4 GB, or its CPU lacks SSE 4.2. ClickHouse settles both questions for you. Use Umami instead: PostgreSQL only, no column store, and it fits where Plausible cannot.
- You are picking a tool, not installing one. Start from the self-hosted analytics comparison rather than here.
How do you get your data back out?
Decide this before you migrate in, not after.
# CSV export of stats: dashboard → Site Settings → Imports & Exports
# Site list via the API
curl -H "Authorization: Bearer YOUR_API_KEY" \
https://plausible.yourdomain.com/api/v1/sites > sites.json
# PostgreSQL: accounts, sites, goals, settings
# Database is named plausible_db, not plausible — DATABASE_URL defaults to
# postgres://postgres:postgres@plausible_db:5432/plausible_db
docker compose exec plausible_db \
sh -c "pg_dump -U postgres plausible_db > /tmp/plausible_db.bak"
docker compose cp plausible_db:/tmp/plausible_db.bak plausible_db.bak
# ClickHouse: the events themselves
docker compose exec plausible_events_db \
clickhouse-client --query "SELECT * FROM plausible_events_db.events_v2 FORMAT CSV" \
> events.csv
Two service names changed in v3.x and the commands above use the new ones. The ClickHouse export is the one people forget: your PostgreSQL dump holds configuration, not a single pageview.
Not for Plausible itself. Plausible's data policy states that it does not use cookies, does not generate persistent identifiers, and that 'raw IP addresses and User-Agent data are never stored' — all data is aggregated. Plausible's own conclusion is that 'by using Plausible, you do not need cookie banners for analytics or to collect consent for tracking.' That is the vendor's position, and it is a well-argued one, but your own legal review is what governs. Anything else on your site that does set cookies still needs its banner. This is not legal advice.
No. The advisory for CVE-2026-8467 / GHSA-55hg-8qxv-qj4p lists v3.0.0 through v3.2.0 as affected, and v2.x is not on that list. The vulnerability was an exposed /storybook endpoint allowing remote code execution, removed in v3.2.1 on 2026-05-15. You should still upgrade: Plausible's upgrade wiki states that security patches and bug fixes are not backported to older majors, so a 2.x instance simply stops receiving fixes rather than being provably safe.
As many as the hardware supports. Community Edition has no per-site or per-pageview limit, which is where self-hosting beats Cloud on cost: Plausible Cloud caps sites by plan (1 on Starter, 3 on Growth, 10 on Business, verified on plausible.io 2026-09-09). Each site gets its own snippet with a different data-domain value and its own dashboard. The real ceiling is ClickHouse's appetite for RAM as event volume grows.
GA4 only. Plausible's documentation covers importing from Google Analytics 4 and no longer covers Universal Analytics. Go to Site Settings, then Imports & Exports, then Import Data. You can import up to 5 GA properties into one dashboard, and data is imported in aggregate per day, from your first GA visitor up to your first Plausible visitor, so nothing double-counts. UTM sources, exit pages, scroll depth and goal conversions do not come across, and Plausible warns to expect discrepancies because the two tools count sessions differently.
Yes, and since v2.1.2 you do not need Cloudflare or any other proxy in front of it for TLS. The friction is on the tracking side rather than the hosting side: the script URL is a well-known pattern that ad blockers and Cloudflare's Rocket Loader can interfere with. Plausible supports proxying the script through your own domain, which is the standard fix and is documented in their script-proxy guide.
Common mistakes and fixes
ClickHouse exits immediately with 'Cannot allocate memory', or the container restart-loops on first boot.
Check that you are running the official `compose.yml` from the v3.2.1 tag and that the four files in `clickhouse/` are mounted. Plausible CE ships `low-resources.xml` (caps ClickHouse's mark cache at 500 MB) and `default-profile-low-resources-overrides.xml` (sets `max_threads` to 1 and disables parallel parsing) specifically so ClickHouse fits on a small VPS. If you forked `compose.yml` from an older guide, those mounts are almost certainly missing. Do not hand-set `CLICKHOUSE_MAX_SERVER_MEMORY_USAGE` instead: that was a workaround people used before upstream shipped these config files, and it does not apply the thread and block-size limits that actually keep ClickHouse small.
ClickHouse will not start at all and logs an illegal-instruction error.
Plausible CE's README states the CPU must support the SSE 4.2 or NEON instruction set, which ClickHouse requires. This bites on some older or heavily oversubscribed budget VPS instances. Run `grep -o 'sse4_2' /proc/cpuinfo | head -1` before you buy; an empty result means ClickHouse cannot run on that host and no amount of RAM will fix it.
Pageviews are not appearing in the dashboard after adding the script.
Three things to check: (1) The tracking script `<script defer data-domain='yourdomain.com' src='https://plausible.yourdomain.com/js/script.js'></script>` must be in the `<head>` of every page, with `data-domain` matching the site domain you added in Plausible. (2) Ad blockers block Plausible's tracking script, so test in a browser with no extensions. (3) Plausible excludes your own visits if you added your IP to the exclusion list or have the Plausible browser extension installed.
Plausible shows 'Error 500' on the login page after an upgrade.
This usually means a database migration did not complete. Run `docker compose run --rm plausible /bin/sh -c '/entrypoint.sh db migrate'`. If the errors reference ClickHouse, check the schema state with `docker compose exec plausible_events_db clickhouse-client --query 'SHOW TABLES'`, then read the release notes for the version you jumped to. Note the service is named `plausible_events_db` in v3.x, not `clickhouse`.