Self-host Plausible Analytics on DigitalOcean 2026 — Complete Guide

Plausible Analytics เป็นเครื่องมือวัดผลเว็บไซต์แบบ open source ที่เน้นความเป็นส่วนตัวของผู้ใช้และไม่ต้องขึ้น cookie consent banner

Plausible Analytics is an open-source, privacy-first website measurement tool that doesn't require a cookie consent banner, and self-hosting it on a DigitalOcean Droplet lets you retain full control of analytics data without reliance on third-party servers. This guide walks through selecting an appropriate Droplet spec, deploying with Docker Compose, installing tracking scripts, and planning long-term data backups.

What is Plausible and how does it differ from Google Analytics? (privacy-first)

Plausible Analytics is an open-source website measurement tool designed as a lighter-weight, privacy-conscious alternative to Google Analytics. Its tracking script weighs under 1KB compared to Google's gtag.js, which is several times larger, minimizing impact on page load time. The key difference is that Plausible uses no cookies and doesn't collect personally identifiable information (PII) such as IP addresses—instead, IPs are hashed immediately and not stored permanently. This means websites using Plausible don't need to display a cookie consent banner under GDPR or ePrivacy Directive, unlike Google Analytics which requires consent in many jurisdictions. The dashboard is designed for single-page readability, showing key metrics like unique visitors, pageviews, bounce rate, and visit duration with breakdowns by source, page, country, and device—no complex multi-layer menus like GA4 that users typically need time to learn. Self-hosting Plausible means all analytics data remains under your control, processed on your own infrastructure, with no limitations on pageviews per month as seen with Plausible Cloud (the hosted service that charges based on traffic volume). The trade-off is that you assume responsibility for server maintenance, security patches, and backups yourself—suitable for teams already equipped with DevOps capabilities or those running Droplets for other services who want to add analytics without incurring additional per-traffic charges.

• No cookies and no PII collection — cookie consent banner not required
• Tracking script under 1KB — less impact on page load than Google Analytics
• Single-page dashboard, easy to read — no complex multi-layer menus like GA4

Recommended Droplet specs

Plausible uses ClickHouse as the primary analytics event database, which requires more RAM than typical web apps even with low traffic. The Plausible team recommends a minimum 2GiB RAM for stable production operation. For small to medium websites with up to roughly 100k pageviews per month, the Basic tier Droplet (Shared CPU) with 2 GiB RAM / 1 vCPU / 50 GB SSD / 2,000 GiB transfer at $12/month is sufficient to run Plausible, PostgreSQL, and ClickHouse together via Docker Compose. For higher traffic or multiple websites on one instance, consider 4 GiB RAM / 2 vCPU / 80 GB SSD / 4,000 GiB transfer at $24/month to give ClickHouse adequate memory for real-time queries without latency issues (pricing as of July 2026—verify current rates at your provider). For Thai users, sgp1 (Singapore) is the recommended region with the lowest latency among DigitalOcean's 15 datacenters; blr1 (Bangalore) is a fallback. When creating the Droplet, enable Cloud Firewall (no extra cost) to restrict open ports to 22 (SSH), 80, and 443 (HTTP/HTTPS) only, and consider a Reserved IP if you need a static address for DNS setup in advance—it's free as long as assigned to an active Droplet. New DigitalOcean users can sign up via a referral link to receive $200 Free Credit → to test before committing.

• Plausible recommends 2GiB RAM minimum because ClickHouse requires more memory than typical web apps
• Light to medium traffic: Basic 2 GiB RAM / 1 vCPU / 50GB SSD at $12/month is sufficient
• High traffic or multiple sites: 4 GiB RAM / 2 vCPU / 80GB SSD at $24/month

Deploy with Docker Compose

