モニタリング · KYC不要
Uptime Kuma をオフショアVPSでホスト
オフショアVPS上で独自のアップタイムモニターと公開ステータスページを運用。エンドポイントリストや身元情報をサードパーティ製SaaSに預ける必要はありません。
概要
Uptime Kumaは、Webサイト、API、TCPポート、DNSレコード、コンテナの稼働状況を監視するセルフホスト型モニタリングツールで、異常が発生すると90種類以上の通知チャネルを通じてアラートを送信します。シンプルなWebダッシュボードを備え、公開または非公開のステータスページを公開できます。バックエンドは単一の組み込みSQLiteデータベースのみで構成されています。
オフショアでホストする理由
監視サーバーには、監視対象のすべてのホスト名・IP・ポート・APIキーなど、インフラ全体の詳細な地図が保存されます。そのため、サーバーがどこにあり、誰が召喚状を出せるかが重要になります。Uptime KumaをノーKYC・暗号資産決済のオフショアVPS上でホストすれば、その資産一覧をSaaSダッシュボードの外、かつ本番環境の管轄外に置くことができ、さらに無制限帯域幅により継続的なポーリングも追加コストなしで行えます。
デプロイ
実際に動作するリファレンス構成
これを新しいChainVPSインスタンスにコピーしてください。プレースホルダーを置き換えてから起動します。
# 1) Install Docker + compose plugin (Ubuntu 24.04)
# curl -fsSL https://get.docker.com | sh
#
# 2) docker-compose.yml — Uptime Kuma behind Caddy for automatic HTTPS
# Replace status.example.com with your domain (A record -> this VPS).
services:
uptime-kuma:
image: louislam/uptime-kuma:1
container_name: uptime-kuma
restart: unless-stopped
volumes:
- ./uptime-kuma-data:/app/data
# Bound to loopback: only Caddy reaches it, never the public internet.
ports:
- "127.0.0.1:3001:3001"
caddy:
image: caddy:2
container_name: caddy
restart: unless-stopped
ports:
- "80:80"
- "443:443"
volumes:
- ./Caddyfile:/etc/caddy/Caddyfile:ro
- caddy-data:/data
- caddy-config:/config
volumes:
caddy-data:
caddy-config:
# 3) Caddyfile (same directory) — TLS is issued automatically:
# status.example.com {
# reverse_proxy uptime-kuma:3001
# }
#
# 4) docker compose up -d
# Open https://status.example.com and create the admin user
# on first visit (do this immediately — the setup screen is unauthenticated).ファイアウォール
開放するポート
| ポート | プロトコル | 用途 |
|---|---|---|
| 3001 | TCP | Uptime KumaのWeb UI / WebSocket — 127.0.0.1にバインドしたままにし、絶対に公開しないこと |
| 443 | TCP | リバースプロキシ(Caddy/nginx)経由のHTTPS — ユーザーが必要とする唯一のインバウンドポート |
| 80 | TCP | HTTP。ACME/Let's Encrypt証明書の発行と443へのリダイレクトにのみ使用 |
適正サイジング
必要なプラン
VPS Nano / Small (1 vCPU, 1-2 GB RAM)
個人利用向け。60秒間隔で最大約50件のモニターまで。Uptime Kumaのアイドル時メモリ使用量は数百MB程度です。
VPS Pro (2-4 vCPU, 4-8 GB RAM)
小規模チーム向け。数百件のモニターに加え、複数の公開ステータスページと高頻度チェックに対応。
VPS Pro（大容量構成）またはエントリーモデルのDedicated
短い間隔で1000件以上のモニターを運用する場合。ボトルネックとなるのはSQLiteの書き込み競合です。高速なNVMeと専有のCPUコアを割り当て、RAMを増やす前にまずチェック間隔を延ばしてください。
最適なロケーション: エンドポイントの全リストを保存するサーバーが友好的な管轄区域に置かれるよう、プライバシー階層のロケーション(NL、CH、RO、IS、MD、LU)を選びましょう。NLとCHは接続性にも優れており、プローブのレイテンシを低く保ち、誤検知アラートを減らせます。監視対象が特定のリージョンに集中している場合は、その近くの接続性の良いロケーションを選ぶことで、最も正確な稼働/停止シグナルが得られます。
セキュリティを固める
セキュリティ強化チェックリスト
- ポート3001は絶対にインターネットに公開しないでください。前述の通り127.0.0.1にバインドし、UIへのアクセスはTLSリバースプロキシ経由のみに限定します。UFWルールでは80/443とSSHのみを許可してください。
- `up -d` の直後、初回アクセス時にすぐ管理者アカウントを作成してください。初期セットアップ画面には認証がないため、あなたより先にUIを開いた人物にインスタンスを乗っ取られる可能性があります。作成後はSettings > Securityで2FAを有効化してください。
- ./uptime-kuma-data は定期的にバックアップしてください(単一のSQLite DBです)。コピー前にはコンテナを停止するか、Uptime Kuma組み込みのバックアップ機能を使用し、書き込み途中の不完全なデータベースを避けてください。バックアップは監視サーバー自体とは別の場所に保管します。
- 公開ステータスページは最小限の情報にとどめてください。内部のホスト名やIPが漏洩する可能性があります。非公開ステータスページやページ単位のアクセス制御を使用し、モニターには実際のサーバーホスト名ではなく汎用的な表示名を付けましょう。
- アラートは個人のメールアドレスではなく、身元に紐づかないチャネル(専用のTelegramボットやセルフホストのApprise/ntfyなど)経由で送信し、DB内の通知トークンは機密情報として扱ってください。
- イメージはメジャータグ `1` に固定し、`docker compose pull && up -d` を定期的に実行してください。Uptime Kumaは活発に開発が続いているため、プロジェクトのリリースノートも注視しましょう。
質問
ホスティング Uptime Kuma — FAQ
Uptime Kumaに別途データベースサーバーは必要ですか?
いいえ。/app/data に保存される組み込みのSQLiteデータベースを使用するため、単一のコンテナとデータボリュームだけで構成が完結します。そのため、モニター数が多い場合はRAMの量よりも高速なディスクの方が重要になります。
ポート3001を直接公開せず、Caddyやnginxの背後に置くのはなぜですか?
Uptime Kumaはポート3001で平文のHTTPのみを提供し、独自のTLSは持ちません。リバースプロキシを使うことで自動的にHTTPS化され、アプリをループバックに留めたままアクセス制御も追加できます。3001を直接公開すると、管理者ログイン情報が暗号化されていないHTTPで送信されてしまいます。
ChainVPSのサーバーから、他国にあるサーバーを監視できますか?
はい。監視はアウトバウンド通信で行われ、VPSからHTTP(S)、TCP、ICMP ping、DNSなどを通じて監視対象にアクセスします。無制限帯域幅により頻繁なチェックでも追加コストは発生せず、接続性の良いロケーションを選べばレイテンシに起因する誤検知アラートも抑えられます。
実際のところ、リソースはどれくらい消費しますか?
モニターが数件程度のアイドル状態のインスタンスであれば、単一vCPU上で200〜400MB程度のRAMで十分に動作します。使用量はモニター数と実行頻度に応じて増加するため、ハードウェアを増強する前にまずチェック間隔を延ばすことを検討してください。
ステータスページやエンドポイントリストは非公開に保てますか?
それは完全にあなたの管理下にあります。ステータスページはオプトイン制で非公開にでき、モニターリストはVPS上のSQLiteデータベースにのみ保存されます。ノーKYCのオフショアホストであれば、監視対象のデータがサードパーティ製SaaSにコピーされることも、アカウントに身元情報が紐づくこともありません。
セルフホストをもっと見る