Self-Host Plausible Analytics 2026: Docker Setup

TL;DR

Plausible Analytics is a privacy-first, cookie-free Google Analytics alternative that runs on your own server. Self-hosting costs $5–10/month on a VPS vs $9–19/month for Plausible Cloud — and you keep full data ownership. This guide walks through production deployment: Docker Compose with ClickHouse and PostgreSQL, Caddy reverse proxy with automatic SSL, SMTP email setup, Google Search Console integration, custom event tracking, and backup procedures. The entire setup takes under 30 minutes.

Key Takeaways

• Plausible requires two databases: PostgreSQL (for site/user data) and ClickHouse (for event analytics) — both handled by the official Community Edition Docker Compose
• Self-hosting saves $108–588/year vs Plausible Cloud depending on traffic volume
• The official community-edition repo manages everything — clone it, configure .env, run docker compose up -d
• SMTP setup is required for email reports and password resets — Resend, AWS SES, or any SMTP server works
• Google Search Console integration shows organic search queries directly in Plausible — configure with OAuth credentials
• Backups require preserving both the PostgreSQL and ClickHouse data volumes

Why Self-Host Plausible?

Plausible Cloud is a well-run service. But self-hosting offers:

• Cost: $60–120/year server cost vs $108–588/year cloud pricing
• Data sovereignty: Events never leave your server — no third-party sees your traffic
• No rate limits: Cloud plans have monthly pageview caps; self-hosted is unlimited
• Custom retention: Default 5-year retention; adjust ClickHouse configuration to keep more or less
• Air-gapped deployments: Internal tools and intranets where data must stay on-premises

Requirements

• VPS with 2 GB RAM (ClickHouse needs memory headroom; 1 GB works but is tight)
• Docker and Docker Compose v2+
• Domain name pointed at your server (analytics.yourdomain.com)
• SMTP credentials for email (Resend free tier, AWS SES, Postmark, or any SMTP)

Recommended VPS providers:

Provider	Spec	Monthly Cost
Hetzner CX22	2 vCPU, 4 GB RAM	€4.50/mo
DigitalOcean Basic	2 vCPU, 2 GB RAM	$12/mo
Linode Nanode	1 vCPU, 1 GB RAM	$5/mo (tight)
Vultr Cloud Compute	1 vCPU, 2 GB RAM	$10/mo

Step 1: Server Setup

# Ubuntu 22.04/24.04 — install Docker
curl -fsSL https://get.docker.com | sh

# Add your user to docker group (avoids sudo)
sudo usermod -aG docker $USER
newgrp docker

# Verify Docker and Compose
docker --version
docker compose version

Step 2: Clone Plausible Community Edition

Plausible maintains an official community-edition repository with the production-ready Docker Compose configuration.

git clone https://github.com/plausible/community-edition.git plausible-ce
cd plausible-ce

The repository contains:

• docker-compose.yml — defines all three services (PostgreSQL, ClickHouse, Plausible)
• clickhouse/ — ClickHouse configuration files for log levels and IPv4 settings
• .env.example — template for all environment variables

Step 3: Configure Environment Variables

# Copy the example environment file
cp .env.example .env

# Generate a 64-character secret key
openssl rand -base64 48

# Generate a 32-character TOTP vault key
openssl rand -base64 24

# .env — complete production configuration

# Base configuration
BASE_URL=https://analytics.yourdomain.com
SECRET_KEY_BASE=your-64-char-generated-secret-from-openssl-above
TOTP_VAULT_KEY=your-32-char-generated-key-from-openssl-above

# SMTP — required for email reports and password resets
# Option A: Resend (free tier: 3,000 emails/month)
MAILER_EMAIL=analytics@yourdomain.com
SMTP_HOST_ADDR=smtp.resend.com
SMTP_HOST_PORT=587
SMTP_USER_NAME=resend
SMTP_USER_PWD=re_your_resend_api_key_here
SMTP_HOST_SSL_ENABLED=true

# Option B: AWS SES
# SMTP_HOST_ADDR=email-smtp.us-east-1.amazonaws.com
# SMTP_HOST_PORT=587
# SMTP_USER_NAME=your-ses-iam-access-key
# SMTP_USER_PWD=your-ses-iam-secret-key

# Optional: Google Search Console integration
# Get credentials from: console.cloud.google.com → APIs & Services → Credentials
GOOGLE_CLIENT_ID=your-oauth-client-id.apps.googleusercontent.com
GOOGLE_CLIENT_SECRET=GOCSPX-your_client_secret

