Supabase + Firebase Functions + Hosting を本番デプロイするまでにやったこと

個人開発した曖昧表現チェッカーを Firebase Hosting / Functions に載せるまでの備忘録です。

Supabase 接続まわりや CI 設定で3日間ほどつまずいたので、対応をまとめておきます。

問題

ローカル回線が IPv4 のみだったため、db.<project>.supabase.co:5432 直結では P1001 接続エラーになった

対応1：Pooler を IPv4 に切り替える

Supabase Console -> Connection string から Session/Transaction Pooler の URI を取得。

その後、functions/.env.local で Transaction Pooler を DATABASE_URL に上書き、Direct connection を DIRECT_DATABASE_URL に指定

.env.local

DATABASE_URL="postgresql://postgres.<project_ref>:<password>@aws-0-ap-northeast-1.pooler.supabase.com:6543/postgres?pgbouncer=true&sslmode=require&options=--search_path%3Daimai"
DIRECT_DATABASE_URL="postgresql://postgres:<password>@db.<project_ref>.supabase.co:5432/postgres?sslmode=require&options=--search_path%3Daimai"

初見では分かりにくいですが、Supabase の Session/Transaction Pooler の URI はこちらから確認できます。

対応2：Prisma マイグレーションをリモートで実行

本番と同じスキーマを即時に反映したかったので、ローカルではなくリモートの Supabase に直接適用しました。

1. supabase login -> supabase link --project-ref <ref> で CLI を紐付ける
2. Docker を起動せずに supabase migration up --db-url "..." を実行し、リモート DB にマイグレーションを適用

以下の理由から Docker を使用しませんでした。

1. 今回やりたかったことはリモートの Supabase 本番 DB に Prisma のマイグレーションを適用するだけで、ローカルコンテナを動かす必要がない
2. Supabase CLI には supabase migration up --db-url ... という、リモート DB に直接適用できるコマンドが用意されており、これなら Docker が不要だった

2. Firebase Functions 用 Secrets 登録

Supabase の接続情報（DATABASE_URL や DIRECT_DATABASE_URL ）を Cloud Functions で使うために登録。

firebase functions:secrets:set DATABASE_URL --project ambiguous-expression-checker
firebase functions:secrets:set DIRECT_DATABASE_URL --project ambiguous-expression-checker
firebase functions:secrets:set OPENAI_API_KEY --project ambiguous-expression-checker

CLI が「古いバージョンで動いている関数を再デプロイするか？」と毎度聞いてくるので、その場では n にして、最後にまとめて firebase deploy --only functions を実行して反映すると逐次デプロイよりも安全とかなんとか......

3. GitHub Actions (CI/CD) のプロジェクト切り替え

.github/workflows/ci-cd.yml の --project を green-network-472014-a4 -> ambiguous-expression-checker に変更。

また、.firebaserc で ambiguous-expression-checker の Hosting ターゲットが正しいサイト ID を指すよう firebase target:apply hosting default ambiguous-expression-checker --project ambiguous-expression-checker を実行。

4. Functions 401 問題と「公共アクセス」の設定

発生した問題

Hosting にデプロイ後
/api/rewrite、/api/versions、/api/dashboard がすべて 401エラーで動かない。

Cloud Functions のログにも The request was not authorized to invoke this service（サービスを呼び出す権限がないよ！） と表示される。

原因

2nd Gen Functions では明示的に Invoker を公開設定しないと、Cloud Run 側でバリデーションされるっぽい。

対応

デフォルト設定を上書きして、Hosting 経由の未認証リクエストでもアクセスできるよう、 onRequest のオプションに invoker: "public" を追加して再デプロイ。

export const rewrite = onRequest({
  cors: true,
  timeoutSeconds: 30,
  invoker: "public",
  secrets: [OPENAI_API_KEY, DATABASE_URL],
}, async (req, res) => {
  ...
});

反映後は Hosting 経由でも 401 が解消（長かった）。

デプロイ手順のまとめ

1.ビルド

npm run build
npm run build:functions

2.Functions デプロイ

firebase deploy --only functions --project ambiguous-expression-checker

3.Hosting デプロイ

firebase deploy --only hosting --project ambiguous-expression-checker

4.CI/CD

main ブランチへの push で GitHub Actions が自動デプロイするよう設定済み。

つまづいたポイントとメモ

エラー	対応	メモ
Prisma マイグレーションが P1001	Pooler URI を使用・supabase migration up	IPv6 直結が必要なケースが多いので注意
supabase migration push --db-url が動かない	supabase migration up --db-url ... を使用	CLI v2 系では push 非対応
Hosting 経由で 401	invoker: "public" を Functions ごとに追加	2nd Gen Functions の仕様変更点

おわりに

今回、Supabase + Firebase のハイブリッド構成では Pooler と Secrets 周りが一番つまづいたところでした。（約3日）

IPv6 と IPv4 の違いなどが、触りだけですが分かったのでいい勉強になりました。