Self-Hosting Plausible Analytics: A Complete Guide to Privacy-Friendly Web Analytics

Caption: Plausible Analytics Community Edition running as a private web analytics stack on your VPS.

#Introduction

Plausible Analytics is a lightweight, open-source web analytics platform built for site owners who want useful traffic insights without turning their visitors into advertising profiles. Unlike legacy analytics platforms, Plausible focuses on simple metrics: page views, visitors, sources, campaigns, countries, devices, browsers, and goal conversions. The tracking script is small, the dashboard is fast, and the product is designed around privacy-first analytics instead of surveillance.

The self-hosted release is Plausible Community Edition. It is free software under the AGPL license and runs the core analytics application, PostgreSQL for relational data, and ClickHouse for event data. You manage the server, upgrades, backups, domain, TLS certificates, uptime, and email delivery yourself. That is the trade-off: you get control and data ownership, but you also inherit the operational work that Plausible's managed cloud service normally handles.

This guide walks through deploying Plausible Community Edition on a fresh Ubuntu 24.04 LTS VPS using Docker Compose, which is the official installation path. By the end, you will have a working analytics instance at your own domain, a first website connected, HTTPS enabled, email settings prepared, and a practical maintenance checklist for backups and upgrades.

#Why Choose Plausible Analytics?

• Privacy-Friendly Metrics: Plausible is designed to avoid cookies and personal data collection for common web analytics use cases.
• Simple Dashboard: The interface prioritizes the numbers most site owners actually use, instead of burying reports under complex menus.
• Open Source Community Edition: The self-hosted edition lets you inspect the code and run analytics on your own infrastructure.
• Lightweight Script: The client-side script is intentionally small, which helps performance compared with heavy analytics bundles.
• Docker-First Deployment: The official Community Edition repository ships a Compose stack with PostgreSQL, ClickHouse, and Plausible.
• Data Ownership: Your traffic data stays in the environment and region you choose.

Self-hosting is best for developers, agencies, small businesses, and privacy-conscious publishers who are comfortable managing a VPS. If you need hosted support, advanced cloud-only features, or do not want to maintain infrastructure, Plausible Cloud may be a better fit.

#Prerequisites

Hardware Recommendations:

• 2 CPU cores
• 2 GB RAM minimum, with 4 GB recommended for busier sites
• 20 GB free disk space to start, plus room for ClickHouse event growth
• CPU support for SSE 4.2 or NEON, which ClickHouse requires

Software and Accounts:

• Ubuntu 24.04 LTS server with sudo access
• Docker Engine and Docker Compose plugin
• A domain such as plausible.example.com
• DNS A or AAAA record pointing to the VPS
• SMTP credentials if you want account invitations, password resets, and email verification

Security Notes:

• Use SSH keys and disable password login for the server.
• Keep Plausible behind HTTPS before adding production sites.
• Restrict registration after the first administrator account is created.
• Back up both PostgreSQL and ClickHouse data before upgrades.

Start with a fully updated host:

sudo apt update
sudo apt upgrade -y
sudo apt install -y ca-certificates curl git openssl ufw

Install Docker using Docker's convenience script:

curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker "$USER"
newgrp docker
docker --version
docker compose version

If you use ufw, allow SSH plus web traffic:

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status

#Installation Guide

The official Community Edition repository contains the Compose file and ClickHouse tuning files. Use a tagged release branch so your installation is reproducible.

#1. Clone Plausible Community Edition

sudo mkdir -p /opt
sudo chown "$USER":"$USER" /opt
cd /opt
git clone -b v3.2.1 --single-branch https://github.com/plausible/community-edition plausible-ce
cd /opt/plausible-ce

The directory should contain the Compose file and ClickHouse configuration:

ls -1

Expected entries include:

LICENSE
README.md
clickhouse
compose.yml

#2. Create the Environment File

Create .env with your public URL and a strong secret. The BASE_URL value must match the domain visitors and administrators will use.

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

Review the file:

cat .env

You should see your real domain and a long random secret:

BASE_URL=https://plausible.example.com
SECRET_KEY_BASE=replace-with-the-generated-secret-from-your-server

Do not copy the example secret into production. Generate it on the server and keep it private.

#3. Expose Plausible on HTTP and HTTPS

The official Compose stack can expose Plausible directly on ports 80 and 443. Add the web ports to .env and create a Compose override:

echo "HTTP_PORT=80" >> .env
echo "HTTPS_PORT=443" >> .env

cat > compose.override.yml <<'EOF'
services:
  plausible:
    ports:
      - 80:80
      - 443:443
EOF

When BASE_URL uses https:// and ports 80/443 are reachable, Plausible can request TLS certificates for the domain. Make sure DNS is correct before starting the stack.

Caption: Docker Compose runs Plausible, PostgreSQL, and ClickHouse as separate services with persistent volumes.

#4. Start the Stack

Run the services in detached mode:

docker compose up -d

Check that all containers are running:

docker compose ps

Watch the first boot logs if the application is still initializing:

docker compose logs -f plausible

The first startup runs database creation and migrations before launching the web application.

#5. Create the First User

Open your browser to:

https://plausible.example.com

Create the first administrator account from the web interface. After the first account is working, registration should normally be disabled so random visitors cannot create users on your private analytics instance.

Add this line to .env:

echo "DISABLE_REGISTRATION=true" >> .env
docker compose up -d

If you plan to invite teammates, configure SMTP first so Plausible can send email.

#Configuration

#Email Delivery

Email is needed for password resets, verification, and team workflows. Plausible Community Edition exposes mail settings as environment variables. A typical SMTP configuration looks like this:

MAILER_ADAPTER=Smtp
MAILER_EMAIL=analytics@example.com
MAILER_NAME=Plausible Analytics
SMTP_HOST_ADDR=smtp.example.com
SMTP_HOST_PORT=587
SMTP_USER_NAME=analytics@example.com
SMTP_USER_PWD=use-a-real-smtp-password
SMTP_HOST_SSL_ENABLED=false

Add the real values to /opt/plausible-ce/.env, then restart:

docker compose up -d
docker compose logs --since=5m plausible

For port 587 with STARTTLS, SMTP_HOST_SSL_ENABLED=false is common. If your provider requires implicit TLS on port 465, follow your provider's documentation and test carefully.

#Reverse Proxy Option

If the VPS already runs Caddy, Nginx Proxy Manager, Traefik, or another reverse proxy, do not bind Plausible directly to public ports 80 and 443. Instead, expose Plausible on a local port and let the reverse proxy handle TLS.

For example, set BASE_URL=https://plausible.example.com, set HTTP_PORT=80, and use this override:

services:
  plausible:
    ports:
      - 127.0.0.1:8000:80

A simple Caddy site can then proxy to the local port:

plausible.example.com {
    reverse_proxy 127.0.0.1:8000
}

Reload Caddy after editing its configuration:

sudo systemctl reload caddy

#Database Volumes

The official Compose file creates persistent volumes for PostgreSQL, ClickHouse, ClickHouse logs, and Plausible application data. Confirm the volumes exist:

docker volume ls | grep plausible

Do not delete these volumes unless you intentionally want to remove analytics data.

#Usage

#Add Your First Website

After logging in, click Add website and enter the domain you want to track, such as www.example.com. Plausible will show a tracking snippet similar to:

<script defer data-domain="www.example.com" src="https://plausible.example.com/js/script.js"></script>

Add that snippet to your site's <head> section. For a Laravel Blade layout, place it in the main layout file before </head>:

<head>
    <!-- other meta tags -->
    <script defer data-domain="www.example.com" src="https://plausible.example.com/js/script.js"></script>
</head>

For a static site, add the same snippet to your base template. Deploy the site and visit a page in a private browser window or from a different network.

Caption: Site traffic flows from your website snippet into Plausible's dashboard without third-party analytics vendors.

#Verify Tracking

Use the browser developer tools Network tab and filter for script.js or your Plausible domain. You should see the script load successfully. Then click around a few pages and return to the Plausible dashboard.

Basic testing checklist:

1. The tracking script returns HTTP 200.
2. The dashboard shows at least one current visitor or page view.
3. Your domain in the snippet exactly matches the domain configured in Plausible.
4. Browser content blockers are not blocking your test request.
5. HTTPS works with no certificate warnings.

#Goals and Campaigns

Use goals for important actions: newsletter signups, contact form submissions, checkout completions, or outbound link clicks. Plausible's dashboard becomes more useful when it tracks business outcomes, not only page views.

For marketing campaigns, add standard UTM parameters to inbound links:

https://www.example.com/pricing?utm_source=newsletter&utm_medium=email&utm_campaign=summer-launch

Plausible will group traffic by source and campaign so you can see which channels bring useful visitors.

#Screenshots and Visuals

The diagrams in this guide are original, copyright-safe visuals created for the deployment workflow. In production documentation for your team, add your own screenshots after installation:

• The Plausible overview dashboard for a test site
• The website settings screen with the tracking snippet
• A goals report showing a successful conversion
• Your backup and monitoring runbook

Avoid using random product screenshots from the web. If you include real dashboard screenshots, blur private domains, emails, and traffic numbers.

#Troubleshooting

• The site does not load after docker compose up -d: Run docker compose ps and docker compose logs plausible. The first boot may take time because migrations run before the web server starts.
• TLS certificate issuance fails: Confirm BASE_URL uses the final public domain, DNS points to the VPS, and ports 80/443 are reachable from the internet.
• ClickHouse container restarts: Verify the CPU supports SSE 4.2 or NEON and the server has enough memory. Increase RAM if the host is under pressure.
• No page views appear: Check that the tracking snippet uses the exact domain configured in Plausible and that the browser is not blocking the request during your test.
• Password reset email is not delivered: Recheck SMTP host, port, username, password, sender address, and provider security rules.
• Registration is still open: Add DISABLE_REGISTRATION=true to .env and restart with docker compose up -d.
• Disk usage grows quickly: Review retention needs, traffic volume, and backup storage. ClickHouse event data can grow faster than application files on busy sites.

#Scaling, Securing, and Next Steps

Treat Plausible like any other production service. It holds business data, needs reliable backups, and should be patched regularly.

#Backups

At minimum, back up the Docker volumes while the stack is stopped or during a maintenance window:

cd /opt/plausible-ce
docker compose stop plausible
sudo tar -czf /root/plausible-volumes-$(date +%F).tar.gz /var/lib/docker/volumes
docker compose start plausible

That broad archive is simple, but it may be large because it includes all Docker volumes on the host. If this VPS runs other containers, use a dedicated Docker volume backup tool or provider snapshots. Always test restoring to a separate server before relying on any backup plan.

#Upgrades

Follow the Community Edition release notes and upgrade guide. A safe upgrade pattern is:

cd /opt/plausible-ce
git fetch --tags
git checkout v3.2.1
docker compose pull
docker compose up -d
docker compose logs --since=10m plausible

Replace v3.2.1 with the target release you have reviewed. Back up first, then upgrade, then verify the dashboard and tracking script.

#Monitoring

Monitor the service from outside the server. At minimum, track:

• HTTPS availability for https://plausible.example.com
• Disk usage on the Docker volume filesystem
• Memory pressure and container restarts
• Backup job success
• Certificate renewal status

Caption: A production Plausible deployment needs backups, upgrades, monitoring, and access controls.

#Hardening

After the first administrator account is created:

• Keep DISABLE_REGISTRATION=true.
• Use strong passwords and a password manager.
• Limit SSH access to trusted keys.
• Keep Docker and the host OS updated.
• Store .env securely because it contains secrets.
• Use provider firewall rules if your VPS platform supports them.

Plausible Community Edition gives you clean, privacy-focused analytics under your control. The setup is straightforward with Docker Compose, but the long-term success of the deployment depends on operational discipline: upgrades, backups, monitoring, and careful access management.

#References

• Plausible Analytics self-hosting documentation
• Plausible Community Edition repository
• Plausible Community Edition wiki
• Plausible Analytics releases
• Docker Engine installation documentation