Uptime Kuma の VPS 構築：Docker Compose・Caddy・通知

Uptime Kuma は、HTTP(S)、TCP、ping、DNS、WebSocket などのチェックに対応したオープンソースのセルフホスト型監視ツールです。別の VPS に置いておけば、本番サーバーが落ちたときに一緒に消えるのではなく、チェックを続けてくれます。

この Uptime Kuma の VPS 構築手順では、Docker Compose で v2 をデプロイし、3001 番ポートをループバックに限定し、Caddy で HTTPS を追加し、通知を Telegram・Discord・Slack に振り分け、ステータスページを公開します。

前提条件と必要なもの

1 vCPU、1 GB RAM、ローカル SSD 10 GB 以上の VPS
Ubuntu 24.04 LTS、または Docker がサポートする最新の Ubuntu リリース
VPS にインストール済みの Docker Engine と Docker Compose
A レコードで VPS を指すドメインまたはサブドメイン（status.example.com など）
SSH アクセスと、コマンドラインの基本的な操作に慣れていること

Docker がまだインストールされていない場合は、 Docker の Ubuntu インストールガイドを参照してください。Docker Engine と、以下で使用する Compose プラグインがインストールされます。

監視用 VPS を監視対象から分離すべき理由

Production in Region A has failed and its website, API and database are down, while Uptime Kuma on a separate VPS in Region B stays online, keeps probing those services and routes alerts to Telegram, Discord and Slack. An external watchdog checks Uptime Kuma itself.

本番環境と監視を同じサーバーに置くと、両者は同じ障害ドメインに入ります。そのサーバーが停止すれば、アプリケーションと、その障害を知らせるはずのシステムが同時に失われます。

これを改善する実用的な構成が 2 つあります。

同じプロバイダーの別ロケーション。 本番環境と監視は、異なるロケーションの別ホストに配置します。これで単一サーバーや単一データセンターの障害の影響は減りますが、プロバイダー全体に及ぶネットワーク障害やコントロールプレーンの障害まで防げるわけではありません。
まったく別のプロバイダー。 監視を別のプロバイダーに置けば、プロバイダー全体を巻き込む障害にも備えられます。その代わり、管理すべきアカウントと請求と運用対象が 1 つ増えます。

Uptime Kuma が 1 台だけでは、外部からの監視役がいない状態のままです。公開ステータスページに対する外部からの HTTP(S) チェックを 1 つ追加しましょう。 UptimeRobot の無料プランは現在、5 分間隔のモニターを 50 個まで利用できます。これで Uptime Kuma が高可用性になるわけではありませんが、監視そのものが落ちたときに気づけます。

同じ原則は公開ステータスページにも当てはまります。障害を知らせる側は、障害を起こす側と同じ障害ドメインにあってはいけません。

root権限、NVMe、AMD EPYCのパワーを備えたLinux VPSで開発を。

Linuxプランを見る

VPS のサイジング

Uptime Kuma には「監視数あたりのメモリ量」といった当てになる目安はありません。負荷は監視の種類、実行間隔、リトライ設定、履歴の保持期間で変わるからです。HTTP(S)、TCP、ping、DNS といった単純なチェックは、Chromium を起動する Browser Engine のチェックより軽く済みます。

基本的なチェックが数個であれば、1 vCPU、1 GB RAM、ローカル SSD から始めれば十分です。実際の使用量は docker stats uptime-kuma で、データベースの増加は du -sh /opt/uptime-kuma/dataで確認します。使用量が高いままのとき、コンテナが OOM kill を報告したとき、または Browser Engine のチェックを追加するときは、メモリを増やしてください。

フル版の v2 イメージには Chromium と組み込みの MariaDB が含まれています。 Docker タグのドキュメントがフル版とスリム版イメージの違いを説明しています。

Docker Compose で Uptime Kuma をデプロイする

以下の内容を /opt/uptime-kuma/ に docker-compose.yml として保存します。

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      # Bind to localhost only. The reverse proxy will expose it on 443.
      - "127.0.0.1:3001:3001"
    volumes:
      - ./data:/app/data

特に押さえておきたい行が 3 つあります。

image: louislam/uptime-kuma:2 はメジャーバージョンを固定します。:2 タグは安定版の 2.x 系を追跡します。:latest は使わないでください。
127.0.0.1:3001:3001 はコンテナを localhost のみにバインドします。公開インターネットから 3001 番ポートへ直接到達できてはいけません。TLS 証明書と公開ホスト名はリバースプロキシ側が持ちます。
data ボリュームにはデータベース、監視設定、履歴が保存されます。これはローカルストレージ上に置いてください。Uptime Kuma のインストールドキュメントには、信頼できる POSIX ロックのないファイルシステム（多くの NFS 構成を含む）では SQLite が破損しうると書かれています。ファイルシステムレベルでコピーを取る前に、スタックを停止してください。

起動して確認します。

sudo install -d -o "$USER" -g "$USER" /opt/uptime-kuma
cd /opt/uptime-kuma
# Paste the docker-compose.yml file above.
sudo docker compose up -d
sudo docker compose ps

docker compose ps の想定出力：

NAME          IMAGE                       STATUS                   PORTS
uptime-kuma   louislam/uptime-kuma:2      Up (healthy)             127.0.0.1:3001->3001/tcp

初回にダッシュボードへアクセスするときは、ほんの一時でも 3001 番ポートを公開インターネットに開けないでください。SSH トンネル経由で接続します。

ssh -L 3001:127.0.0.1:3001 [email protected]

ブラウザで http://localhost:3001 を開き、管理者アカウントを作成し、強力なパスワードを設定して、トンネルを閉じます。以降は、リバースプロキシ経由の HTTPS でダッシュボードにアクセスできます。

手動で Compose を用意する必要がなければ、 Uptime Kuma ワンクリックアプリもご用意しています。現在のアプリページの表記は v1 のため、本記事の v2 の Compose 構成とは一致しません。どうしても v2 が必要な場合は、手動の Compose 手順を使ってください。

リバースプロキシと TLS

Public traffic reaches Caddy on the host or an Nginx Proxy Manager container over HTTPS on port 443. Caddy forwards to Uptime Kuma on 127.0.0.1:3001 while the NPM container uses a shared Docker network instead. Public access to port 3001 is blocked, and first-time setup runs through an SSH tunnel to localhost:3001.

Uptime Kuma を直接公開してはいけません。TLS、まっとうな URL 処理、そして公開用の入口を 1 か所に絞るために、前段にリバースプロキシを置きます。方法は 2 つです。

Caddy。 Caddy がまだ入っていない場合は、公式の Ubuntu パッケージ手順に従ってください。Caddy をホスト側のサービスとして動かしていれば、以下の Caddyfile がループバック上の Uptime Kuma へプロキシし、証明書の発行と更新も自動で処理してくれます。

ヒント：監視用 VPS で動かすのが Uptime Kuma だけなら、Caddy を使いましょう。Caddyfile はたった 3 行で済み、証明書の発行と更新も Caddy が自動でやってくれます。Certbot も、朝 4 時に様子を見に行く更新タイマーも不要です。

以下を /etc/caddy/Caddyfile として保存します。

status.example.com {
    reverse_proxy 127.0.0.1:3001
}

Caddy を再読み込みします。

sudo systemctl reload caddy

確認します。

curl -I https://status.example.com

有効な証明書とともに 2xx または 3xx の成功レスポンスが返るはずです。接続に失敗する場合は、ドメインの A または AAAA レコードがこの VPS を指しているか、80 番と 443 番ポートに到達できるか、Caddy が両方のポートをバインドできるかを確認してください。これらは Caddy の自動 HTTPS の要件です。.

Nginx Proxy Manager。 NPM をホスト上で直接動かしている場合は、status.example.com 用の Proxy Host を追加し、127.0.0.1 のポート 3001 に転送して、Let's Encrypt 証明書を要求し、Websockets Support を有効にします。NPM を Docker で動かしている場合、127.0.0.1 は NPM コンテナ自身を指してしまいます。その場合は NPM と Uptime Kuma を同じ Docker ネットワークに接続し、プロキシホストの転送先を uptime-kuma のポート 3001 にしてください。

通知の振り分け：Telegram・Discord・Slack

Uptime Kuma は、同じ監視イベントを複数の通知チャンネルに振り分けられます。各プロバイダーを一度設定しておき、あとは「誰に知らせたいか」に応じて監視項目にチャンネルを 1 つ以上ひも付けるだけです。

通知は 設定 > 通知で全体設定してから、個々の監視項目に割り当てます。1 つの監視項目から 1 つでも複数でもチャンネルを鳴らせます。同じアラートを、オンコール担当には Telegram、チームには Slack、監査ログ用にはメールへと、1 つのイベントからまとめて飛ばせます。

Telegram で @BotFather にメッセージを送り、/newbot を実行します。名前とユーザー名を決めると、BotFather がボットトークンを返してきます。これを保管しておきます。
作成したボットに何でもいいのでメッセージを送ります。次にブラウザで https://api.telegram.org/bot<YOUR_TOKEN>/getUpdates を開き、chat.id フィールドを探します。これがチャット ID です。
Uptime Kuma 側の操作： 設定 > 通知 > 通知を設定 > Telegram。ボットトークンとチャット ID を貼り付けます。次に テストをクリックし、ボットからテスト通知が届くことを確認します。
テストメッセージが届かない場合は、ボットトークンとチャット ID が正しいかを確認し、VPS のファイアウォールが api.telegram.org への外向き HTTPS を許可しているかを確かめてください。

Discord

アラートを受け取りたい Discord サーバーを開きます。対象チャンネルを右クリックし、 チャンネルの編集 > 連携サービス > ウェブフック > 新しいウェブフックを選びます。名前を付け（「Uptime Kuma」など）、チャンネルを選び、ウェブフック URL をコピーします。
Uptime Kuma 側の操作： 設定 > 通知 > 通知を設定 > Discord。ウェブフック URL を貼り付けます。必要ならユーザー名とアバターも設定できます。
クリック テストをクリックし、ウェブフックがテスト通知をチャンネルに投稿することを確認します。

Slack

Slack では、 Incoming Webhook を、アラートを受け取りたいチャンネル向けに作成します。Slack からは https://hooks.slack.com/services/T.../B.../.... という形式のウェブフック URL が返ってきます。
Uptime Kuma 側の操作： 設定 > 通知 > 通知を設定 > Slack。ウェブフック URL を貼り付けます。必要ならアイコンとチャンネルの上書きも設定できます。
クリック テスト.

すべてのテストが通ったら、各監視項目を編集して使用する通知チャンネルを選びます。一時的な 1 回の失敗ですぐアラートが飛ばないよう、 Max Retries（最大リトライ回数） と Retry Interval（リトライ間隔） を設定しておきます。

組み込みのステータスページ（と、それでは足りなくなるとき）

Uptime Kuma には、カスタムスラッグ、監視項目のグループ化、独自ドメイン、障害報告の投稿、計画メンテナンスの告知に対応した公開ステータスページが備わっています。1 つのインスタンスから、サービスごと・読み手ごとに複数のステータスページを公開することもできます。

より大きな制約は、顧客への告知まわりです。訪問者がステータスページから直接メールで更新を購読することは今のところできず、公開ページも運用者用ダッシュボードと同じ Uptime Kuma アプリケーションの一部のままです。訪問者による自己購読は、今も未対応の機能リクエスト.

顧客向けの購読機能や、監視ダッシュボードから切り離したステータス基盤が必要なら、Kener が選択肢の 1 つです。この 2 つをどう組み合わせるかは、セルフホスト型監視スタックで解説しています。

よくある問題

VPS のファイアウォールが外向き HTTPS を塞いでいると、通知は何も言わずに失敗します。 症状：Test ボタンが一部のチャンネルでは通り、他では通らない。対処：外向き HTTPS 接続が許可されているか、VPS から curl -I https://api.telegram.org が成功するかを確認します。