After creating a Droplet and installing Docker and Docker Compose, the first step is to clone the official Plausible Community Edition repository with git clone https://github.com/plausible/community-edition.git plausible && cd plausible, then copy the example environment file using cp plausible-conf.env.example plausible-conf.env and edit it to match your actual domain, such as BASE_URL=https://plausible.yourdomain.com, and set SECRET_KEY_BASE with a random string generated via openssl rand -base64 64 | tr -d '\n'. The docker-compose.yml defines three main services: plausible (the main app), plausible_db (PostgreSQL for user accounts and site config), and plausible_events_db (ClickHouse for event data). A sample service definition for the main app looks like plausible: image: ghcr.io/plausible/community-edition:v2 restart: always command: sh -c \"sleep 10 && /entrypoint.sh db createdb && /entrypoint.sh db migrate && /entrypoint.sh run\" depends_on: [plausible_db, plausible_events_db] ports: [\"8000:8000\"]. Once config is ready, start all services with docker compose up -d; the system automatically pulls images and creates database schemas on first run. Check container status with docker compose ps and view logs with docker compose logs -f plausible. When ready, Plausible listens on port 8000 inside the Droplet. The final step is setting up a reverse proxy like Caddy or Nginx with an SSL certificate from Let's Encrypt to expose the service via HTTPS on your configured domain—Plausible requires HTTPS in production. After reverse proxy setup, visiting the domain shows an admin account creation page; enter email and password to access the dashboard.

• Clone the repository with git clone https://github.com/plausible/community-edition.git
• Set BASE_URL and SECRET_KEY_BASE in plausible-conf.env before starting
• docker-compose.yml has 3 main services: plausible (app), plausible_db (Postgres), plausible_events_db (ClickHouse)
• Run with docker compose up -d and check status with docker compose ps

Install tracking script on your website

Once the Plausible server runs with HTTPS, add a new site via the dashboard by clicking Add a website and entering your website domain, such as example.com. The system auto-generates a tracking script that must be placed in the <head> of every page you want to measure. The basic script format is <script defer data-domain="example.com" src="https://plausible.yourdomain.com/js/script.js"></script>, where the data-domain attribute must exactly match the registered domain in your dashboard, and the src must point to your self-hosted instance, not plausible.io. For websites built with frameworks like Next.js, Nuxt, or WordPress, you can place this same script in the main layout file or via a plugin that supports custom script injection into the head. To track custom events like signup button clicks or file downloads, enable the extended script by changing the filename to script.outbound-links.file-downloads.js. After embedding the script and deploying, open your website in a browser and return to the Plausible dashboard—you should see visitor counts increase in real-time within seconds. If you see no data, check whether an ad blocker or browser extension is blocking requests to your Plausible domain, as some extensions that block analytics may block domains containing analytics or stats in the name—which is why some admins choose subdomain names that don't match common filter terms.

• Add a new site via the Add a website button in the dashboard, which auto-generates the script
• Embed the script in the format <script defer data-domain="example.com" src="https://plausible.yourdomain.com/js/script.js"></script> in head
• data-domain must exactly match the registered domain; src must point to your self-hosted instance, not plausible.io

Back up analytics data

Based on real-world use, since all analytics data lives in PostgreSQL and ClickHouse running on your Droplet, backup planning falls entirely on you—there's no auto-backup like cloud services provide. The simplest approach is database-level backup using pg_dump for PostgreSQL via a container command like docker compose exec plausible_db pg_dump -U postgres plausible_db > plausible_db_backup.sql, and for ClickHouse you can use its built-in backup mechanism or export event tables via clickhouse-client on a schedule. Set up a cron job to run these backup commands daily, then upload the resulting files outside the Droplet to protect against total Droplet failure. Another infrastructure-level approach is to attach a DigitalOcean Volume (Block Storage) to your Droplet at $0.10 per GiB per month, mount it as the data directory for ClickHouse and PostgreSQL, and create Volume snapshots at $0.06 per GiB per month—this separates backup from Droplet lifecycle. For full-system backup including config and Docker images, create a Droplet Snapshot at $0.06 per GiB per month, which captures the entire disk state at a given moment; it's ideal for recovery points before major version upgrades (pricing as of July 2026—verify current rates at your provider). Regardless of method, test restore from actual backup files at least once to confirm the recovery process actually works—having backup files alone isn't enough.

1. Database-level backup: pg_dump for PostgreSQL + export ClickHouse event tables as daily cron jobs
2. Store backup files outside the Droplet at all times to prevent total loss if Droplet fails
3. Use DigitalOcean Volumes ($0.10/GiB/month) mounted as data directory, separate from Droplet disk
4. Volume snapshot ($0.06/GiB/month) or Droplet Snapshot ($0.06/GiB/month) for recovery points before major updates
5. Test restore from actual backup files at least once to verify the recovery process truly works

When to use this feature (real-world use cases)

