Plausible Analytics: self-hosted, cookie-free web analytics in Elixir

What Plausible Analytics measures, and what it refuses to measure

Plausible Analytics is a web analytics tool that counts traffic without storing personal data or IP addresses and without setting cookies or persistent identifiers. The README states the product is compliant with GDPR, CCPA and PECR on that basis. The practical consequence is that the dashboard shows aggregates: pageviews, referrers, goals, conversions, funnels and revenue attribution, all on a single page rather than in a report builder.

The audience is a site owner who wants to answer "how many people came, from where, and did they convert" without running a consent banner for analytics. The README also targets teams migrating off Google Analytics, and it lists a Search Console integration for keyword data, weekly or monthly email and Slack reports, and public dashboard sharing. What it will not give you is a per-user journey. There is no individual profile to inspect because the tool does not build one, so any question of the form "what did this specific visitor do" is outside the design.

The Elixir, Postgres and ClickHouse split behind the dashboard

The repository layout tells most of the architecture story. The application is an Elixir/Phoenix project (mix.exs, lib/, priv/, rel/), the browser tracker lives in its own tracker/ directory with its own package.json, and the dashboard assets live in assets/. The Makefile exposes two separate database targets: postgres and clickhouse. That split is the core mechanism. Postgres holds the application data (sites, users, settings), while ClickHouse holds the event data that the dashboard queries.

The Makefile pins a production-parity ClickHouse image, clickhouse/clickhouse-server:25.11.5.8-alpine, alongside a latest-alpine variant for local work, and stores its data in a host volume. Events arrive either from the tracker script or directly through the documented events API, and the README notes the stats API and CSV export for getting data back out. The Dockerfile shows the build path: a Node 24 stage supplies npm, an Elixir 1.20.4 on Erlang 28 stage compiles dependencies with MIX_ENV=ce, then builds the tracker, deploys assets and digests static files. The MIX_ENV=ce default is the signal that the Docker image builds the Community Edition, not the cloud product.

Installing Plausible CE from the Makefile

The README does not walk through a local install; the Makefile does. Its install target is the documented sequence for a development setup, and it requires Elixir, Node and a reachable Postgres instance before you run it. From the repository root:

make install

That target runs mix deps.get, mix ecto.create, mix ecto.migrate, mix download_country_database, then npm install in both assets and tracker, and finally npm run deploy --prefix tracker. If the database is not up, ecto.create fails and nothing after it runs. ClickHouse is separate and starts from the same Makefile:

make clickhouse

This launches the clickhouse/clickhouse-server:latest-alpine container named plausible_clickhouse with ports 8123 and 9000 published and a host volume for its data. For a version matching production, the Makefile offers make clickhouse-prod, which uses clickhouse/clickhouse-server:25.11.5.8-alpine. To confirm the event database exists, connect to it:

make clickhouse-client

That opens clickhouse-client against the plausible_events_db database. Once both databases are reachable, the web server starts with:

make server

which is mix phx.server. The reader should expect the Phoenix endpoint to come up and the dashboard to be reachable, with the tracker script served from the same application. The README points to the official managed cloud as the two-minute option; the Makefile path above is the self-hosted one, and it assumes you already know how to run Postgres and Docker.

Where the Community Edition stops and the cloud begins

The README carries a comparison table between Plausible Analytics Cloud and the Community Edition, and the split is worth reading literally. On the cloud side it promises a worldwide CDN, high availability, backups, security and maintenance handled by the vendor, plus a release schedule described as continuously developed with updates multiple times per week. On the CE side the README says you do it all yourself: installation, maintenance, upgrades, server capacity, uptime, backup, security, stability, consistency and loading time. The table's release-schedule cell for CE is truncated in the README text, so the exact CE cadence is not stated there.

That asymmetry is the real limitation, not a missing feature. Nothing in the repository suggests the CE build lacks the tracking or dashboard functionality; the cost is operational. You are running two stateful databases with different failure modes. ClickHouse volumes need their own backup story, and the Makefile's local container writes into a project directory volume, which is fine for development and wrong for production. The README does not document rollback or a supported upgrade procedure for CE, so a self-hoster is choosing a path the documentation describes in terms of responsibility rather than steps.

How Plausible differs from a full-session analytics suite

The obvious alternative is Google Analytics, and the README frames the difference as a business model question rather than a feature list: Google Analytics is free because the vendor monetizes user data for advertising, while Plausible is funded by subscriptions and collects only aggregated, anonymized stats. Technically the divergence is sharper. A session-oriented suite builds a visitor identity so it can stitch pageviews into a journey, which is what makes funnels, cohorts and attribution flexible. Plausible deliberately does not keep that identity, so its funnels and attribution are computed over aggregate events within the retention window you configure.

If your questions are about individual behavior over time, a cookie-based or first-party-identifier tool answers them and Plausible does not. If your questions are about traffic volume, sources, and conversion counts, Plausible answers them with a much smaller data surface and no consent banner for analytics. The trade is analytical depth for a smaller compliance footprint, and it is a genuine trade rather than a strict improvement. The README's own framing, that Plausible measures traffic and not individuals, is the honest summary of which side you are choosing.

Licence, forks and the cost of staying current

Plausible Analytics is licensed under AGPL-3.0. For a self-hoster running the software internally, that is a familiar arrangement: you can run and modify it, and the copyleft obligations attach when you distribute modified versions or offer the modified software to users over a network. Because this is a network-facing application, the AGPL's network clause is the part to read carefully before you fork the dashboard and expose it to your own customers. This is a description of the licence text, not legal advice; if you plan to redistribute a modified build, get your own review.

Upgrade cost follows from the two-database design. The repository ships a CHANGELOG.md and tagged releases, with v3.2.1 dated 2026-05-15, v3.2.0 dated 2026-01-26 and a v3.2.0-rc.0 before it. The last push to the default branch was on 2026-05-15, so the project is not archived, but the gap between v3.2.0 in January and v3.2.1 in May is the cadence a CE operator should plan around. The README does not document a supported upgrade path for CE, and schema changes in either Postgres or ClickHouse are the kind of thing that makes a version pin valuable. Pinning the ClickHouse image to 25.11.5.8-alpine, as the Makefile's production target does, is the concrete way to keep one half of the stack from moving under you.

Editorial conclusion

Adopt Plausible CE if you want aggregate, cookie-free traffic numbers on infrastructure you control and you are willing to run Postgres, ClickHouse and an Elixir release yourself. Do not choose it if you need per-visitor session replay, if nobody on the team can operate a database cluster, or if you want someone else to handle upgrades. Before committing, read the CE versus Cloud comparison table in the README, check the release cadence against the changelog, and confirm that the AGPL-3.0 obligations fit how you intend to modify and distribute the code.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes