Supabase on Ubuntu セルフホスト — Firebase代替BaaSを自前構築

FirebaseやSupabase Cloudの「無料枠が足りない」「データを自分の手元に置きたい」——そう思ったことはありませんか。Supabaseはオープンソースなので、Ubuntu上のDockerさえあれば完全に自前で動かせます。PostgreSQL・REST API・認証・リアルタイム配信・WebUI（Studio）がすべて込みの本格的なBaaSを、自分のVPSに構築できます。

本記事は机上の空論ではありません。公式リポジトリを実際に docker compose up し、11個のコンテナがすべて healthy になり、Supabase Studio がブラウザで開くところまで実機で検証しました（2026-06-14、Docker Desktop / 割り当てRAM 11.68GiB環境）。検証で分かった「ドキュメントに書いていない詰まりどころ」も正直に共有します。

動作確認済み環境

まず、今回の検証で使ったバージョンを正確に共有します。バージョンはすべて実際に apt-cache policy やコンテナ内の --version で取得した実測値です。

注意したいのが DB本体は PostgreSQL 15系だという点です。「Supabase = 最新のPostgres」というイメージがありますが、セルフホストの db コンテナは supabase/postgres:15.8.1.085、つまり PostgreSQL 15.8 でした。Ubuntu 標準の postgresql-client も16系なので、ローカルから psql でつなぐ場合もバージョン差を意識しておくと安心です。

Supabaseとは — Firebaseの何がオープンソースになったのか

Supabase は Firebase の代替として開発された、オープンソースのBaaS（Backend as a Service：バックエンド機能をまるごと提供してくれるサービス）です。次の機能がひとつのパッケージにまとまっています。

特に重要なのは、PostgreSQLをそのまま使っている点です。他のBaaSではベンダー独自のクエリ言語を覚える必要がありますが、Supabaseでは普通のSQLがそのまま動きます。既存のPostgreSQLの知識が活きますし、インデックスを貼るのも CREATE INDEX で完結します。

セルフホストの全体構成

Supabaseは公式の docker-compose.yml で起動します。今回その中身を実際に解析したところ、サービス数は 11個でした（一部の解説では「12コンテナ」とされていますが、現行の公式 compose は11サービス構成です）。実際に取得したイメージタグ付きの一覧がこちらです。

リクエストの流れを図にすると次のようになります。外部に公開されるのは原則 Kong（APIゲートウェイ）の8000番ポートだけで、そこから内部の各サービスに振り分けられます。

ここが最初の落とし穴でした。古い記事では「Studioは3000番で開く」と書かれていますが、現行の公式構成ではStudioも8000番（Kong経由）からBasic認証で開きます。3000番はコンテナ内部用で、ホストには公開されていませんでした。後半でファイアウォール設定とあわせて詳しく書きます。

STEP 1. Docker と依存パッケージを入れる

Ubuntu 24.04 の標準リポジトリには docker.io と docker-compose-v2 が含まれています。ubuntu:24.04 コンテナ内で apt-cache policy を実行し、実際にインストール候補になるバージョンを確認しました。

候補バージョンが確認できたら、まとめてインストールします。

インストール後は、自分のユーザーを docker グループに追加して、sudo なしで docker コマンドを使えるようにします。newgrp でその場でグループを反映できますが、確実なのは一度ログアウトして入り直すことです。

ここで Total Memory を必ず見てください。3.8GB以上あればSupabaseのフル構成が安定して動きます。1〜2GBのVPSではこの段階で「足りない」と判断できます。

STEP 2. Supabase リポジトリを取得する

セルフホスト用の docker-compose.yml と設定ファイル群は、公式リポジトリの docker/ ディレクトリに入っています。リポジトリ全体は巨大なので、docker/ だけをスパースチェックアウトすると速くて軽いです。

volumes/ の中には Kong の設定や DB の初期化スクリプトが入っています。docker-compose.yml はこれらを ./volumes/... として参照するので、このディレクトリごと持ってこないと起動できません。compose ファイル1枚だけコピーしてもダメ、というのは覚えておくと良いです。

STEP 3. .env を編集してシークレットを設定する

これが最も重要なステップです。.env.example にはダミーのJWTシークレットやキーが書かれており、それらはインターネット上に公開されています。本番運用では必ず自分で生成した値に置き換えてください。

JWTシークレットは openssl で生成します。実際にコンテナ内で叩いたところ、44文字のbase64文字列が返ってきました（毎回異なる値になります）。

.env で最低限変更すべき項目は次のとおりです。

ANON_KEY と SERVICE_ROLE_KEY は単なるパスワードではなく、JWT_SECRET で署名した JWT形式のトークンです。{"role":"anon",...} というペイロードを JWT_SECRET でHS256署名して作ります。今回の検証ではこの方法でキーを生成しましたが、公式ドキュメントのジェネレーターを使うのが手軽です。JWT_SECRET と ANON_KEY の署名が食い違うとAPIが401を返すので、必ずセットで生成してください。

STEP 4. docker compose で起動する

設定が終わったら、すべてのイメージをプルして起動します。初回は11個のイメージをダウンロードするため、回線にもよりますが数分〜十数分かかります。

全コンテナが healthy になったかを確認します。これは今回の検証で実際に得られた出力です。

下のように docker compose ps で11サービスすべてが Up ... (healthy) になれば成功です。

STEP 5. Supabase Studio にブラウザでアクセスする

