Plausible Community Edition: self-hosting the analytics stack with Docker Compose

What the community-edition repository actually contains

This repository is not the analytics application. It is the deployment recipe for it. The top level holds five entries: .gitignore, LICENSE, README.md, a clickhouse/ directory, and compose.yml. That is the whole surface. The README describes itself as "a getting started guide to self-hosting Plausible Community Edition", and the application itself arrives as a prebuilt image, ghcr.io/plausible/community-edition:v3.2.1, pulled by Compose rather than compiled from source.

The audience follows from that shape. You are expected to be comfortable with Docker Compose, environment files, and DNS. You are not expected to read Ruby or Elixir, because none of it is here. If you wanted to patch the application, this repository will not help you; it only decides how the application is configured and what it talks to.

The clickhouse/ directory is the part worth noticing. It holds configuration fragments mounted read-only into the ClickHouse container, including logs.xml, ipv4-only.xml, low-resources.xml, and default-profile-low-resources-overrides.xml. Those files are the difference between a ClickHouse instance that fits on a small VPS and one that does not.

Three containers and the data flow between them

compose.yml defines three services. plausible_db runs postgres:16-alpine, stores its data in the db-data volume, and carries POSTGRES_PASSWORD=postgres as an environment variable. plausible_events_db runs clickhouse/clickhouse-server:24.12-alpine with three volumes: event-data for /var/lib/clickhouse, event-logs for the server logs, and the read-only config mounts from the clickhouse/ directory.

The application container, plausible, depends on both. Its command is explicit about the startup sequence:

command: sh -c "/entrypoint.sh db createdb && /entrypoint.sh db migrate && /entrypoint.sh run"

That single line tells you most of the operational story. The container creates the database if it does not exist, runs migrations, then starts the server. Migrations run on every container start, not as a separate release step, which is convenient for a single-host deployment and awkward if you ever want to run more than one application instance against the same database.

The split between PostgreSQL and ClickHouse is the architectural decision that matters. PostgreSQL holds the relational state: users, sites, configuration. ClickHouse holds the event stream, because columnar storage is what makes aggregate queries over millions of pageviews return quickly. Both must be healthy before the app is useful, and both have healthchecks with a start_period of 1m, which is a fair signal that neither comes up instantly. ClickHouse's healthcheck polls http://127.0.0.1:8123/ping. The ulimit on the ClickHouse service sets nofile to 262144 for both soft and hard limits, and CLICKHOUSE_SKIP_USER_SETUP=1 is set so the image does not try to configure users on first boot.

Installing Plausible Community Edition with Docker Compose

The README gives a five-step quick start. The first step clones the tag matching the default branch, v3.2.1, as a single branch into a directory called plausible-ce. The listing after the clone shows clickhouse/, compose.yml, LICENSE, and README.md, which matches the repository layout.

git clone -b v3.2.1 --single-branch https://github.com/plausible/community-edition plausible-ce
cd plausible-ce

The second step creates a .env file with two variables. BASE_URL is the domain you will actually serve from, and SECRET_KEY_BASE is generated with openssl. The README is explicit that the secret must be at least 64 bytes.

touch .env
echo "BASE_URL=https://plausible.example.com" >> .env
echo "SECRET_KEY_BASE=$(openssl rand -base64 48)" >> .env

The third step is where most people get stuck, because the base compose.yml does not publish any ports. You add a compose.override.yml that maps host ports to the container, and set HTTP_PORT and HTTPS_PORT in .env. The README states that setting these to 80 and 443 enables automatic Let's Encrypt TLS certificate issuance, and that the domain must already have a DNS entry pointing at the server for that to work.

services:
    plausible:
        ports:
            - 80:80
            - 443:443

For a local evaluation the README suggests a different combination: set BASE_URL=http://localhost:8000, keep the server on HTTP_PORT=80, and map the host port as 8000:80 in the override. Then docker compose up -d starts all three services in the background, and you visit the base URL to create the first user. If you plan to put Plausible behind a reverse proxy instead, the README points to a wiki page on that setup rather than describing it inline.

The resource floor is real, and it is ClickHouse