# Optional: MaxMind GeoLite2 for city-level location data (free license)
# Register at: maxmind.com/en/geolite2/signup
MAXMIND_LICENSE_KEY=your_maxmind_license_key
MAXMIND_EDITION=GeoLite2-City

# Optional: IP geolocation database path (alternative to MaxMind)
# GEONAMES_SOURCE_FILE=/path/to/cities15000.txt

Step 4: Start Plausible

# Start all services (runs in background)
docker compose up -d

# Watch startup logs
docker compose logs -f plausible

# Check all services are healthy
docker compose ps

Wait for this log line before proceeding:

plausible  | [info] Running PlausibleWeb.Endpoint with cowboy 2.x.x at 0.0.0.0:8000

Plausible runs on localhost:8000 by default.

Step 5: Reverse Proxy with Caddy (Automatic SSL)

Caddy is the simplest option for HTTPS — it automatically provisions and renews Let's Encrypt certificates.

# Install Caddy on Ubuntu
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update && sudo apt install caddy

# /etc/caddy/Caddyfile
analytics.yourdomain.com {
    reverse_proxy localhost:8000

    # Optional: block known bot traffic at the proxy level
    @bots header_regexp User-Agent (bot|crawl|spider|slurp)
    respond @bots 403
}

sudo systemctl enable caddy
sudo systemctl restart caddy

# Check Caddy is running and certificate issued
sudo caddy validate --config /etc/caddy/Caddyfile
curl -I https://analytics.yourdomain.com

Alternative: Nginx + Certbot

