Supabaseをセルフホストして実機検証｜8GBのVPSにDockerで構築、メモリ約1GB・つまずいたのは安全設定【2026年版】
2026-10-21
※2026年10月7日時点の情報です。Supabase の公式リポジトリにある docker-compose（Studio 2026.09.07、Postgres 17.6）を弊社のサーバーで動かして確認しました。構成やクラウド版の料金は変わるため、最新の内容は公式ドキュメントと料金ページで確認してください。
Firebase の代わりを探すと、まず名前が挙がるのが Supabase です。オープンソースで、自分のサーバーにセルフホストもできます。ただ、日本語の構築記事は手順の写しが多く、どれだけメモリを使い、どこで失敗するのかを実測したものはほとんどありません。そこで弊社で、公式の docker-compose を2コア・8GB の VPS に立てて確認しました。
結論：Supabaseのセルフホストは8GBのVPSで軽く動く。難しいのは安全設定
- 11個のコンテナが約50秒で起動し、メモリは約1.0GB。2コア・8GB の VPS で余裕がある
- Docker イメージは約9.2GB。公式の最小要件はメモリ 4GB・SSD 40GB
- 公式の compose は API（8000）と DB（5432・6543）をインターネットに全公開する。弊社はこれで約3分間、既定の鍵のまま外に開けてしまった
- 鍵・パスワードの既定値はすべて公開情報。公式も「この既定値で起動してはならない」と明記している
- 費用だけなら、クラウド版の Free か Pro（月25ドル）の方が安い。セルフホストの理由はデータの置き場所と制限の無さ
Supabaseのセルフホスト構成：11個のコンテナは何をしているか
Supabase は1つのアプリではなく、Postgres を中心にした部品の集まりです。公式の docker-compose.yml には11個のサービスが定義されています（2026年10月7日に GitHub で確認）。
| サービス | 役割 | 実測メモリ |
|---|---|---|
| db（postgres 17.6） | 本体のデータベース | 131MB |
| api-gw（envoy 1.39） | API の入口（8000番）と Studio の Basic 認証。旧 Kong の後継 | 43MB |
| rest（PostgREST 14） | テーブルをそのまま REST API にする | 19MB |
| auth（gotrue 2.196） | ユーザー登録・ログイン・JWT 発行 | 13MB |
| realtime 2.134 | 変更通知・WebSocket | 204MB |
| storage 1.74＋imgproxy 3.31 | ファイル保存と画像変換 | 226MB＋72MB |
| functions（edge-runtime 1.76） | Edge Functions の実行 | 40MB |
| supavisor 2.9 | 接続プーラー（5432・6543番） | 183MB |
| meta（postgres-meta 0.99） | Studio がテーブル定義を読む API | 109MB |
| studio 2026.09.07 | 管理画面 | 254MB |
公式は Firebase との違いを「Postgres の上に作られたオープンソースの代替で、Docker で自分でホストできる」と説明しています（2026年10月7日に公式の比較ページで確認）。ライセンスは Apache-2.0 で、商用利用に追加条件はありません。
Supabaseをdocker-composeで構築した手順と実測値
公式の手順は、リポジトリを取得 → docker/ の中身をプロジェクト用フォルダにコピー → cp .env.example .env → docker compose pull → docker compose up -d です。要件は最小でメモリ 4GB・2コア・SSD 40GB、推奨は 8GB・4コア・SSD 80GB 以上（2026年10月7日に公式ドキュメントで確認）。弊社の環境は、さくらのクラウドの2コア・8GB・SSD 40GB です。同居していた Immich を停止し、素の状態（0.5GB）を差し引いて計測しました。
| 項目 | 実測値 |
|---|---|
| Docker イメージ（11個の合計） | 約9.2GB（studio 1.69GB・postgres 1.69GB・supavisor 1.42GB・storage 1.31GB・edge-runtime 1.12GB など） |
| 起動時間 | up -d の戻りと API ゲートウェイの応答が20秒。全11コンテナが healthy になるまで約50秒 |
| メモリ（Supabase 分） | 約1.0GB（全体 1.5GB − 素の状態 0.5GB）。コンテナ別の値の合計は約1.3GB で、共有分を重複して数える分だけ大きい |
| ディスク使用量 | 約21GB（停止中の Immich 5GB を含む） |
ただし利用者0・データなしの値で、Realtime の接続やファイル保存が増えれば変わります。イメージの取得時間は、途中で再起動をはさんだため測れていません。
弊社がやらかした「3分間の全公開」と、既定の鍵の差し替え
ここが本記事でいちばん伝えたい点です。公式の docker-compose.yml は、api-gw の 8000番、supavisor の 5432番と 6543番を 0.0.0.0 で公開しています（2026年10月7日に GitHub で確認。127.0.0.1 に限定した行はありません）。しかもポートの行は入れ子の既定値で書かれています。
ports:
- ${API_GW_HTTP_PORT:-${KONG_HTTP_PORT:-8000}}:8000/tcp弊社は「8000」を 127.0.0.1 付きに置き換えたつもりでこの書き方を見落とし、起動から約3分間、8000番が既定の認証情報のままインターネットに開いた状態になりました。ufw で閉じていても、Docker が公開したポートはその手前で通ります。気づいて止め、ポートを閉じてから立て直しました。
もう1つが鍵です。.env.example の JWT シークレット・anon キー・service_role キー・DB とダッシュボードのパスワードは、すべて GitHub で公開されている値です。公式ドキュメントも「例として置いたパスワードと鍵のまま起動してはならない」と書き、生成スクリプト（utils/generate-keys.sh）を用意しています。公開する前に、最低限この順で進めてください。
- 起動前に
.envの鍵とパスワードを生成した値に差し替える - ポートの行を
127.0.0.1:8000:8000のように書き換える。5432・6543 も同じ - 外からは SSH トンネルか、HTTPS を付けたリバースプロキシ経由だけにする
- 起動後に外部からポートを確認し、開いていないことを確かめる
公式ドキュメントにファイアウォールの節はなく、「ポート・DNS・ファイアウォールの基礎を理解していること」が前提に書かれているだけです。手順通りに進めると全公開になると知った上で始めてください。
動作確認：psqlでテーブルを作ってRESTで読む。つまずいたのはキャッシュ更新
鍵を差し替えてから API を確認しました。認証なしで /rest/v1/ を叩くと 401、.env の anon キーを付けると通ります。次に psql で public.memo テーブルを作って2行入れ、anon ロールに select を許可しました。ところが REST から読むと「schema cache にテーブルが無い」（PGRST205）というエラーになります。PostgREST はテーブル定義をキャッシュしているため、psql で直接作ったテーブルは反映されていません。
NOTIFY pgrst, 'reload schema';これを psql で実行すると反映され、GET /rest/v1/memo?select=id,title が30ms で JSON を返しました。日本語のデータも問題ありません。Studio から作れば自動で反映されるので、つまずくのはSQL で直接いじる人だけです。
もう1点、このテーブルには Studio で「RLS disabled」の赤いバッジが付きます。行レベルセキュリティが無効で、anon キーを知っていれば誰でも全行を読める状態です。anon キーはアプリに埋め込む前提の鍵なので、公開するテーブルには RLS のポリシーを必ず付けてください。
Studioの画面：クラウド版と同じ構成で、英語のみ
管理画面の Studio は、api-gw の Basic 認証（DASHBOARD_USERNAME／DASHBOARD_PASSWORD）の後ろにあります。この既定値も公開値なので差し替えが必要です。
ホームには「Get connected」として Framework／Server／Direct／ORM／MCP／API Keys の6つの入口が並び、左メニューは Table Editor／SQL Editor／Authentication／Storage／Edge Functions などクラウド版とほぼ同じ構成です。日本語の UI はなく、すべて英語です。
Table Editor で memo テーブルを開くと、psql で入れた「検証メモ1」「検証メモ2」が表示されます。上部の「RLS disabled」が前の節の警告です。
Supabaseのクラウド版の料金と、セルフホストの損益分岐
クラウド版の料金は次の通りです（2026年10月7日に公式の料金ページで確認。請求はドル建て）。
| プラン | 月額 | 主な制限・内容 |
|---|---|---|
| Free | 0ドル | アクティブなプロジェクトは2つまで。DB 500MB・ファイル 1GB・転送 5GB・MAU 50,000。1週間使わないと一時停止 |
| Pro | 25ドル〜 | DB ディスク 8GB（超過 1GB あたり 0.125ドル）・転送 250GB・MAU 100,000。月10ドルのコンピュート枠を含み、2プロジェクト目から1つにつき10ドル追加 |
| Team | 599ドル〜 | 組織向け |
一方、弊社が使ったさくらのクラウドの2コア・8GB は月7,260円、SSD 40GB が月1,540円で、合計 8,800円（税込）です（2026年10月7日に料金ページで確認。石狩第1ゾーン）。Pro の25ドルは1ドル150円なら約3,750円なので、同じスペックの VPS を借りると Pro より高くつきます。公式の最小要件の 2コア・4GB（4,620円＋ディスク 1,540円＝6,160円）でも Pro を上回ります。
費用で逆転するのは、Pro でディスク超過やプロジェクト追加が積み上がる場合か、既にある VPS に相乗りする場合です。それ以外でセルフホストを選ぶ理由は、データを国内の自分のサーバーに置ける、Free の一時停止や 500MB の上限が無い、の2つです。鍵・ポート・バックアップを自分で持つ手間が、その対価です。
Supabaseのセルフホストが向いている人・向いていない人、まとめ
| 向いている | 向いていない |
|---|---|
| データを国内の自社サーバーに置きたい。Docker とファイアウォールの基礎が分かる | 手順通りに動かせば安全だと思っている。公式の compose は全公開で、鍵も公開値 |
| 8GB クラスの VPS が既にあり、他の OSS と相乗りさせたい（Supabase 分は約1GB） | Supabase のためだけに VPS を借りる。さくらのクラウド 8GB ならPro より高い |
| Free の一時停止や 500MB の上限に当たっている | 個人開発の試作。Free の2プロジェクトで足りる |
弊社の結論は「動かすのは簡単、公開するまでが本番」です。鍵の差し替えとポートの限定を済ませてから up -d してください。Supabase の概要と、ほかの Firebase 代替 OSS は OSSMatch にまとめています。
「公開前の安全設定を一緒に確認してほしい」「クラウド版とセルフホストのどちらにすべきか」という場合は、合同会社Edel Hearts のOSS導入支援でご相談を受け付けています。弊社自身が3分間ポートを開けてしまった分、どこで失敗するかを具体的にお伝えできます。
出典
- Supabase Docs：Self-Hosting with Docker（手順・システム要件・既定値の警告・Studio の Basic 認証）（2026年10月7日確認）
- supabase/supabase：docker/docker-compose.yml（11サービスとポート公開の確認）（2026年10月7日確認）
- Supabase Pricing（Free／Pro／Team の料金と制限）（2026年10月7日確認）
- Supabase vs Firebase（公式の比較ページ）（2026年10月7日確認）
- supabase/supabase の LICENSE（Apache License 2.0）（2026年10月7日確認）
- さくらのクラウド：サーバー料金・ディスク料金（税込表示、2026年10月7日確認）
- 実測値：弊社の検証サーバー（さくらのクラウド、2コア・8GB・SSD 40GB）で2026年10月7日に計測。メモリは全11コンテナが healthy になった後の全体使用量から、同居していた Immich 停止後の素の値（0.5GB）を差し引いたもの。円換算は1ドル150円の仮定
▶ 同じ環境で測った他の OSS は OSS 実機検証シリーズの一覧 にまとめています。