Plausible Analytics VPS requirements: RAM, CPU, disk, and why ClickHouse sets the size

Sizing guide

Our recommendations, derived from the sourced figures below. Not measurements.

Official requirements

What people report in practice

Individual reports, not controlled tests. Versions, hardware and settings differ, so treat these as data points, not guarantees.

• Plausible read 619 MB of RAM and 1.4 GB of Docker disk shortly after the documented install on a clean 2 vCPU / 8 GB VM. In the same sweep Umami, which uses PostgreSQL instead of ClickHouse, read 165 MB, and Matomo 138 MB

  Independent test of 96 self-hosted apps, Google Cloud e2-standard-2, 28 Sep 2026. One reading about 30 seconds after install, with no data or traffic; the authors note ClickHouse stacks may still be growing at that point, so the figure is more likely to read low than high

  Blog SelfHost Atlas: Self-hosted app RAM usage, 96 apps measured (2026) · checked Nov 3, 2026

• docker stats on Plausible CE 2.1.4 with almost no traffic: the Plausible app 23 MiB, PostgreSQL 36 MiB and ClickHouse 541 MiB, with ClickHouse at 7.7% CPU and 724 processes/threads. The user saw about 5% of a quad-core i5 used overall

  GitHub issue comment, Oct 2024, on a 32 GB home server

  GitHub GitHub plausible/analytics #301: Excessive resource usage from clickhouse · checked Nov 3, 2026

• "Plausible + Clickhouse used a constant 15% CPU on my powerful server, while apparently doing nothing, even before I added any website analytics." The user moved to Umami. Another user in the same thread, after applying ClickHouse's low-memory tips, still saw ClickHouse "always consuming CPU and ~349MiB of Memory"

  GitHub issue comments, Nov 2024 and Feb 2026

  GitHub GitHub plausible/analytics #301: Excessive resource usage from clickhouse · checked Nov 3, 2026

• ClickHouse restarted about once a minute with "Cannot schedule a task: failed to start the thread" while loading its own system tables, so the dashboard was down. The user had been on a very small EC2 instance ("I think micro"), and moving to a larger one fixed it

  GitHub issue, Sep to Oct 2026

  GitHub GitHub plausible/analytics #6680: Clickhouse keeps restarting · checked Nov 3, 2026

• The ClickHouse volume reached 44 GiB and filled the disk while the events table held only about 700k rows and about 10 MiB of active parts. Another user saw 30 GB in three days; a third found system.trace_log at 25.81 GiB. One user said the folder stopped growing after switching to the repo's default ClickHouse config files

  GitHub issue, opened Sep 2025, still open; comments through Dec 2025

  GitHub GitHub plausible/community-edition #256: ClickHouse store folder grows uncontrollably · checked Nov 3, 2026

• Even with the shipped logs.xml, processors_profile_log reached "almost 2GB" on one setup, because it isn't disabled and has no TTL. A follow-up pull request measured about 36 rows per query in that table

  GitHub issue #275 (Jun 2026) and pull request #280 (Aug 2026), both still open

  GitHub GitHub plausible/community-edition #275: Why no processors_profile_log in logs.xml? · checked Nov 3, 2026

• On a 4-core, 8 GB server tracking about 150k goal conversions a week, the Goal Conversions report for 7 days took 60 seconds at about 120% CPU, and 28 days hit a 120-second Cloudflare timeout after upgrading from v2.0.0-rc.0 to v3.2.1

  GitHub issue, Sep 2026, still open; the reporter isn't sure whether it is a regression or an upgrade problem

  GitHub GitHub plausible/community-edition #283: Goal Conversions performance regression · checked Nov 3, 2026

What drives Plausible Analytics (Community Edition)'s RAM use

ClickHouse, not Plausible, is the big process

In one user's docker stats, the Plausible app took 23 MiB and PostgreSQL 36 MiB, while ClickHouse took 541 MiB (#301). ClickHouse is built for huge datasets, so the CE repo ships settings that cap its caches and threads for small servers (clickhouse/). Keep those files mounted; at least one of the disk-filling reports was cured by going back to them.

