Plausible Analytics self-hosted: Community Edition on one machine

What CE asks of the machine

The prerequisites in the community-edition README are short, and they are all of the official hardware guidance:

The shipped compose.yml mounts low-resource configuration files into ClickHouse, with a comment that they suit small setups. That is how the stack fits in 2 GB. ClickHouse's own guidance assumes far more memory; see our self-hosted ClickHouse page if you plan heavy queries on the raw events. Check the CPU flag before you start: grep -c sse4_2 /proc/cpuinfo prints a number above zero on a CPU that has it.

What the Community Edition includes and omits

The plausible/analytics README states the licence: "Plausible CE is open source under the GNU Affero General Public License Version 3 (AGPLv3) or any later version." The JavaScript tracker that goes on your site is released under MIT, and the community-edition repository that holds the Compose files carries its own MIT licence.

• Release cadence: a long-term release published twice per year, so cloud features arrive late.
• Not in CE: marketing funnels, ecommerce revenue goals, SSO and the sites API.
• Bot filtering: basic, by User-Agent header and referrer spam domains. The cloud product also excludes data-centre IP ranges.
• Support: community only, through GitHub discussions.
• Gained: you choose the country the data sits in, and raw events can be read straight from ClickHouse.

Sizing the server

Plausible publishes no per-pageview sizing, so size from the recommended 2 GB and from what else shares the box. Every line in our dedicated server range starts at 8 GB of memory or more, which covers the stack with room for the page cache ClickHouse reads through. The machine is yours alone: all the cores, all the memory, the disks and the port, with root and no hypervisor, so ClickHouse merges never compete with a neighbour's workload.

• A few sites, modest traffic: an x86 Moonshot cartridge (Opteron X2150, Atom or Xeon E3), the class the range describes for one service per machine. The X-Gene ARM cartridge will not run the ClickHouse image, which needs ARMv8.2 or later on ARM.
• Many sites, or analysts querying ClickHouse directly: more memory and NVMe, for instance the 16-core Xeon D-1587 line with a 1.92 TB NVMe-SSD and up to 128 GB, or a dual-socket rack server.
• Location: pick the city by where your visitors and your data rules are. Amsterdam and Bucharest are inside the EU; see European dedicated servers.

The port on every line marked Unmetered has no transfer allowance, so a traffic spike sending more tracking hits costs nothing extra. Racked machines are handed over in about 30 minutes once payment is approved. Rack servers carry an out-of-band console (HPE iLO, Dell iDRAC or a Supermicro BMC), which gets you back in if a firewall rule locks out SSH; of the cartridges, only the m510 and m710x have one, the rest power control.

Installing behind Caddy, app on 127.0.0.1

The README's quick start publishes ports 80 and 443 from the container and lets Plausible fetch its own Let's Encrypt certificate, which makes the instance public from its first second. The wiki's reverse-proxy route keeps the app on loopback, so you can claim it privately first.

1. Point a DNS record such as plausible.example.com at the server, and install Docker Engine with the Compose plugin from Docker's documentation.
2. Enable ufw ahead of any listening service: sudo ufw allow OpenSSH, sudo ufw allow 80/tcp, sudo ufw allow 443/tcp, sudo ufw enable. Ubuntu's ufw applies each rule to IPv4 and IPv6 while IPV6=yes is set in /etc/default/ufw, its default.
3. Clone the repository, write the .env and the override, and start the stack as below. Run it as a docker group member, or with sudo.
4. curl --head http://localhost:8000 should answer HTTP/1.1 200 OK.

git clone -b v3.2.1 --single-branch https://github.com/plausible/community-edition plausible-ce
cd plausible-ce
touch .env && chmod 600 .env
echo "BASE_URL=https://plausible.example.com" >> .env
echo "SECRET_KEY_BASE=$(openssl rand -base64 48)" >> .env
echo "TOTP_VAULT_KEY=$(openssl rand -base64 32)" >> .env
echo "HTTP_PORT=8000" >> .env
cat > compose.override.yml << 'EOF'
services:
  plausible:
    ports:
      - 127.0.0.1:8000:8000
EOF
docker compose up -d

openssl rand -base64 48 prints 64 characters, the 64 bytes SECRET_KEY_BASE must reach. The keys are generated inside the command, so shell history records $(openssl ...) and never the value; chmod 600 runs before they are written. TOTP_VAULT_KEY encrypts two-factor secrets and is derived from SECRET_KEY_BASE when unset; set it now or not at all, because changing it later breaks existing two-factor enrolments.

Claiming the first account privately

Until an account exists, Plausible sends every visitor to the registration page, and that first registration is accepted whatever DISABLE_REGISTRATION says (check_registration_enabled in the Plausible source). Whoever registers first owns the instance. So the proxy starts out answering only your own address. Install Caddy from its project's Debian/Ubuntu packages and put this in /etc/caddy/Caddyfile, with the IPv4 address your browser reaches the server from and, for IPv6, your /64 prefix rather than a single address, because home IPv6 addresses change often within the prefix:

plausible.example.com {
    @outsiders {
        not remote_ip 203.0.113.10 2001:db8:1::/64
    }
    respond @outsiders "Not open yet" 403
    reverse_proxy localhost:8000
}

Run sudo systemctl reload caddy. Caddy obtains the certificate, you open https://plausible.example.com and register. Then delete the @outsiders block and the respond line, which leaves the wiki's two-line Caddyfile, and reload again. Caddy sets X-Forwarded-For by default, so the visitor's address reaches Plausible in that header.

Registration, mail and the published ports

• DISABLE_REGISTRATION: invite_only by default, so only invited users can register. Set true to stop every new registration, invitations included; false opens sign-up to anyone. Add the line to .env and run docker compose up -d.
• Mail: password resets, invitations and reports need it. Set SMTP_HOST_ADDR to a relay; without one Plausible tries direct delivery, which needs outbound port 25 and SPF or DKIM on the sender domain.
• Ports: Docker-published ports bypass ufw. Here the only published port is 127.0.0.1:8000, IPv4 loopback. Never combine it with the README's 80:80 and 443:443 override: a mapping without an address listens on every IPv4 and IPv6 interface and ufw cannot fence it. sudo ss -tlnp should show 80 and 443 owned by Caddy, and nothing else public but SSH.

Upgrades and backups

The wiki recommends pinning a patch version and notes that security fixes are not backported, so stay current. A minor upgrade is git pull origin with the new release's tag, then docker compose up -d; major versions carry their own steps in the release notes, and PostgreSQL major upgrades have a separate wiki page. Watch releases on the plausible/analytics repository.

Accounts, sites and goals live in PostgreSQL; every pageview lives in ClickHouse, in the event-data volume. This dump covers the first. Save it as a script and run it nightly from root's crontab; it uses -T rather than -it, and keeping it out of the crontab line avoids cron reading the % as a newline:

cd /home/you/plausible-ce && docker compose exec -T plausible_db pg_dump -U postgres plausible_db | gzip > /var/backups/plausible_db-$(date +%F).sql.gz

For the events, use ClickHouse's BACKUP statement to a declared disk or to S3, as our ClickHouse page explains, or copy the volume with the stack stopped. Ship both copies off the machine. Keep .env with them, encrypted: a restore needs the same SECRET_KEY_BASE and TOTP_VAULT_KEY, or two-factor logins stop working.

When this is the wrong place to run it

The Compose setup is one machine, one failure domain: if tracking must never drop a hit during patching, look elsewhere. Funnels, revenue goals and SSO are absent from CE at any size. And per the README, self-hosting means owning installation, upgrades, backups and security yourself.