# /etc/nginx/sites-available/plausible
server {
    listen 80;
    server_name analytics.yourdomain.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name analytics.yourdomain.com;

    ssl_certificate /etc/letsencrypt/live/analytics.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/analytics.yourdomain.com/privkey.pem;

    location / {
        proxy_pass http://localhost:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

# Get SSL certificate
sudo certbot --nginx -d analytics.yourdomain.com
sudo systemctl reload nginx

Step 6: DNS Configuration

Add an A record pointing your subdomain to your server's IP:

Type: A
Name: analytics
Value: YOUR_SERVER_IP
TTL: 300 (or auto)

Propagation typically takes 1–5 minutes. Verify with:

dig +short analytics.yourdomain.com
# Should return your server IP

Step 7: Create Account and Add Site

1. Navigate to https://analytics.yourdomain.com
2. Click Register — create your admin account
3. Click Add Website — enter your domain (yourdomain.com)
4. Copy the tracking snippet

Step 8: Add Tracking Script to Your Site

<!-- Basic tracking — cookieless, under 1KB, no consent banner needed -->
<script defer data-domain="yourdomain.com"
  src="https://analytics.yourdomain.com/js/script.js"></script>

<!-- Enhanced tracking with outbound links, file downloads, and custom events -->
<script defer data-domain="yourdomain.com"
  src="https://analytics.yourdomain.com/js/script.tagged-events.outbound-links.file-downloads.js">
</script>

Custom Event Tracking

// Method 1: Data attributes (no JS required)
<button data-analytics='"Signup", {"props": {"plan": "pro"}}'>
  Start Free Trial
</button>

// Method 2: JavaScript API
window.plausible('Purchase', {
  props: { plan: 'pro', billing: 'annual' },
  revenue: { currency: 'USD', amount: 99.00 }
});

// Method 3: Tagged events (use class="plausible-event-name=EventName")
<a href="/pricing" class="plausible-event-name=Pricing+Click">
  View Pricing
</a>

Step 9: Google Search Console Integration

If you set GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET in your .env:

1. In Plausible dashboard: Site Settings → Integrations → Google Search Console
2. Click Continue with Google — authorize the OAuth connection
3. Select your GSC property from the dropdown
4. Click Save

The Search tab in your Plausible dashboard now shows organic search queries with impressions, clicks, and average position — without leaving Plausible.

Getting OAuth credentials:

1. Go to Google Cloud Console
2. Create or select a project
3. APIs & Services → Credentials → Create Credentials → OAuth 2.0 Client ID
4. Application type: Web application
5. Authorized redirect URIs: https://analytics.yourdomain.com/auth/google/callback
6. Copy Client ID and Client Secret to .env

Step 10: Production Hardening

Backups

Plausible uses two databases. Back up both:

#!/bin/bash
# /opt/plausible-backup.sh

BACKUP_DIR="/opt/backups/plausible/$(date +%Y-%m-%d)"
mkdir -p "$BACKUP_DIR"

cd /opt/plausible-ce

# Backup PostgreSQL (site/user configuration)
docker compose exec -T plausible_db pg_dump -U postgres plausible > "$BACKUP_DIR/postgres.sql"

# Backup ClickHouse (analytics events — the big one)
docker compose exec -T plausible_events_db clickhouse-client \
  --query "BACKUP DATABASE plausible TO File('/var/lib/clickhouse/backup/plausible')"
docker cp plausible-ce-plausible_events_db-1:/var/lib/clickhouse/backup/plausible "$BACKUP_DIR/clickhouse/"

echo "Backup complete: $BACKUP_DIR"

# Add to crontab — daily backup at 2am
echo "0 2 * * * /opt/plausible-backup.sh >> /var/log/plausible-backup.log 2>&1" | crontab -

Updates

cd /opt/plausible-ce

# Pull latest Plausible CE version
git pull

# Pull new Docker images
docker compose pull

# Restart with new images (zero-downtime if using rolling restart)
docker compose up -d

Monitoring

Add Uptime Kuma (open source uptime monitoring) to alert when Plausible goes down:

# Add to your Uptime Kuma configuration
- name: "Plausible Analytics"
  url: "https://analytics.yourdomain.com"
  interval: 60
  maxretries: 3
  notificationId: 1  # Your Slack/email notification

Firewall

# Allow only necessary ports
sudo ufw allow 22    # SSH
sudo ufw allow 80    # HTTP (Caddy redirect)
sudo ufw allow 443   # HTTPS
sudo ufw enable

# Plausible (8000) should NOT be publicly exposed — Caddy proxies it

Resource Usage

Metric	Low Traffic	Medium Traffic	High Traffic
Sites	1–5	5–20	20+
Monthly pageviews	<1M	1–10M	10M+
RAM	512 MB	1–2 GB	4+ GB
CPU	1 core	2 cores	4+ cores
Disk/month	100–500 MB	1–5 GB	10+ GB
VPS cost/month	$5–6	$12–20	$40+

ClickHouse compression is excellent — 10 million events typically use less than 1 GB on disk.

Troubleshooting Common Issues

Plausible not receiving events:

# Check Plausible is running on port 8000
docker compose ps
curl -I http://localhost:8000

# Check Caddy is forwarding correctly
curl -I https://analytics.yourdomain.com

# Check tracking script loads (open DevTools → Network tab → filter "script.js")

ClickHouse health check fails:

# Check ClickHouse logs
docker compose logs plausible_events_db

# ClickHouse needs elevated nofile limits — verify with:
docker compose exec plausible_events_db ulimit -n
# Should return 262144

Email not working:

# Test SMTP from Plausible container
docker compose exec plausible bin/plausible eval "Plausible.Mailer.deliver_now(Plausible.Email.welcome_email(%{email: \"test@example.com\", name: \"Test\"}))"

Why Self-Host Plausible

Plausible Cloud is a well-run, ethical service — the team is small, the product is focused, and the pricing is transparent. But self-hosting offers financial and operational advantages that matter at scale. Plausible Cloud's Growth plan is $19/month for up to 100,000 monthly pageviews. The Business plan is $49/month for 1 million pageviews. For a website or SaaS product with consistent traffic, the annual cloud cost reaches $228–588/year.

Self-hosting Plausible runs on a Hetzner CX22 (€4.50/month) for low-to-medium traffic sites, or a CX32 (€6.49/month) for high-traffic sites processing millions of events monthly. The annual infrastructure cost is $54–78/year — a 75–87% reduction against Plausible Cloud. For companies tracking multiple properties or high-traffic applications, the savings compound further: self-hosted Plausible handles unlimited sites on a single server at the same fixed cost.

Data sovereignty at the tracking layer: Analytics data contains behavioral fingerprints for every user who visits your site — pages visited, referrers, device types, geographic locations, and custom event completions (signups, purchases, form submissions). With self-hosted Plausible, this data never leaves your infrastructure. No Plausible Labs employees can access your visitor data, no data sharing agreements apply, and no vendor breach can expose your users' behavioral patterns. For companies serving EU users under GDPR, hosting analytics within EU infrastructure on your own servers simplifies data processing agreements considerably.

No pageview caps or rate limits: Plausible Cloud enforces monthly pageview limits per plan tier. A traffic spike — a successful launch, a viral post, a mention on a major platform — can push you over your plan limit and trigger billing alerts or service throttling at the worst possible time. Self-hosted Plausible imposes no software-level caps. Your only limit is server capacity, which you control and can scale on demand.

Custom data retention: Plausible Cloud retains data for the lifetime of your account. Self-hosted deployments let you configure ClickHouse retention policies to keep data longer or shorter based on your compliance requirements.

When NOT to self-host Plausible: Plausible requires two databases — PostgreSQL and ClickHouse — which makes it more operationally complex than tools that use a single database. ClickHouse in particular needs memory headroom (1 GB minimum, 2 GB recommended) and occasional tuning for high-traffic deployments. If you're tracking a personal blog or low-traffic site (under 10,000 monthly pageviews), Plausible Cloud's entry pricing ($9/month) may be worth the operational simplicity. Self-hosting is most compelling for teams with existing DevOps capacity monitoring multiple properties or high-traffic applications.

Prerequisites (Expanded)

VPS with 2 GB RAM (ClickHouse needs memory headroom): The RAM requirement is almost entirely driven by ClickHouse, not Plausible itself. ClickHouse is a column-oriented OLAP database optimized for high-speed event ingestion and aggregation queries. It buffers data in memory before flushing to disk and uses memory for query processing. Running ClickHouse on 1 GB RAM is technically possible but causes frequent page faults and slow query responses. 2 GB provides workable headroom; 4 GB is recommended for sites with over 1 million monthly pageviews.

Docker and Docker Compose v2+: Verify you have Compose v2 specifically — not the legacy docker-compose binary. The official community-edition repository uses docker compose (space, not hyphen) syntax. Check with docker compose version. If you only have the old binary, follow the Docker documentation to install the Compose plugin.

Domain name pointed at your server: Plausible's community edition configuration uses your BASE_URL environment variable in many places — SMTP callback URLs, CORS headers for the tracking script, Google OAuth redirect URIs. This URL needs to be the real production URL before you start, not a placeholder. Changing it later requires updating DNS, the .env file, and any registered OAuth credentials.

SMTP credentials: Email is required for account creation, password resets, and weekly email reports. Plausible's community edition has no way to manually create accounts from the CLI — email verification is the only onboarding path. Set up SMTP before your first registration. Resend's free tier (3,000 emails/month) is sufficient for small to medium deployments.

Choosing the right VPS matters more for Plausible than for most tools because ClickHouse is sensitive to storage I/O. NVMe SSD storage (which Hetzner and Vultr offer at their entry tiers) provides much faster analytics query response times than spinning-disk or network-attached storage. See the VPS comparison for self-hosters for storage performance benchmarks across providers.

Production Security Hardening

Plausible collects analytics for every visitor to your site. While Plausible is privacy-first and doesn't track individuals by default, it still holds aggregate behavioral data about your users. Secure the infrastructure appropriately.

Firewall with UFW: Plausible runs on port 8000 internally. After configuring Caddy as your reverse proxy, this port should never be directly accessible.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

PostgreSQL (5432), ClickHouse (8123, 9000, 9009), and the Plausible internal port (8000) should all be blocked from external access. Docker manages internal networking between these containers.

Fail2ban for SSH protection:

sudo apt install fail2ban
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Configure /etc/fail2ban/jail.local to set maxretry = 3 and bantime = 3600 under [sshd].

Keep secrets out of version control: Your .env file contains SECRET_KEY_BASE, TOTP_VAULT_KEY, SMTP credentials, and Google OAuth secrets. This file must never be committed to Git. Add it to .gitignore:

echo ".env" >> /opt/plausible-ce/.gitignore

Disable SSH password authentication:

sudo sed -i 's/#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo systemctl restart sshd

Automatic security updates:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

Harden ClickHouse access: ClickHouse's HTTP interface runs on port 8123 with no authentication by default in the community edition configuration. The included ClickHouse config restricts this to the Docker internal network, but verify that UFW blocks port 8123 from external access after deployment.

For a comprehensive server security checklist covering certificate management, log monitoring, and intrusion detection for self-hosted analytics infrastructure, see the self-hosting security checklist.

Protecting your backup copies is equally important — your ClickHouse analytics data represents months or years of visitor records. Set up encrypted off-site backups using automated server backups with restic, which handles both PostgreSQL and ClickHouse backup procedures with automatic S3 or Backblaze B2 upload.

Community and Support

Plausible has an active community and strong documentation. The official GitHub repository for the community edition is the primary place to report bugs specific to self-hosted deployments. The Plausible community forum covers both cloud and self-hosted questions, and many users share configuration tips, custom event tracking recipes, and integration guides.

When asking for help, always specify the community edition version you're running (git log --oneline -1 in your plausible-ce directory) and include relevant container logs. The Plausible team is responsive to community edition issues but prioritizes issues that include clear reproduction steps and log output.

The best open source monitoring tools article covers pairing Plausible with infrastructure monitoring to understand not just your traffic but the server health behind it. Many operators run Netdata or Uptime Kuma alongside Plausible to catch server issues before they affect analytics collection.

Understanding Plausible's Analytics Model

Plausible takes a philosophically different approach to web analytics than Google Analytics. Understanding these differences helps you know what you can and cannot measure with the platform.

Plausible tracks page views, unique visitors (approximated without persistent identifiers), referrer sources, outbound link clicks, file downloads, and custom events. It does not track individual user sessions across visits, does not build user profiles, and does not use cookies or localStorage for persistent identification. Each page view is processed independently — Plausible uses an anonymized hash of IP + user agent + domain to detect unique visits within a day, then discards that hash. There is no persistent user identifier in the data.

This design makes Plausible legally simpler than cookie-based analytics for EU-based sites under GDPR. No consent banner is required for Plausible's basic tracking because no personal data is stored or cookies set. However, if you add custom events that include user-identifiable information (like email addresses in event properties), you're responsible for your own data handling — Plausible's architecture doesn't prevent you from logging personal data through its custom events API.

Understanding what Plausible measures well and what it doesn't helps you interpret your data correctly. Plausible is excellent for top-level traffic analysis: which pages are most popular, where your traffic comes from, which campaigns are driving visits, and whether your content is trending up or down. It's less suited for deep funnel analysis (multi-step conversion paths where you need to track the same user across many interactions), e-commerce attribution (which ad campaign led to a purchase three days later), or retention analysis (do users come back?). For those use cases, a full-featured analytics system with user identification is more appropriate — though it comes with corresponding privacy and legal complexity.

Scaling Plausible for High-Traffic Sites

Plausible's self-hosted deployment is designed for single-node operation, but ClickHouse scales surprisingly well on modest hardware. Understanding the performance profile helps you size your server appropriately and recognize when you're approaching limits.

ClickHouse is a columnar database optimized for analytics queries. It ingests events extremely efficiently and compresses them significantly — a million page views typically consume 10–50 MB of storage in ClickHouse. Query performance for the standard Plausible dashboard (traffic by page, referrer, country, device) is fast even on 10–20 million monthly page views running on a single VPS, because ClickHouse can scan and aggregate those records in milliseconds using its columnar format.

Memory is the main scaling constraint. ClickHouse performs poorly when it cannot keep its working set in RAM. For sites with up to 5 million monthly page views, 2 GB RAM is sufficient — ClickHouse will use about 1 GB, leaving headroom for PostgreSQL and the Plausible application. For sites with 10–50 million monthly page views, 4 GB RAM is comfortable. Beyond 100 million monthly page views, consider 8–16 GB RAM and a dedicated server rather than sharing with other workloads.

When your site experiences traffic spikes — a viral article, a Product Hunt launch, or a major press mention — Plausible's event ingestion queue handles the burst gracefully. Events are written to an in-memory buffer and flushed to ClickHouse in batches, so sudden spikes don't cause data loss or query degradation. The Plausible container may show higher CPU usage during ingestion spikes, which is expected behavior.

For multi-site deployments (tracking multiple domains on one Plausible instance), the load scales roughly linearly with combined page views across all sites. A Plausible instance tracking 10 sites with 100,000 page views each (1 million total) has similar resource requirements to one tracking a single site with 1 million page views.

Migrating from Google Analytics

If you're moving from Google Analytics to self-hosted Plausible, the migration process is straightforward but requires setting expectations about data availability.

Google Analytics historical data does not automatically transfer to Plausible. You'll have two sets of analytics data: the complete history in Google Analytics (which remains accessible until Google deletes it, typically after account deletion), and new data from the Plausible tracking date forward. Plan your migration timing accordingly — if you care about year-over-year comparisons, install Plausible and run it alongside Google Analytics for at least a few months before removing GA.

The tracking script replacement is a single line change. Remove the Google Analytics gtag.js script tag and replace it with the Plausible snippet from Step 8. For sites using a tag manager (Google Tag Manager), add the Plausible script as a custom HTML tag and remove or disable the Google Analytics tag. For WordPress sites, use the official Plausible WordPress plugin rather than manually editing theme files.

Custom events require mapping from Google Analytics's event model to Plausible's simpler model. Google Analytics 4 uses a complex event model with event parameters; Plausible uses named events with optional string properties. Audit your GA4 custom events and identify which are essential for your business decisions. Implement the most important ones in Plausible first using the window.plausible() API shown in Step 8.

After migration, give your team a two-week orientation period to get comfortable with Plausible's interface. Google Analytics's UI encourages exploration of detailed user journeys and cohort analysis that doesn't exist in Plausible. The adjustment is worth the change — most teams find Plausible's simpler model more actionable for day-to-day decisions, with less time spent interpreting complex reports and more time acting on clear traffic signals.

For privacy-first analytics platforms generally, see the best open source alternatives to Google Analytics — Plausible, Umami, and Matomo each serve different use cases and scale requirements.

Upgrading Plausible

Plausible Community Edition updates are released regularly with new features and security fixes. The upgrade process is designed to be safe, but a few precautions matter.

Before upgrading, check the release notes for breaking changes. Plausible occasionally ships migrations that modify the ClickHouse schema — these run automatically on startup but are irreversible. A backup before upgrading is not optional.

The standard upgrade sequence:

cd /opt/plausible-ce

# Pull latest changes to the community-edition repo
git pull

# Back up both databases before upgrading
docker compose exec -T plausible_db pg_dump -U postgres plausible > backup-postgres-$(date +%Y%m%d).sql
docker compose exec plausible_events_db clickhouse-client \
  --query "BACKUP DATABASE plausible TO File('/var/lib/clickhouse/backup/pre-upgrade')"

# Pull new images
docker compose pull

# Restart with new images
docker compose up -d --force-recreate

# Monitor startup logs for migration success
docker compose logs -f plausible

Watch for migration completion messages in the logs. A successful upgrade shows the application starting and accepting requests on port 8000. If a migration fails, the application will log the error and exit — restore from backup and investigate the issue before retrying.

Troubleshooting Common Issues

Data not appearing in the dashboard after adding the tracking script. First verify the script is loading: open your browser's Developer Tools → Network tab → filter for script.js. If the request returns 404, the domain in your script's data-domain attribute doesn't match a site you've added in Plausible. If the request succeeds but no data appears, check the Plausible server logs (docker compose logs -f plausible) for incoming event processing errors.

ClickHouse container exits immediately on startup. ClickHouse requires elevated file descriptor limits (nofile: 262144). The community edition's Docker Compose file includes the appropriate ulimits configuration, but some container runtimes or cloud providers restrict this. Check docker compose logs plausible_events_db for the exact error. If you see "Too many open files," add --ulimit nofile=262144:262144 to your Docker daemon configuration in /etc/docker/daemon.json.

Custom events not recording. The window.plausible() function is asynchronous and requires the tracking script to be loaded before calling it. If you call window.plausible() before the script tag executes (for example, in a <head> inline script), the function doesn't exist yet. Either ensure your custom event calls happen after the script loads, or use the plausible-event-name CSS class approach which doesn't require JavaScript.

Google Search Console integration shows no data. After connecting GSC, data appears with a 2–3 day delay — GSC data is not real-time. Also verify that the Google account used to authorize the connection has Search Console access to the specific property you're trying to view. GSC permissions are per-property, not per-account.

Password reset emails not arriving. SMTP failures are a common setup issue. Test your SMTP configuration directly from the container: run the test command from the Troubleshooting section above. Common causes: incorrect SMTP port (587 vs 465 vs 25), SSL/TLS configuration mismatch, or SMTP credentials with special characters that need escaping in the .env file.

Related: Matomo vs Plausible: Full-Featured vs Lightweight · Plausible vs Umami vs Matomo: The Three-Way Comparison · How to Migrate from Google Analytics to Umami

Also see: Best open source analytics tools for a full comparison of self-hosted analytics options.

See open source alternatives to Plausible on OSSAlt.