Self-hosting Plausible on DigitalOcean suits specific organizational needs rather than being optimal for everyone. The first group is websites or organizations with strict data residency or compliance requirements—needing all user data on infrastructure they fully control without passing through third-party servers at all, common in healthcare, finance, or government sectors with rigid data policies. The second group is sites with such high traffic that Plausible Cloud's per-pageview pricing clearly exceeds the fixed Droplet cost, since self-hosting has no per-event charges and cost remains constant regardless of traffic volume (as long as Droplet specs can handle it). The third group is teams already running Droplets for their main app who want to add analytics without adding another third-party dependency or privacy policy consideration. Conversely, for small teams without dedicated server management, or websites where traffic volume keeps Plausible Cloud cheaper than a Droplet per month, the hosted Plausible Cloud service may be more cost-effective in terms of time saved avoiding maintenance, security patches, backups, and monitoring. Before committing to self-hosting, assess whether your team has baseline DevOps readiness—comfort with Docker, reverse proxies, SSL certificates, and resource monitoring—since you'll own all responsibility once you self-host.

• Organizations with strict compliance on data residency, needing 100% control—e.g., healthcare, finance, government
• Websites with such high traffic that Plausible Cloud's per-pageview cost clearly exceeds monthly Droplet cost
• Teams already running Droplets who want analytics without adding more third-party services
• Small teams without dedicated server staff, or low-traffic sites—Plausible Cloud hosted may be more economical for time

Common errors and fixes

The most common issue is ClickHouse consuming more memory than your Droplet provides, causing the container to be killed by the OOM (out of memory) killer. Signs include dashboard slow-loading or plausible_events_db container restarting repeatedly. The fix: check memory usage with docker stats, and if Droplet RAM is below 2GiB, resize the Droplet to a higher tier. The second issue is forgetting SMTP configuration in plausible-conf.env, which prevents the system from sending account confirmation emails or weekly reports. Add SMTP variables like SMTP_HOST_ADDR, SMTP_HOST_PORT, SMTP_USER_NAME, and SMTP_USER_PWD matching your email provider. The third is incorrect reverse proxy setup causing mixed-content errors or HTTP/HTTPS redirect loops, usually from BASE_URL not matching the actual access URL or the reverse proxy failing to forward the X-Forwarded-Proto header so the container understands the request came via HTTPS. The fourth is disk filling up from accumulated ClickHouse logs and event data, especially high-traffic sites over many months. Monitor disk space regularly with df -h and plan storage expansion via Volumes before the disk is full. The fifth is neglecting Docker image updates for months, missing critical security patches or bug fixes. Review Plausible Community Edition release notes regularly and schedule updates on a routine cadence.

• ClickHouse consuming excess Droplet memory causing OOM kill—check docker stats and resize Droplet if needed
• SMTP not configured in plausible-conf.env, breaking account confirmation and weekly report emails
• BASE_URL not matching actual URL or reverse proxy not forwarding X-Forwarded-Proto, causing redirect loops

Best practices

To keep your self-hosted Plausible instance stable over the long term, adopt these practices from the start. First, separate PostgreSQL and ClickHouse data directories onto DigitalOcean Volumes instead of the Droplet's main disk, allowing free storage expansion without relocating the Droplet and simplifying separate snapshot backups from system disk. Second, enable DigitalOcean Monitoring (free, includes free Uptime Check) to alert immediately when CPU, memory, or service responsiveness becomes abnormal. Third, set up daily automated cron backup jobs as described earlier and keep at least one backup copy outside DigitalOcean to guard against account-level or region-wide risk. Fourth, restrict admin and API access via Cloud Firewall to open only necessary ports, and consider adding a second layer of basic authentication at the reverse proxy level for sensitive paths. Fifth, use VPC (free private networking) to isolate database instances from application instances if running multiple Droplets, reducing the attack surface exposed to the public internet. Finally, test major version updates on a staging environment before running them on production, especially when migrations involve large database changes, to minimize production downtime during updates. Following these practices consistently helps your self-hosted analytics platform achieve stability comparable to managed cloud services while retaining full data control.

• Separate PostgreSQL/ClickHouse data directories to DigitalOcean Volumes for free storage expansion independent of Droplet
• Enable DigitalOcean Monitoring (free) with Uptime Check for immediate alerts when resources become abnormal
• Set up daily automated cron backups and keep at least one copy outside DigitalOcean

Get $200 Free Credit →