How to Self-Host Plausible Analytics: Setup and Costs

You can run Plausible Analytics on your own server in about an hour with Docker, and keep it healthy with roughly an hour of maintenance a month. The software is free (AGPLv3), the server costs about EUR 6 to 12 a month, and the real price is that you own the backups, the upgrades, and the uptime. This guide covers the full install, the configuration the quickstart skips, a backup and upgrade routine, and an honest cost comparison with Plausible Cloud.

If you are still deciding between Plausible and Google Analytics on privacy grounds, we have a separate breakdown of the cost and privacy trade-offs between Plausible and Google Analytics. This post assumes you have already picked Plausible and want to run it yourself.

What you are actually signing up for

Plausible ships the same codebase two ways. Plausible Community Edition (CE) is the free, self-hosted, AGPL-licensed release. Plausible Cloud is the managed service, and subscription revenue is what funds development of both. That funding model shapes what CE is, and being clear about it up front saves disappointment later.

The differences that matter operationally:

• Release cadence. Cloud is updated continuously, often multiple times a week. CE is a long-term release published twice a year. New features arrive on your server months after cloud users get them.
• Missing features. Marketing funnels, user journeys, ecommerce revenue goals, SSO, and the sites API are not in CE. Everything else, including goals, custom events, email reports, and the stats API, is there.
• Bot filtering. Cloud excludes around 32,000 data center IP ranges and uses behavioural detection across its whole network. CE filters the most common bots by user agent and referrer spam domains only. If your sites sit on cheap hosting and attract scraper traffic, your self-hosted numbers will run slightly inflated.
• Support. CE is community supported through GitHub discussions. There is no vendor support contract at any price.
• Security patches. Plausible is explicit that fixes are not backported. A patch only protects you once you pull the new release yourself.

None of this makes CE a bad product. It makes it infrastructure. If you treat it like a server you maintain rather than software you install once, it works well. That framing comes straight from Plausible's own self-hosting page, and it is the right one.

What you need before you start

The requirements are modest. From the official Community Edition repository:

• A server with Docker and Docker Compose installed. Any modern Linux VPS works.
• A CPU that supports SSE 4.2 (x86) or NEON (ARM). This is a ClickHouse requirement. Anything sold in the last decade qualifies.
• At least 2 GB of RAM. Below that, ClickHouse and the Plausible app will fight over memory and you will see out-of-memory kills. 4 GB is comfortable and leaves room for the OS and other small services.
• A domain or subdomain (for example stats.yourcompany.com) with a DNS A record pointing at the server. You need this before install because Plausible issues its own Let's Encrypt certificate at first boot.
• An SMTP relay for password resets and email reports. More on this below, because it is the piece most guides skip and most installs get wrong.

A 2 vCPU, 4 GB RAM VPS is the right starting size for a handful of low-to-medium traffic sites. Plausible's architecture (Elixir and Phoenix on the app side, PostgreSQL for user and site data, ClickHouse for the event data) is efficient, and the Plausible repo notes this stack is chosen specifically to keep the dashboard fast under load.

Install: the official quickstart, annotated

The official quickstart is genuinely good. Here it is with the decisions explained.

Clone the release, pinned to a specific version:

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

Check the releases page for the current version before you copy that line. Never clone master for production.

Create the environment file with your domain and a secret:

echo "BASE_URL=https://stats.yourcompany.com" >> .env
echo "SECRET_KEY_BASE=$(openssl rand -base64 48)" >> .env

Two details matter here. BASE_URL must be the real domain users will visit, because Plausible uses it for link generation and websocket hijacking checks. SECRET_KEY_BASE must be at least 64 bytes; the openssl rand -base64 48 command produces exactly that. Treat it like a password: it protects dashboard sessions and derives other encryption keys.

Expose the web server with a compose override file:

cat > compose.override.yml << EOF
services:
  plausible:
    ports:
      - 80:80
      - 443:443