ここが一番つまずきやすいポイントです。Studioは3000番ではなく、Kong経由の http://サーバーのIP:8000 にアクセスします。最初にBasic認証が求められるので、.env で設定した DASHBOARD_USERNAME と DASHBOARD_PASSWORD を入力します。実際にPlaywrightでアクセスして撮影したのが次の画面です。

ログインすると Default Project のダッシュボードが表示され、画面上部にAPIのURL（http://localhost:8000）が出ています。左サイドのアイコンから Table Editor・SQL Editor・Authentication・Storage などへ移動できます。

興味深いのが、ダッシュボード下部の Advisor が起動直後から働いていた点です。今回テスト用に作った todos テーブルに対して「RLS（行レベルセキュリティ）が無効です」という CRITICAL の警告が自動で出ていました。Studioはただの管理画面ではなく、セキュリティ的に危ない設定を能動的に教えてくれます。

Table Editor — GUIでテーブルを作る

Table Editor では、SQLを書かなくてもGUIでテーブルのカラムや制約を定義できます。「New table」から始められます。今回は確認のため todos テーブル（id / title / is_done / created_at）を作成しました。

そしてここがSupabase最大の魅力です。テーブルを作った瞬間、PostgRESTがREST APIのエンドポイントを自動生成します。実際に anon キーを付けて curl したところ、コードを1行も書いていないのに作ったばかりの todos がJSONで返ってきました。

SQL Editor — ブラウザからSQLを実行する

SQL Editor はブラウザ上でPostgreSQLに直接クエリを投げられます。複数テーブルのJOINや集計、RLSポリシーの作成など、GUIでは難しい操作もここで書けます。

テンプレートやサンプルも用意されているので、「とりあえず select * from todos; を実行してみる」といった確認もすぐにできます。

Data API（PostgREST）— 自動生成APIのドキュメントを見る

Integrations の「Data API」では、テーブルごとの自動生成APIのドキュメントと、各言語からの接続コードが確認できます。todos テーブルもしっかり一覧に載っていました。

画面右には createClient('http://localhost:8000', SUPABASE_KEY) のような初期化コードが表示され、@supabase/supabase-js からそのまま叩けるようになっています。接続先URLが8000番（Kong）になっているのがここでも確認できます。

Authentication — ユーザー管理画面

Authentication の Users 画面では、GoTrueで管理されるユーザーの一覧・追加・招待ができます。メール＋パスワード認証のほか、各種OAuthプロバイダの設定もGUIから行えます。

ファイアウォールの設定（UFW）

VPSで運用するなら、UFW（Ubuntu標準のファイアウォール）でポートを絞ります。公開が必要なのは原則 SSH(22) と Kong(8000) だけです。古い手順にある3000番は現行構成では公開されていないので開ける必要はありません。

自動起動の設定（再起動後もSupabaseを維持する）

VPSが再起動しても Supabase が自動で立ち上がるよう、Docker Compose を systemd サービスとして登録します。

Ubuntu 22.04 との違い — docker.io バージョン比較

Ubuntu 22.04 と 24.04 では同じ docker.io 29.1.3 が入りますが、パッケージのビルド識別子が異なります。

Docker本体のバージョンは同じでも、Ubuntu 24.04 のほうがサポート期限が長い（2029年まで）ため、新規にVPSを立てるなら24.04を選ぶのが正解です。

よくあるエラーと解決策

①「permission denied while trying to connect to the Docker daemon socket」

docker グループに追加したあと、セッションを作り直していないと出ます。

②「Additional property name is not allowed」

古い docker compose が、公式 compose 先頭の name: supabase を解釈できないときに出ます。docker compose -p supabase up -d でプロジェクト名を渡すか、Composeを更新してください。Ubuntu 24.04 標準の v2.40 系なら発生しません。

③ Studioに「3000番」でアクセスできない

これは仕様です。現行の公式構成ではStudioは3000番をホストに公開していません。http://サーバーIP:8000 にBasic認証（DASHBOARD_USERNAME / DASHBOARD_PASSWORD）でアクセスしてください。

④「supabase-db」がメモリ不足で落ちる

RAMが足りないと db コンテナが起動途中で落ちます。docker logs supabase-db に out of memory が出ていたら、プランを4GB以上にアップグレードしてください。

まとめ

Supabase の Ubuntu セルフホストは、docker.io と docker-compose-v2 を入れて公式リポジトリの docker/ を取得し、.env を設定して docker compose up するだけで動き始めます。Firebase代替として本格的に使えるBaaSが、月額数ドルのVPS代だけで運用できるのは大きな魅力です。

• Ubuntu 24.04 + docker.io 29.1.3 + docker-compose-v2 2.40.3 で動作確認済み（2026-06-14、全11コンテナ healthy）
• DB本体は PostgreSQL 15.8。最低 2vCPU / 4GB RAM のVPSが必要
• Studioは8000番（Kong経由）にBasic認証でアクセスする。3000番ではない
• .env の JWT_SECRET・ANON_KEY・SERVICE_ROLE_KEY・DASHBOARD_PASSWORD は必ず変更する
• Table Editor でテーブルを作ると、その場でREST APIが自動生成される（curlで実証済み）
• 公開テーブルにはRLSを必ず設定する（Studioの Advisor が未設定を警告してくれる）

セルフホストが面倒な場合や、まずはプロトタイプを作りたい場合は、Supabase Cloud の無料枠から始めて、トラフィックが増えた段階で自前サーバーへ移行するのも手です。VPSの選び方に迷っている方はも参考にしてください。