データベース

Nodaro は、データベースとして Supabase を使います。データの保存には Postgres、ログインには GoTrue、エディターが読み書きするデータ API には PostgREST を使います。Compose スタックにはこの 3 つが同梱されており、データベースのマイグレーションも自動で適用されます。代わりに、Nodaro の接続先をマネージドの Supabase プロジェクトにして、マイグレーションを自分で適用することもできます。

同梱のスタック

ブラウザーと API は、アプリ自身のオリジンの PUBLIC_URL/supabase を通じて、ログインとデータ API にアクセスします。Nodaro コンテナ内の Web サーバーが /supabase/auth/v1 を GoTrue に、/supabase/rest/v1 を PostgREST に転送するため、追加のポートやドメインは必要ありません。

同梱のスタックは、メールを送信しません。アカウントは、登録後すぐに使えます。

同梱のスタックでのマイグレーション

アプリのコンテナは、API が起動する前に、supabase/migrations/ 内のすべてのファイルを適用します。これには RUN_MIGRATIONS_ON_BOOT=true と DATABASE_URL が必要ですが、どちらも Compose ファイルで設定済みです。

• 適用済みのファイルは記録され、次回の起動時にはスキップされます。
• マイグレーションが途中までしか適用されていないデータベースで動くことはありません。マイグレーションが失敗すると API は起動を拒否し、コンテナのログにそのファイル名が表示されます。
• 原因を修正してから、もう一度起動します。修正したら、docker compose -f docker-compose.community.yml up をもう一度実行します。適用済みのファイルはスキップされます。

同梱のデータベースを保護する

デフォルトのキーとパスワードは、公開されている値です。スタックをネットワークに公開する前に、次の作業を行います。

1. node tools/generate-selfhost-keys.mjs >> .env で新しい認証キーを発行します。このスクリプトは、SUPABASE_JWT_SECRET、SUPABASE_ANON_KEY、SUPABASE_SERVICE_ROLE_KEY を出力します。キーはシークレットで署名されるため、3 つとも同じ実行で生成したものを使う必要があります。
2. POSTGRES_PASSWORD と、それに合わせた DATABASE_URL を設定します。たとえば postgres://postgres:<new-password>@db:5432/postgres のようにします。
3. docker compose -f docker-compose.community.yml up -d で変更を反映します。

データベースが supabase_auth_admin や authenticator などの内部ロールのパスワードを POSTGRES_PASSWORD に合わせるのは、初回の起動時だけです。db-data ボリュームがすでにある場合は、ボリュームを削除する（データも削除されます）か、supabase_admin としてロールのパスワードを手動で変更します。そうしないと、ログインが password authentication failed for user "supabase_auth_admin" で失敗します。

マネージドの Supabase プロジェクトを使う

supabase.com のプロジェクトで、同梱の db、auth、rest サービスを置き換えます。無料プランで十分です。.env に次の値を設定します。

SUPABASE_URL=https://YOUR-PROJECT.supabase.co
SUPABASE_ANON_KEY=eyJ...
SUPABASE_SERVICE_ROLE_KEY=eyJ...
FRONTEND_SUPABASE_URL=https://YOUR-PROJECT.supabase.co
RUN_MIGRATIONS_ON_BOOT=false
NODARO_ENCRYPTION_KEY=<64-character hex>

• FRONTEND_SUPABASE_URL は、ブラウザーが使うプロジェクトの URL です。公開されているイメージは同梱のスタック向けにビルドされており、別の URL は、起動時にこの変数からしか読み取りません。
• RUN_MIGRATIONS_ON_BOOT=false は、マイグレーションランナーを無効にします。マイグレーションは、後述の方法で自分で適用します。
• NODARO_ENCRYPTION_KEY は、必ず設定します。たとえば openssl rand -hex 32 で生成できます。スタックがこのキーを自動で生成するのは、マイグレーションランナーがオンのときだけです。キーがないと、プロバイダーキーの貼り付けと Nodaro Cloud への接続が EncryptionKeyMissingError で失敗します。