EOF
echo "HTTP_PORT=80" >> .env
echo "HTTPS_PORT=443" >> .env

With ports 80 and 443 set, Plausible requests and renews a Let's Encrypt certificate automatically. This only works if DNS already resolves to the server, which is why the DNS record comes first. If you already run Nginx or Caddy on the host for other sites, put Plausible behind it instead using the reverse proxy guide in the project wiki, and skip the port 443 override.

Start it:

docker compose up -d

Visit your BASE_URL, create the first user, add your first site, and paste the tracker snippet into your site's head tag. The tracker itself is MIT-licensed (deliberately, so AGPL does not spread to your site), and it sets no cookies and stores no personal data, which is the whole point of running Plausible.

Configure what the quickstart skips

A default install works, but three configuration jobs turn it into something you can rely on. All settings are environment variables in your .env file, documented in the official configuration reference.

Lock down registration

The default, DISABLE_REGISTRATION=invite_only, means anyone who knows your URL can see the registration page and only invited users can sign up. For a single-company instance, set it to true after your team has accounts:

DISABLE_REGISTRATION=true

There is no reason to leave any registration surface open on the public internet.

Set up email properly

Without SMTP configured, Plausible tries to send mail directly from the server on port 25. Many VPS providers block outbound port 25 by default, and mail that does get out lands in spam without SPF and DKIM records. Password resets and weekly reports will silently never arrive.

Point Plausible at a relay instead:

SMTP_HOST_ADDR=smtp.yourprovider.com
SMTP_HOST_PORT=587
SMTP_USER_NAME=your_username
SMTP_USER_PWD=your_password
MAILER_EMAIL=stats@yourcompany.com
ENABLE_EMAIL_VERIFICATION=true

Any transactional email service works (Postmark, Mailgun, SendGrid, or your existing mailbox provider), and there are dedicated adapters for the big ones. The free tier of any of them covers an analytics instance many times over. Enabling email verification means new users must confirm their address, which closes the loop on the invite flow. If you want to see the same relay discipline applied to a higher-volume sender, our guide to self-hosting a newsletter with Listmonk and Amazon SES walks through SMTP credentials, bounce handling, and DNS records in detail.

Pin your image version

The default compose file tracks the latest tag. Pin a patch version instead, so upgrades happen when you choose:

ghcr.io/plausible/community-edition:v3.2.1

The upgrade guide recommends patch-level pinning for exactly this reason: you read the release notes, then upgrade, rather than discovering a new version because a container restarted.

Backups: the part that decides whether this works

Plausible stores data in two databases, and you need both to restore a working instance:

• PostgreSQL holds users, sites, goals, API keys, and settings. Losing it means re-creating every account and site config by hand.
• ClickHouse holds every pageview and event. Losing it means your history is gone, permanently.

A backup routine that covers both looks like this:

  # PostgreSQL dump
docker compose exec plausible_db pg_dump -U postgres plausible_db | gzip > backups/plausible_pg_$(date +%F).sql.gz

  # ClickHouse backup (also stop writes briefly, or use the clickhouse-backup tool)
docker compose exec plausible_events_db clickhouse-client --query "BACKUP DATABASE plausible_events_db TO Disk('backups', 'ch_$(date +%F).zip')"

Then get the backups off the server. A cron job that dumps both databases nightly and syncs the folder to object storage (S3-compatible buckets cost a few euros a month for this volume) is enough for almost everyone. Snapshots from your VPS provider are a useful second layer but not a substitute: they are tied to the provider and usually expire with the server.

Two habits matter more than the tooling. First, test a restore once, on a spare machine, before you need it. A backup you have never restored is a hypothesis. Second, always take a fresh backup immediately before an upgrade, because that is the moment you are most likely to want one. We use the same pattern across the whole self-hosted stack; the Formbricks self-hosting guide covers an identical database-plus-offsite-copy routine for a different tool.

