How to Self-Host Plausible Analytics With Docker Compose

Plausible Community Edition (CE) is the self-hosted version of Plausible, a web analytics service. Docker Compose uses a configuration file to run the Plausible web app and its databases together. You control the server and where it stores data, and you also take responsibility for updates, backups, security, and uptime.

The Plausible container needs two databases to run: PostgreSQL stores application data, and ClickHouse stores website events. This guide uses the versioned CE setup at v3.2.1 to configure a public URL and HTTPS, then connect a website. Check the release notes and setup instructions for the version you choose before deploying or upgrading.

Check the server and domain

The official CE setup requires Docker and Docker Compose. ClickHouse requires the server’s CPU to support SSE 4.2 or NEON. Plausible recommends at least 2 GB of RAM; actual memory needs depend on traffic.

Choose a hostname such as plausible.example.com and point its DNS to the server. DNS is the internet’s naming system; it tells browsers which server to contact for a hostname. The hostname must resolve to the server for Plausible’s automatic Let’s Encrypt certificate setup to work. The official CE repository lists the prerequisites and deployment instructions.

Download a versioned Compose setup

Clone the repository at a specific release so the Compose configuration and application image stay aligned:

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

The v3.2.1 Compose file defines three services: Plausible, PostgreSQL 16, and ClickHouse 24.12. It also declares persistent volumes for database and application data. A volume stores data separately from a container, so replacing the container does not delete that data. You still need a separate backup.

Set the public URL and secret

Create a .env file in the repository directory. Replace the sample hostname with the domain you configured:

cat > .env <<EOF
BASE_URL=https://plausible.example.com
SECRET_KEY_BASE=$(openssl rand -base64 48)
EOF

Plausible uses BASE_URL as its public address for generated links and security checks. Keep the hostname and https scheme consistent with the address visitors will use. SECRET_KEY_BASE protects dashboard sessions and helps generate other secrets. The CE quick start requires at least 64 bytes; generate a fresh value rather than copying one from an example. Keep .env private because it contains this secret.

Choose how HTTPS reaches Plausible

Use one of two setups: let Plausible handle HTTPS directly, or place a reverse proxy in front of it. A reverse proxy is a web server that accepts public requests and forwards them to Plausible.

For direct HTTPS, add these settings to .env:

HTTP_PORT=80
HTTPS_PORT=443

Then create compose.override.yml to publish those ports for the Plausible service:

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

Allow inbound traffic on ports 80 and 443 at the server’s firewall and any network firewall in front of it. Plausible uses the public hostname and those ports to obtain and serve a Let’s Encrypt certificate.

If a reverse proxy already handles HTTPS for your other services, configure it to forward requests to Plausible over its internal HTTP port. Follow the CE reverse-proxy instructions for the proxy you run, and avoid publishing Plausible’s backend port directly to the public internet. Use one clear path for public HTTPS: either Plausible handles certificates, or the proxy does.

Start Plausible and create an account

Start the services in the background:

docker compose up -d

The Plausible startup command creates and updates the database schema before launching the web app. The schema defines how the database organizes records. A migration changes that structure when a release requires it.

Check whether the containers started and review Plausible’s logs if the site does not load:

docker compose ps
docker compose logs plausible

Then open the address in BASE_URL and create the first user. If startup fails, check the logs for database or configuration errors. Also confirm that DNS points the hostname to the server and that the selected HTTPS ports are reachable.

Connect a website

After signing in, add the website in Plausible and install the tracking snippet from that site’s settings in the website’s <head> section. The tracking code sends page-view events to Plausible. A working dashboard does not mean the website is sending data. Use the instance-specific script address shown for your self-hosted deployment. Plausible’s tracking instructions describe how to install and review the snippet.

Restrict access and plan for recovery

The CE configuration sets DISABLE_REGISTRATION to invite_only by default. Keep that setting unless you have a reason to allow open registration; setting it to false lets anyone sign up. Plausible also supports email delivery for messages such as password resets and reports. Configure the documented mail settings before enabling email verification, which requires working email delivery. The configuration reference describes these options and Docker Secrets, which let Plausible read sensitive values from files instead of ordinary environment variables.

Back up PostgreSQL, ClickHouse, and the deployment configuration. Then test that you can restore them. The Compose volumes preserve data when containers are replaced, but they do not protect against lost or damaged storage. Follow a backup plan that covers both databases; a PostgreSQL backup alone does not preserve analytics events stored in ClickHouse.

Pin versions and review upgrades

Keep the Plausible image pinned to a release instead of using an unpinned latest tag. Before upgrading, read that release’s instructions: major upgrades can require extra migration steps, so starting the new image is not always sufficient. The CE upgrade guide explains how to approach releases.

For example, the v3.2.1 release notes document a security fix for earlier CE v3.0 through v3.2 tags. Operators running an affected version were advised to update to v3.2.1; the release notes also describe blocking the /storybook endpoint as an interim mitigation. Check the notes for the exact version you run rather than applying an old mitigation as a general rule.

Self-hosting gives you control over the server and data location, while making you responsible for capacity, uptime, security, backups, and release work. Plausible also distinguishes CE from its managed service in features and support; review the current project details before choosing between them. Hosting analytics yourself does not, by itself, establish that your use meets a particular legal requirement.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com