環境をすでに同梱のスタックで動かしていた場合は、そのキーを再利用します。キーは、app-data ボリュームの /data/nodaro/encryption-key にあります。新しいキーでは、古いキーで暗号化したデータを読み取れません。

マネージドプロジェクトにマイグレーションを適用する

supabase/migrations/ 内のすべてのファイルを、ファイル名の順に適用します。順序は、001_ や 002_ のようなゼロ埋めの接頭辞で決まります。

• SQL エディターを使う場合：Supabase のダッシュボードで SQL editor を開き、各ファイルを順に実行します。
• Supabase CLI を使う場合：こちらのほうが速く適用できます。

supabase link --project-ref YOUR-REF
supabase db push

マイグレーションは、マイグレーション済みのデータベースで再実行しても問題ありません。ただし、シードデータ用のファイルなど、ファイル内に別の記載がある場合は除きます。新しいデータベースで実行する場合は、常に問題ありません。

アップデートのたびに、新しいイメージで再起動する前に、新しいファイルをファイル名の順に適用します。マイグレーションが欠けていても、通常は API は止まりません。ただし、そのマイグレーションを必要とする機能は、テーブルができるまで 500 を返します。

マネージドプロジェクトを自分のオリジン経由で提供する

ネットワークによっては、ブラウザーのリクエストをすべてホスト名でフィルタリングし、Supabase のドメインをブロックしている場合があります。そのようなネットワークでは、Nodaro コンテナ内の Web サーバーが、アプリ自身のオリジンを通じてマネージドプロジェクトに転送できます。次の 3 つの変数を、まとめて設定します。

SUPABASE_MANAGED_PROXY=true
FRONTEND_SUPABASE_URL=/supabase
SUPABASE_PROXY_UPSTREAM=https://YOUR-PROJECT.supabase.co

• SUPABASE_PROXY_UPSTREAM には、パスを含まないオリジンを指定します。
• SUPABASE_URL は、プロジェクトの HTTPS の URL のままにします。API は引き続き、この URL に直接接続します。
• ブラウザーは、/supabase をページのオリジンを基準に解決します。Web サーバーは、ログイン、REST、ストレージ、Realtime のリクエストを、WebSocket のアップグレードも含めてプロジェクトに転送します。
• トークンと API キーは、そのまま通過します。プロキシが特権的な認証情報を追加することはありません。
• Supabase でカスタムドメインを追加しなくても、複数のドメインで同じ設定を使えます。

Compose ファイルは、.env の SUPABASE_MANAGED_PROXY と SUPABASE_PROXY_UPSTREAM をアプリに渡しません。nodaro サービスの environment: の下に追加してください。設定しない場合、プロキシはオフのままで、同梱のルートはこれまでどおりに動作します。

データベースを利用できないとき

マイグレーションや復旧のために Postgres が停止すると、API は、データベースに再び接続できるまで再起動を繰り返します。これは想定どおりの動作です。Postgres が復帰したら、Nodaro コンテナを再起動します。

docker compose -f docker-compose.community.yml restart nodaro

データベースに保存されるもの

ワークフローとプロジェクト、ユーザーのプロフィール、実行とその進行状況、ジョブ、生成したメディアの記録、API トークンと OAuth アプリ、そして暗号化されたプロバイダーキーと SNS のログイン用トークンです。すべてのテーブルで行レベルセキュリティが適用されるため、ユーザーは自分の行しか見られません。メディアファイル自体はオブジェクトストレージに保存され、Redis が保持するのは、短期間だけ必要なジョブの状態だけです。

データベースは、暗号化キーと一緒にバックアップします。バックアップと復元を参照してください。1 つのデータベースで 2 つの環境を動かす方法は、スケーリングを参照してください。