ブラウザに「ERR_TOO_MANY_REDIRECTS」が出る というエラーは、プロキシを有効にした後に出ることがあります。Caddy、Nginx Proxy Manager、あるいは前段の CDN に HTTP から HTTPS への重複したリダイレクトがないか確認してください。Uptime Kuma は 3001 番ポートで HTTP を返し続け、TLS の終端は公開側のリバースプロキシが担当する形が正解です。信頼するプロキシヘッダーを有効にする場合、現在のパスは 設定 > Reverse Proxy > HTTP Headers > Trust Proxy です。

コンテナが数分おきに再起動する。 まず、コンテナがメモリ不足で終了させられたのかを確認し、次に docker stats uptime-kuma で現在の使用量を見ます。OOM kill されていた場合や、メモリが VPS の上限近くに張り付いている場合は、RAM を増やすか、重いチェックを減らすか、その実行間隔を広げてください。

ステータスページは localhost では表示できるのに、公開ホスト名では表示できない。 リバースプロキシがルートパスをそのまま転送しているか、Host ヘッダーを保持しているか、WebSockets に対応しているかを確認してください。Uptime Kuma はサブディレクトリ配下へのインストールに対応していないため、example.com/uptime-kuma のようなパスではなく、専用のドメインまたはサブドメインを使ってください。

まとめ

Uptime Kuma を独立した VPS で動かせば、チェック内容、通知の経路、公開ステータスページを自分の手で決められます。その代わり、アップデート、バックアップ、OS のパッチ適用、そして監視そのものを見張る外部のウォッチドッグまで自分の担当になります。本番とは別のロケーションの VPS を選び、Docker Compose で v2 をデプロイするか、表示バージョンを確認したうえでワンクリックアプリを使い、前段に Caddy を置いて、チームが実際に見ているチャンネルにつないでおきましょう。

よくある質問

Uptime Kuma にはどれくらいのメモリが必要ですか？

Uptime Kuma には「監視数あたりのメモリ量」という当てになる式はありません。使用量は監視の種類、チェック間隔、リトライ設定、履歴の保持期間、Browser Engine を使うかどうかで変わるからです。基本的なチェックが数個程度なら、まず 1 GB のメモリで始め、docker stats uptime-kuma で実際の使用量を見てください。使用量が上限近くに張り付く場合や、コンテナが OOM kill される場合はメモリを増やします。

Uptime Kuma はアプリと同じサーバーで動かしてもいいですか？

いいえ。監視ツールとアプリケーションが同じサーバーにあると、障害時に両方が同時に落ち、いちばん必要なタイミングで通知が失われます。Uptime Kuma は別の VPS で、できれば別のデータセンターのロケーションで動かしてください。

Uptime Kuma は Telegram・Discord・Slack にアラートを送れますか？

送れます。Telegram・Discord・Slack は、メール、汎用ウェブフック、PagerDuty、ntfy、Mattermost などと並ぶ標準搭載の通知サービスです。Telegram はボットトークンとチャット ID を使い、Discord と Slack はウェブフック URL を使います。同じ監視項目に複数の通知チャンネルをひも付けることもできます。

Uptime Kuma と UptimeRobot は何が違いますか？

Uptime Kuma はセルフホストなので、サーバー、アップデート、バックアップ、通知の経路はすべて自分で管理します。チェック間隔は最短 20 秒まで設定できます。UptimeRobot はホスティング型の SaaS で、現在の無料プランは 5 分間隔のモニターを 50 個まで含みます。主導権が欲しいなら Uptime Kuma、監視サーバーの面倒を見たくないなら UptimeRobot を選びましょう。

Uptime Kuma に公開ステータスページはありますか？

あります。どの監視項目を見せるかを選び、グループ化し、複数のステータスページを公開し、独自ドメインに割り当て、メンテナンス告知を予約することもできます。ただし訪問者がメールで自ら購読する機能は標準では備わっていないため、顧客に更新を購読してもらう必要がある場合は、顧客向けのステータスページ専用ツールを別に用意してください。

VPS に Uptime Kuma を構築する方法