Idle CPU is real

ClickHouse runs background merges and flushes its own logs even with no visitors. Users have reported 5 to 15% CPU at idle (#301). On a shared 1 vCPU plan that's noticeable, and some cheap plans have fair-use limits on sustained CPU, so check your plan's terms. The CPU must also support SSE 4.2 or NEON, which any current VPS does, but very old or emulated CPUs may not.

Disk: your events are small, ClickHouse's logs may not be

Analytics events compress well: one user's 700k-row events table was about 10 MiB (#256). What fills disks is ClickHouse's system tables, such as trace_log and processors_profile_log, when they aren't disabled or capped (#275). Start with at least 20 GB of disk (our estimate) and check table sizes after the first month.

Gotchas on a VPS

• Add processors_profile_log to logs.xml yourself. Until PR #280 is merged, add <processors_profile_log remove="remove" /> to clickhouse/logs.xml and restart ClickHouse. Then check what's using space with a query on system.parts grouped by table; any system.* table in the gigabytes is a log you can disable or truncate.
• Don't drop the low-resource files from a custom compose. If you write your own compose file or use an older template, copy all four ClickHouse files from the repo (logs.xml, ipv4-only.xml, low-resources.xml and the default-profile overrides). Without them ClickHouse logs far more and sizes itself for a much bigger server (#256).
• Bind-mounted data folders need the right owner. The default compose uses named volumes. If you switch to host folders, the Plausible container can fail with enoent errors; one user fixed it by making the plausible-data folder owned by user 999 (#206).
• Registration and the public dashboard. Create your own account right after docker compose up, before anyone else finds the page. After that, registration is invite-only by default; set DISABLE_REGISTRATION=true if you'll never invite anyone (configuration).
• It has to be reachable from the internet. Unlike most apps here, Plausible must accept tracking requests from every visitor's browser, so it can't live only behind a VPN. You can still keep the server at home and publish just the Plausible hostname through a tunnel such as Pangolin. Behind your own reverse proxy, leave HTTPS_PORT unset and point the proxy at HTTP_PORT (8000 by default).
• Back up both databases. Accounts and site settings are in PostgreSQL; the analytics are in ClickHouse. Back up the db-data and event-data volumes (or dump both databases) with the containers stopped, and copy them off the server. We haven't tested a restore ourselves yet.

Cheapest plans that fit

Plausible CE alone (app, PostgreSQL, ClickHouse) for a few small sites: 2 GB RAM and 1+ vCPU

Threshold: Official CE guide: at least 2 GB of RAM recommended. Not yet measured by us (source). Only plans with at least 1 vCPU are listed.

Plausible CE next to other apps, or for busier sites: 4 GB RAM and 2+ vCPU

Threshold: Our estimate, not a measurement: 2 GB for Plausible plus room for neighbours, and a second vCPU for ClickHouse queries (source). Only plans with at least 2 vCPUs are listed.

Prices checked Oct 28, 2026 on each provider's official pricing page. EUR prices converted at the ECB rate of Oct 27, 2026 (1 € = $1.115) only for ranking. See all plans on the cheapest 4 GB VPS page.

Related pages

• Uptime Kuma requirements: Watch your Plausible dashboard and tracking script from a separate small VPS, so you notice if ClickHouse falls over.
• Pangolin requirements: Run Plausible at home and publish only its hostname through a Pangolin tunnel on a small VPS.
• Coolify requirements: Coolify can run a Docker Compose stack like Plausible's; budget Coolify's own RAM on top of Plausible's 2 GB.
• n8n requirements: Plausible has a Stats API, so an n8n workflow can pull numbers into reports or alerts.
• Vaultwarden requirements: A light app that fits next to Plausible on a 4 GB plan; keep its login private even though Plausible must be public.
• linkding requirements: Another small app that can share a 4 GB VPS with Plausible without changing the size.