Dockerを使用したSupabaseのセルフホストによるBackend-as-a-Serviceの構築 – ITFROMZERO

Table of Contents

クイックスタート：5分でSupabaseを起動する

詳細を読み飛ばして、まずは試してみたいですか？ターミナルを開いて以下の4つのコマンドを実行するだけです。事前にDockerとDocker Composeがインストールされていることを確認してください。

# 1. 公式リポジトリをクローン
git clone --depth 1 https://github.com/supabase/supabase

# 2. dockerディレクトリに移動
cd supabase/docker

# 3. 設定ファイルのサンプルをコピー
cp .env.example .env

# 4. イメージをプルして起動
docker compose pull
docker compose up -d

完了したら、http://localhost:8000にアクセスしてください。ユーザー名 supabase、デフォルトパスワード this_password_is_insecure_and_should_be_updated でログインできます。本番サーバーにデプロイする際は、データ流出を防ぐためすぐにパスワードを変更してください。

Supabaseの内部構造を解剖する

ダッシュボードの見かけに騙されてはいけません。Supabaseは単一のデータベースではなく、高度に組み合わされたマイクロサービスの集合体です：

PostgreSQL: システムの心臓部です。FirebaseのNoSQLとは異なり、Postgresは強力なクエリ能力と完璧なデータ整合性を提供します。
GoTrue (Auth): ユーザー管理とJWTトークンの発行を行うGo製のサービスです。メール登録から各種OAuthまでスムーズに処理します。
PostgREST: Postgresデータベースを自動的にRESTful APIに変換するツールです。手動でCRUDコードを書く手間を大幅に削減できます。
Realtime: Elixir/Phoenixをベースにしており、WebSocketを通じてデータベースの変更を極めて低いレイテンシで監視します。
Kong (API Gateway): ゲートウェイとして機能し、すべてのリクエストを適切なサービスにルーティングします。

MySQLやMongoDBを使ってきた経験から言うと、Supabaseの最大の魅力は、伝統的なSQLの強力さとモダンなAPIの利便性が融合している点にあります。

詳細設定：必ず変更すべきパラメータ

コンテナを起動できたのは、あくまで始まりに過ぎません。安定して運用するためには、.envファイルを開いて以下の項目を調整する必要があります：

1. JWTとパスワードのセキュリティ

デフォルトのシークレットは絶対に使用しないでください。この文字列が漏洩すると、攻撃者がトークンを偽造して管理者権限を奪取する可能性があります。少なくとも32文字以上のランダムな文字列を使用してください。

POSTGRES_PASSWORD=your_strong_password
JWT_SECRET=your_super_long_random_string
ANON_KEY=your_new_anon_key
SERVICE_ROLE_KEY=your_new_service_role_key

2. メール送信のためのSMTP接続

SMTPが設定されていないと、Supabaseは確認メールを送信できません。無料枠が充実しているResendやSendGridの利用をお勧めします：

[email protected]
SMTP_HOST=smtp.resend.com
SMTP_PORT=587
SMTP_USER=resend
SMTP_PASS=re_your_api_key

セルフホストにおける実戦ノウハウ

数々の実プロジェクトへの導入を経て、夜中にサーバーがダウンする事態を避けるための3つの教訓を得ました。

RAMリソースに関する警告

Supabaseは「メモリを食い尽くす怪物」です。アイドル状態でも約1.2GB〜1.5GBのRAMを消費します。2GBのVPSで実行すると、簡単にフリーズ（OOM）してしまいます。
解決策： 最低でも4GBのスワップ（Swap）を有効にしてください。もし Edge Functions や Vector を使用しない場合は、docker-composeファイルでこれらを無効にして負荷を下げましょう。

データバックアップ戦略

データバックアップ戦略だけに頼ってはいけません。私は毎日午前2時に pg_dump を実行するcronjobを設定しています。バックアップファイルは、安全を確保するためにS3やGoogle Cloud Storageに直接アップロードするようにしています。

リバースプロキシによるセキュリティ強化

ポート8000をインターネットに直接公開しないでください。Supabaseの前にNginxやCaddyを配置しましょう。これにより、SSL（HTTPS）の管理が容易になり、基本的な攻撃リクエストをフィルタリングできます。

# Caddyの設定例
supabase.yourdomain.com {
    reverse_proxy localhost:8000
}

なぜFirebaseではなくSupabaseを選ぶのか？

多くの開発者がこの2つの選択肢で迷います。私がSupabaseを支持する3つの理由は以下の通りです：

ベンダーロックインがない： Firebaseでは「借り主」ですが、セルフホストのSupabaseでは「家主」です。Googleにコストを強制されることなく、データを自由に移動させる権利があります。
SQLの強力さ： FirestoreではテーブルのJOINや集計計算などの複雑なクエリが困難です。Postgresならこれらを一瞬で処理できます。
コスト管理： 大規模プロジェクトでは、Firebaseの読み書き料金が制御不能になるほど高騰することがあります。Supabaseをセルフホストすれば、毎月のVPS費用（約10ドル〜20ドル）だけで済みます。

Supabaseのセルフホストは、データの制御権を維持しつつ、高速で強力なバックエンドを必要とする場合に最適な選択肢です。セットアップの成功を祈っています。デプロイ時にエラーが発生した場合は、下のコメント欄で教えてください。サポートします！