Upgrades without surprises

CE releases ship twice a year, with occasional patch releases between them. Because security fixes are not backported, applying releases promptly is your only patching mechanism. This is not theoretical: in May 2026 the project shipped v3.2.1 as a dedicated security release, because every version from v3.0.0 through v3.2.0 exposed an HTTP /storybook endpoint that allowed remote code execution on instances reachable from untrusted networks. The only complete fix was upgrading to v3.2.1, per the release notes. Anyone running an unpatched v3.2.0 with ports 80 and 443 open to the internet, exactly as the quickstart sets up, stayed exposed until they pulled the new image. Subscribe to release notifications on the plausible/analytics GitHub repository (Watch, then Custom, then Releases) so you hear about each one.

The routine for a minor or patch release:

cd plausible-ce
docker compose exec plausible_db pg_dump -U postgres plausible_db | gzip > backups/pre_upgrade_$(date +%F).sql.gz
git pull origin v3.2.2        # the new version tag
docker compose up -d          # pulls new images, restarts containers
docker image prune            # remove old images once the new one is healthy

Check the release notes before every upgrade. Minor versions are usually exactly the commands above. Major versions can include data migrations with extra steps, and the release notes spell them out. This is another argument for patch pinning: nothing changes underneath you, and every upgrade is a deliberate, backed-up event.

Budget 30 to 60 minutes a month for this loop plus a quick glance at logs and disk usage. ClickHouse grows with your traffic, so watch disk: when the volume passes 70 percent full, either prune old data (Plausible lets you set per-site data retention) or resize the disk.

What it costs: a worked example

Here is a realistic monthly bill for self-hosting Plausible for a company tracking five marketing sites with a combined 2 million pageviews a month.

• VPS (Hetzner CX23, 2 vCPU, 4 GB RAM, 40 GB NVMe): about $6.30 a month excluding VAT, roughly EUR 5.50. EU locations include 20 TB of traffic, far more than analytics beacons will ever use. Step up to the CX33 (4 vCPU, 8 GB, about $9.75, roughly EUR 8.50) once you pass a few million monthly pageviews or share the box with other tools. Figures from VPS Arena's September 2026 index of Hetzner's own price feed; Hetzner adjusts prices and availability by region, so confirm on hetzner.com/cloud before ordering.
• Backups: 25 GB of object storage plus provider snapshots, about EUR 2 to 4.
• SMTP relay: free tier of a transactional email service, EUR 0.
• Domain: already owned, EUR 0 marginal.

Cash total: roughly EUR 8 to 12 a month, plus 30 to 60 minutes of admin time.

Now the cloud comparison. Plausible Cloud starts at $9 a month on the Starter plan (one site, solo use), $14 for Growth (multiple sites and team sharing), and $19 for Business (funnels, user journeys, revenue tracking), all at the 10,000 pageview tier and climbing as your pageview tier rises, per Plausible's subscription plans documentation and pricing page. Our example's 2 million monthly pageviews across five sites rules out Starter entirely and pushes Growth well up the tiers, so run your own numbers on the pricing page before deciding.

So the honest arithmetic: below a few hundred thousand monthly pageviews, cloud at $9 to 19 a month is cheaper than anyone's time. Self-hosting pays off when you track many sites, when pageview counts push cloud pricing well above the entry tiers, when you already maintain a VPS for other tools, or when data residency requirements rule out a third-party processor entirely. For the wider economics of running several tools this way on shared servers, see our guide to self-hosting your business stack and real server costs.

When self-hosting is the wrong choice

Be honest with yourself on these before installing:

• You need funnels, user journeys, ecommerce revenue tracking, SSO, or the sites API. These are cloud-only. No amount of self-hosting effort adds them to CE.
• Nobody will own the maintenance. An analytics instance that stops receiving events because a disk filled or a certificate renewal failed is worse than no analytics. If there is no named person who applies updates, pay for cloud.
• You run high-traffic sites where bot accuracy matters. Cloud's network-wide bot filtering, built from traffic across all its customers, is not something a single instance can replicate. If ad spend decisions ride on these numbers, cleaner data is worth the subscription.
• Your team has no Linux or Docker experience. The install is easy; the eleventh month is what gets you. Paying $9 a month is cheaper than one emergency call to a consultant.
• You want to support the project. Cloud subscriptions are Plausible's only revenue. If the software saves you money, a subscription keeps it maintained.

Common mistakes

The failure modes people hit with self-hosted Plausible are consistent:

• Cloning master instead of a tagged release. Master can contain unreleased migrations. Always clone the version tag.
• Short or reused SECRET_KEY_BASE. It must be 64 bytes or more, generated fresh. Reusing one from a tutorial (including the example in Plausible's own docs, which they warn about) compromises your sessions.
• Skipping SMTP setup. Everything seems fine until the first password reset, which is usually months later and at a bad moment.
• Backing up only PostgreSQL. The events live in ClickHouse. A Postgres-only backup restores a dashboard with zero history.
• Never upgrading. Because fixes are not backported, a CE instance that has not been updated in a year is running known-vulnerable code. Pin the version, watch releases, upgrade on a schedule.
• Running on 1 GB of RAM. It installs, it works in testing, and then ClickHouse gets OOM-killed under real traffic and events are lost. Start at 2 GB, prefer 4.
• Leaving registration open. Set DISABLE_REGISTRATION=true once your users exist. Public sign-up pages on analytics tools get found by bots quickly.

Frequently asked questions

Is Plausible Community Edition really free? Yes. CE is AGPLv3 open source and you never pay Plausible anything to run it. You pay for your own server, storage, and bandwidth. The managed cloud service is what funds the project's development.

How much traffic can a self-hosted Plausible handle? On a 2 vCPU, 4 GB VPS, comfortably into the low millions of monthly pageviews across several sites. The ClickHouse event store and the Elixir app are both built for high write volumes. When the dashboard slows or disk fills, resize the server before tuning anything else.

Can I migrate from Plausible Cloud to self-hosted, or the reverse? Yes. Plausible supports exporting and importing data in both directions via CSV export and the import tooling. Plan the cutover so the tracker snippet points at the new endpoint the same day, or you will have a gap in your graphs.

Do I need a cookie banner with self-hosted Plausible? Plausible sets no cookies and stores no personal data, which is why sites using it generally do not need an analytics consent banner. Self-hosting does not change that. It does make you the data controller and the data processor, so your privacy policy should name your hosting provider and server location.

What is the difference between Plausible CE and Plausible Cloud? Same codebase, different responsibilities. Cloud is updated continuously and includes funnels, user journeys, ecommerce revenue goals, SSO, the sites API, and network-wide bot filtering. CE is a twice-yearly long-term release you host, patch, back up, and monitor yourself.

Does self-hosted Plausible work behind Cloudflare or Nginx? Yes. Run it behind your existing reverse proxy instead of using the built-in Let's Encrypt handling, following the reverse proxy guide in the Community Edition wiki. One caveat: make sure the proxy passes the real visitor IP through, or your country stats degrade.

Where to go from here

Self-hosted Plausible is one of the easiest entries into running your own stack: one compose file, two databases, an hour a month. The discipline it demands (version pinning, tested backups, scheduled upgrades) is the same discipline every other self-hosted tool will demand, so it is a good place to build the habit. If you would rather have that stack run for you, our managed open-source stack service deploys and operates Plausible alongside Twenty, Chatwoot, Listmonk, Formbricks, and the rest of the self-hosted toolchain, with backups, updates, and monitoring handled. If you want to talk through whether self-hosting or cloud fits your situation, book a call.

Related reading

• Self-Hosting Cal.com: Docker Setup, Licensing and Real Costs