Plausible Analytics をセルフホストする実務メモ

Plausible に何を期待し、何を諦めるか

Plausible Analytics は GA4 の代替ではなく、GA4 で見ていない 8 割を捨てて見ていた 2 割だけ所有するための道具です。Cookie 不要 / GDPR 準拠 / スクリプト約 1.4KB の 3 点に振り切った設計で、機能の網羅性は最初から狙っていません。

私が個人サイトで欲しかったのは次の 3 つだけでした。

• 1 ページの 1 日 PV
• リファラ（どこから来たか）
• 国別の大まかな分布

逆に諦めるのは、ユーザ単位のファネル分析、LTV、コホート分析です。GA4 で出していたグラフの大半は、私には実は読めていなかったし、月に 1 度も開いていませんでした。読めないグラフを「持っている」状態を維持するために gtag.js を 70KB 読み込ませる、というのは合理的ではないと判断しました。

Plausible には公式のホスト版 (Plausible Cloud) と、AGPLv3 で公開されている Community Edition (CE) の 2 系統があります。前者は 2026 年 5 月時点で月額 USD 9 から。後者は自前のサーバで動かす前提で、運用工数と引き換えにライセンス料がかかりません。私が選んだのは後者です。

自宅サーバではなく VPS を選んだ理由

結論から書きます。analytics は計測対象（自分のサイト）より長く生きていないと意味がないため、家庭環境ではなく VPS に置きました。当たり前のようで、最初の 3 日はこれで失敗しました。

最初は自宅の Mac mini (M2、Monterey) で docker compose up -d していたのですが、家のルータを再起動するたびに Plausible が落ちました。私のルータは月に 1 度は機嫌を損ねて再起動するので、データの欠落が発生します。「サイトは落ちていないのに analytics だけ落ちている」のは、運用としては最悪の状態でした。

VPS は Hetzner Cloud の CX22 (ARM64, 2 vCPU, 4GB RAM, €4.51/月) に決めました。決め手は 3 点です。

• ClickHouse の公式 ARM64 イメージが安定している
• Plausible 公式が「最小 4GB RAM」と書いているのを満たす最安構成
• ドイツ / フィンランドのリージョンが GDPR 文脈で説明しやすい

DigitalOcean と Linode も比較しましたが、同スペック比で Hetzner が約 40% 安い。為替やリージョンの好みもあるので決め打ちはできませんが、2026 年 5 月時点の私の手元での比較ではそうでした。

docker-compose 構成と環境変数の勘所

公式 community-edition リポジトリの hosting/docker-compose.yml をそのまま使うのが安全です。ClickHouse / PostgreSQL / Plausible 本体の 3 コンテナ構成で、外向きに開けるのは Plausible の 8000 番だけ。

TLS は Caddy で終端しました。Caddyfile はこれだけです。

analytics.example.com {
  reverse_proxy plausible:8000
}

ハマったのが BASE_URL と SECRET_KEY_BASE の 2 つの環境変数でした。

BASE_URL は 末尾スラッシュなし で https://analytics.example.com と書きます。スラッシュを付けるとログイン後のリダイレクトが二重スラッシュ (https://analytics.example.com//login) になり 404 が返るという、地味で気付きにくい不具合に遭遇しました。私は 30 分くらい怒っていました。

SECRET_KEY_BASE は最低 64 文字のランダム文字列。openssl rand -base64 64 で生成して .env に置きます。dev 環境からコピーしてくる、というのを 1 度やりかけて自分で止めたので一応書いておきます。

メール送信は別途 SMTP を用意します。私は AWS SES を使いましたが、Postmark でも Resend でも何でも構いません。Plausible は招待制 (DISABLE_REGISTRATION=true) で運用するのが現実的で、招待メールが届かないと初期セットアップが詰みます。SMTP を後回しにすると、自分のサイトの analytics に自分でログインできない、という間抜けな状態になります。

ClickHouse の落とし穴と日々の運用

Plausible は集計用に ClickHouse を使っています。MySQL や PostgreSQL の感覚で触ると痛い目を見ます。私が踏んだのは「ディスクが急に膨らむ」現象でした。

/var/lib/clickhouse/data の中の parts ディレクトリが、何もしていないのに GB 単位で増えていきます。原因は ClickHouse の merge（パーティションの結合）が間に合っていないだけで、放っておけば収束しますが、見ていて精神衛生に悪い。月に 1 度、OPTIMIZE TABLE events_v2 FINAL を流すスクリプトを cron に入れて落ち着きました。

バックアップは clickhouse-backup を使って日次で取り、Cloudflare R2 (S3 互換) に投げて 3 世代だけ残しています。GDPR 文脈では「個人データを長く保持しない」ことが運用方針になるため、長期バックアップを取らないこと自体がポリシーの一部です。

監視は最小限です。ディスク使用率と HTTP 200 率の 2 つだけ Uptime Kuma で見ています。この最小構成は、以前 個人サイトの観測 3 点セット で書いた「読まれているか / 壊れていないか / あとから追えるか」の流儀に合わせたものです。Plausible 自体も「監視のために監視する」沼に入らないよう気をつけています。

GA4 と並走させるか、置き換えるか

私は 1 ヶ月だけ並走させてから GA4 を外しました。並走の目的は「数字がどれくらいずれるか」を体感するためで、ずれ幅に納得できなければ Plausible 側を捨てるつもりでした。

結果は次のとおりです。

• PV ベースで Plausible が約 12% 少ない（広告ブロッカーで gtag.js が読み込まれない分を Plausible は拾えていない可能性が高い）
• 直帰率は計測ロジックが違うため直接比較できない
• リファラは Plausible のほうが「Direct」が多い（Cookie が無いため判定が荒い）

12% の差は許容範囲と判断しました。広告も EC も無い個人サイトでは、月の PV が 1,000 か 1,120 かは意思決定を変えません。「先月より読まれているか」「どの記事が読まれているか」が分かれば足ります。

GA4 を外したあと、ページ表示が体感で 200ms ほど速くなりました。gtag.js は約 70KB、Plausible のスクリプトは約 1.4KB。Lighthouse の Performance スコアが 4 ポイント上がり、CLS が 0.02 下がりました。数字としては地味ですが、毎回 50 倍重いスクリプトを配っていたのか、と思うと外して良かったと感じます。

まとめ

Plausible のセルフホストは「自分のサイトの数字を、自分のサーバで持ちたい」人向けの選択肢です。VPS と SMTP の初期セットアップで半日、ClickHouse の挙動に慣れるまで 1 ヶ月、というのが私の体感でした。

GA4 の置き換えではなく、GA4 で見ていない 8 割を捨てる代わりに、見ていた 2 割を所有する選択です。同じ判断が誰にでも当てはまるわけではありませんが、個人サイトで広告も EC も持たないなら、検討に値する選択肢だと思います。