Webアプリ開発者にとって、近年Supabaseは非常に「アツい」存在になっています。Firebaseのオープンソース代替として勢いよく機能拡充され続けており、データベース(Postgres)、認証(GoTrue)、リアルタイムAPI(Realtime)、ストレージ(Storage)、エッジファンクション(Edge Functions)、GUIによる管理ツール(Studio)など、モダンなバックエンド構築に求められる要素をワンストップで提供してくれるプラットフォームです。
しかし、その豊富な機能ゆえ、公式リポジトリには本番を想定した包括的なdocker-compose.ymlが存在し、ありとあらゆるコンテナが並びます。初学者や、ローカルでちょっと試したいだけの場面で、いきなり全部のコンテナを立ち上げるのは大げさです。CPUやメモリは食われるし、設定やログが多くて混乱することもあるでしょう。
この記事では、公式docker-compose.ymlを参考にしながら「必要最低限のコンテナ」と「その依存サービス」だけを起動する方法について紹介します。これによって、ローカル環境で軽量かつシンプルな形でSupabaseを触り始めることができます。
公式docker-compose.ymlが示すフルスタック構成
公式のdocker-compose.yml（参照: GitHub）には以下のようなコンテナが含まれます。
-
Database関連:
db(Postgres),rest(PostgREST),meta(Postgres Meta),vector(ログ関連) -
Authentication関連:
auth(GoTrue),kong(APIゲートウェイ),supavisor(接続プーリング) -
Realtime関連:
realtime -
Storage関連:
storage,imgproxy -
Edge Functions関連:
functions -
Studio (GUI):
studio -
Analytics (ログ・分析):
analytics -
API Gateway:
kong
これらは相互に依存関係を持ち、depends_onで起動順序や可用状態を保障しているほか、環境変数を通じてJWTシークレットやDB接続情報、ストレージパスなどをやりとりしています。
次のようなモジュール分解も可能です。
{
"modules": {
"Database": ["db", "rest", "meta", "vector"],
"Authentication": ["auth", "kong", "supavisor"],
"Realtime": ["realtime"],
"Storage": ["storage", "imgproxy"],
"Edge Functions": ["functions"],
"Studio": ["studio"],
"Analytics": ["analytics"],
"API Gateway": ["kong"]
}
}
このように全貌を把握すると、Supabaseがいかに多機能かがわかります。
なぜ「必要最低限のコンテナ」構成が有効なのか
ローカル開発段階では、最初からすべてを理解し、すべてを起動する必要はありません。むしろ、必要な機能に対応するコンテナだけ立ち上げれば学習コストもリソース消費も抑えられます。 例えば、以下のような段階的ステップが可能です。
- DB + Studioだけ: とりあえずPostgresとGUIでDB状態を確認したい。
- DB + Studio + REST + Auth: 認証やREST APIも試して、実際のWebアプリっぽく触れたい。
- DB + Realtime + Analytics: リアルタイム更新やログ分析を加えて高度な機能を試す。
こうした段階的なアプローチが、Supabaseの全貌に圧倒されずに理解を深めていくのに役立ちます。
例: StudioとDBを中心に必要最低限のコンテナ構成
ここでは、studioとdbを中心に、metaやanalytics、rest、authなど最低限あると便利なサービスを加えた例を示します。これらを起動することで、GUI管理ツール(Studio)経由でDB状態を確認し、認証やREST APIも最低限触れる環境が整います。
docker-compose.yml例
以下はカスタムしたdocker-compose.ymlの例です。公式ファイルを参考にした上で、不要なコンテナをコメントアウト、または削除し、環境変数やポートを適宜簡略化しています。なお、本例はあくまで一例であり、実際の値やパスワード、JWTシークレットは適宜変更してください。
version: "3.9"
services:
db:
image: supabase/postgres:15.6.1.146
container_name: supabase-db
healthcheck:
test: ["CMD", "pg_isready", "-U", "postgres", "-h", "localhost"]
interval: 5s
timeout: 5s
retries: 10
environment:
POSTGRES_PASSWORD: examplepass
POSTGRES_DB: postgres
volumes:
- ./volumes/db/data:/var/lib/postgresql/data:Z
restart: unless-stopped
meta:
image: supabase/postgres-meta:v0.84.2
container_name: supabase-meta
depends_on:
db:
condition: service_healthy
environment:
PG_META_PORT: 8080
PG_META_DB_HOST: db
PG_META_DB_PORT: 5432
PG_META_DB_NAME: postgres
PG_META_DB_USER: postgres
PG_META_DB_PASSWORD: examplepass
ports:
- "8080:8080"
restart: unless-stopped
rest:
image: postgrest/postgrest:v12.2.0
container_name: supabase-rest
depends_on:
db:
condition: service_healthy
environment:
PGRST_DB_URI: postgres://postgres:examplepass@db:5432/postgres
PGRST_DB_SCHEMAS: public
PGRST_DB_ANON_ROLE: anon
PGRST_JWT_SECRET: super-secret-jwt
ports:
- "3000:3000"
command: ["postgrest"]
restart: unless-stopped
auth:
image: supabase/gotrue:v2.164.0
container_name: supabase-auth
depends_on:
db:
condition: service_healthy
environment:
GOTRUE_API_HOST: 0.0.0.0
GOTRUE_API_PORT: 9999
API_EXTERNAL_URL: http://localhost:9999
GOTRUE_DB_DRIVER: postgres
GOTRUE_DB_DATABASE_URL: postgres://postgres:examplepass@db:5432/postgres
GOTRUE_SITE_URL: http://localhost:3000
GOTRUE_JWT_SECRET: super-secret-jwt
ports:
- "9999:9999"
restart: unless-stopped
studio:
image: supabase/studio:20241202-71e5240
container_name: supabase-studio
depends_on:
db:
condition: service_healthy
meta:
condition: service_healthy
environment:
POSTGRES_PASSWORD: examplepass
SUPABASE_ANON_KEY: super-secret-anon
SUPABASE_SERVICE_KEY: super-secret-service
STUDIO_PG_META_URL: http://meta:8080
SUPABASE_URL: http://localhost:3000
SUPABASE_PUBLIC_URL: http://localhost:3000
AUTH_JWT_SECRET: super-secret-jwt
ports:
- "8081:3000"
restart: unless-stopped
ボリュームについて
dbサービスでは、./volumes/db/data:/var/lib/postgresql/data:Zのようにボリュームマウントをしています。これにより、コンテナを再起動してもDBデータがローカルホスト上に保持され、永続化されます。ZオプションはSELinux対応のためのものです（環境により不要な場合もあります）。
ローカル開発でDBデータを保持したい場合、名前付きボリュームやホストディレクトリマウントを活用してください。また、本番環境ではより洗練されたストレージ戦略やバックアップ管理が必要になりますが、ここではあくまでローカル開発用途なので簡易的な設定で十分です。
コマンド例
上記のdocker-compose.ymlファイルが./docker-compose.ymlというパスにあると仮定すると、コンテナ群を起動するには以下のコマンドを実行します。
docker compose up
起動後、以下にアクセスしてみてください。
-
Studio:
http://localhost:8081
GUIでDB状態や認証設定などを確認できます。 -
REST API:
http://localhost:3000
PostgRESTが動いているので、publicスキーマのテーブルにアクセスできます。 -
Auth API:
http://localhost:9999
GoTrueによる認証エンドポイントが利用できます。 -
Meta API:
http://localhost:8080
Postgres Meta APIでメタデータ操作が可能です。 -
Analytics:
http://localhost:4000
Logflareによるログ・分析画面（設定次第）
停止する場合は以下のコマンドを実行します。
docker compose down
永続化したボリュームやネットワークを削除してクリーンアップしたい場合は、以下のようにします。
docker compose down -v --remove-orphans
さらに機能を絞るには？
この例ではstudio, db, meta, analytics, rest, authを一気に起動していますが、本当に最低限（例: dbとstudioだけ）に絞ることも可能です。その場合はmetaやanalyticsを省略しようとすると、Studioの一部機能が制限される可能性がありますが、開発初期の「とりあえずDBの状態をGUIで見たい」程度ならそれでも価値があります。
まとめ
- Supabaseは多機能で、公式
docker-compose.ymlは本番向けのフル構成が提示されています。 - ローカル開発や学習初期段階では、「必要最低限のコンテナ」と「必須依存サービス」だけを立ち上げることで、軽量かつシンプルな環境を構築できます。
- 段階的なアプローチでSupabaseの各機能を理解していけば、最終的にはフルスタック環境への拡張もスムーズです。
-
docker compose upで起動し、downで停止、-vでボリューム消去など基本的なDocker Composeコマンドも活用できます。
Supabaseはコミュニティや公式サイドからも次々とアップデートや新機能が提供されているため、継続的な情報収集と環境更新がポイントになります。この軽量構成を足掛かりに、より高度なSupabaseの世界へと踏み込んでみてください！