The prerequisites section is unusually blunt: CPU must support SSE 4.2 or NEON or higher, and at least 2 GB of RAM is recommended to run ClickHouse and Plausible without OOM kills. Neither of those is a soft suggestion. ClickHouse will refuse to start on an older x86 CPU, and the RAM figure is what keeps both the columnar store and the application resident at the same time.

That puts a floor under your hosting choice. A 1 GB VPS is not enough by the project's own stated threshold. The low-resources.xml and default-profile-low-resources-overrides.xml files in the clickhouse/ directory are the project's attempt to make small setups viable, and the compose.yml comments link to ClickHouse's own documentation page on running with less than 16 GB of RAM. Those files help; they do not remove the 2 GB recommendation.

The second constraint is storage growth. Event data lands in the event-data volume and is never pruned by anything visible in this repository. There is no retention job, no scheduled cleanup, and no documented size ceiling. You are responsible for watching disk usage and for deciding what happens when it fills. The README does not document a retention policy or a rollback procedure, and the wiki is where upgrade and configuration questions are deferred to.

A third limitation is the single-instance assumption. Because migrations run inside the container command on every start, and because the override file publishes ports directly on the plausible service, the design targets one host running one copy. Horizontal scaling is not addressed here.

When a managed analytics service is the better answer

The honest alternative is Plausible's own hosted cloud product, which the README acknowledges by noting that Plausible CE is funded by cloud subscribers. The difference is not the interface; it is who owns the failure modes. With the cloud service, ClickHouse capacity, upgrades, backups, and TLS are someone else's problem. With this repository, all four are yours, and the README hands upgrades and configuration to the wiki rather than covering them in the quick start.

A second comparison point is a general-purpose stack where you assemble the pieces yourself: your own PostgreSQL, your own ClickHouse, your own application build. That path gives you control over versions and the ability to run the app from source. It also means you own the migration ordering, the healthcheck tuning, and the ClickHouse config fragments that this repository already wrote for you. The value here is precisely that compose.yml and the clickhouse/ directory encode those decisions.

If your actual need is a privacy-friendly counter on a static site and you do not care about the Plausible UI, a self-hosted or hosted lightweight pageview counter is a smaller thing to operate. This stack is for people who want the analytics product, not just a number.

Licence, maintenance, and what an upgrade costs you

The repository carries the MIT licence, which is permissive and places few conditions on reuse of the Compose file and the ClickHouse configuration fragments. That covers the deployment recipe, not the application image, which is published separately as ghcr.io/plausible/community-edition and may carry its own terms. If licence terms matter to your organisation, check the application's own licensing rather than assuming the MIT file at this repository's root settles the question. Nothing here is legal advice.

On maintenance, the last push to this repository was on 2026-05-15, and the default branch is tagged v3.2.1. The repository is not archived. The README directs release announcements to the GitHub releases page of the separate analytics repository and questions to GitHub discussions under a self-hosted support category, which means the issue tracker here is not the main support channel.

The upgrade cost is concrete rather than abstract. The application image is pinned by tag in compose.yml, so moving forward means editing that tag and restarting, at which point the container command runs db createdb and db migrate before the server starts. That is the moment to have a database backup, because there is no documented rollback path in the README. The ClickHouse image is pinned separately at 24.12-alpine, so the two version lines move independently and you should read the release notes before changing either.

Editorial conclusion

Adopt this if you want Plausible's own analytics interface running on hardware you control, you already run Docker Compose, and your CPU has SSE 4.2 or NEON with at least 2 GB of RAM free for ClickHouse and Plausible. Do not adopt it if you want a managed service, if your host is a small ARM board without NEON, or if you were looking for a general-purpose BI layer rather than a web analytics tool. Before pointing a domain at it, verify three things: that BASE_URL matches the real hostname you will serve from, that SECRET_KEY_BASE is a unique 64-byte value generated with openssl rand -base64 48, and that the ports in compose.override.yml are free on the host, because the default flow expects 80 and 443 for automatic Let's Encrypt issuance.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. plausible/community-edition on GitHub
4. README