lovable-cloud-migration

Lovable Cloud から自分の Supabase への移行

Carol Monroe 作成 - Lovable Champion および Supabase SupaSquad メンバー 完全な移行は、実際のエンドツーエンド移行 (12 テーブル、 237 行、23 ユーザー、40 ストレージファイル、5 エッジファンクション、2 つの cron ジョブ) で 2026-07-06 に検証されました。Lovable MCP 経由のパスワードハッシュアクセスは、 ハッシュ値を一切公開せずに 2026-08-31 に再確認されました。

v4.1.2 (2026 年 8 月) での変更点

Lovable の公式ドキュメントには、ユーザーのパスワードは使用可能な形式ではエクスポートされず、移行したユーザーにはパスワードリセットのフローを推奨すると記載されています。そのため、このスキルではパスワードリセットをデフォルトの経路として扱います。

ネイティブエクスポートは引き続きデータベースの主要なソースですが、パスワードを保持するエクスポートとして提示しては決してなりません。

Lovable MCP の query_database が、対応する Cloud プロジェクトで auth.users.encrypted_password を読み取れる場合には、オプションの高度な経路も引き続き利用できます。ブール値のみの機能チェックは 2026-08-31 に成功し、完全なハッシュ保持フローは以前に 2026 年 3 月と 7 月に検証されました。この経路はオプションかつ機微であり、Lovable MCP がリサーチプレビューであるため変更される可能性があります。

v4 (2026 年 7 月) での変更点

Lovable は Cloud 向けの公式の Export、Pause、Remove ボタンをリリースしました (Cloud タブ > Overview > Advanced settings)。Lovable Cloud はもはや永続的ではありません。 これにより移行プレイブックが書き換わります:

• 以前の「Cloud は決して切断できない」という事実はもはや当てはまりません。データベースをエクスポートし、同じプロジェクトから Cloud を削除して、自分の Supabase を接続できるようになりました。
• ネイティブエクスポートファイル (pg_dump カスタム形式バックアップ) が、データベースの主要なソースになりました。使用可能なパスワードが保持されていると想定しないでください。デフォルトでは公式のリセット経路に従うか、機能チェックとセキュリティ確認の後に高度な MCP ハッシュ経路を明示的に選択してください。
• 新しい Lovable プロジェクトへの旧 68 ステップの MCP 移行は、ネイティブエクスポートでは対応できないケースのために保持されたフォールバック経路になりました。

命名に関する注意: このスキルは意図的に lovable-cloud-migration という名前を維持しているため、v4 は同じスキルの以前のインストール (その「Cloud は永続的」というガイダンスはもはや当てはまりません) と共存するのではなく置き換えます。これと古いコピーの両方が何らかの形で存在する場合、こちらが優先されます - 古い方を削除してください。

このスキルが行うこと

Lovable Cloud プロジェクト全体を自分の Supabase に移行します: データベーススキーマ、データ、RLS ポリシー、ファンクション、トリガー、シーケンス、認証ユーザーとアイデンティティ、ストレージバケットとファイル、ファンクションごとに正しい verify_jwt を持つエッジファンクション、cron ジョブ、シークレットのインベントリ。その後 Cloud を削除し、ユーザー自身の Supabase を同じ Lovable プロジェクトに接続します。パスワードはデフォルトで公式のリセット経路を使用します。高度な MCP 経路は、利用可能で明示的に承認された場合に既存のハッシュを保持できます。

判断ポイント (常にここから開始)

ユーザーが実際に何を必要としているかを尋ね、経路を選びます:

ユーザーの状況	経路
「作業していない間にアプリがクレジットを消費する」	移行しません。Pause Cloud (Cloud タブ > Overview > Advanced settings)。完了です。
「Cloud データのバックアップが欲しい」	移行しません。Export project data は単体で動作し、24 時間に 1 回、Cloud 上で構築を続けられます。
自分の Supabase で実行する準備ができており、データベースが 5 GB 以下	SAME-PROJECT PATH (主要、以下): 既存の Lovable プロジェクトで Export + 認証の判断 + Remove + Connect。
データベースが 5 GB 超、エクスポートが利用不可/失敗、またはユーザーが元の Cloud プロジェクトをそのまま保持したい	FRESH-PROJECT PATH (レガシーフォールバック): 新しい Lovable プロジェクトへの完全な MCP 移行。references/fresh-project-path.md を参照してください。

ユーザーに伝えてください: Export/Pause/Remove ボタンはクレジットを消費しません。消費するのはエージェントのプロンプトだけです。

そもそもなぜ移行するのか (正しい理由)

Lovable Cloud は堅牢なマネージドバックエンドです。移行が意味を持つのは、プロジェクトが完全な Supabase セットアップでしか提供されない機能を必要とする場合です：

やりたいこと...	なぜ独自の Supabase が必要か
認証メール (送信者、デザイン、内容) をカスタマイズしたい	Cloud は [email protected] から送信します
完全な Supabase ダッシュボードにアクセスしたい	SQL エディター、拡張機能、ログ、モニタリング
サービスロールキーを使いたい	管理者操作と一部のエッジ関数
ステージング + 本番環境を持ちたい	Cloud はプロジェクトごとに 1 つのデータベースです
長期的にインフラを所有したい	あなたのプロジェクト、あなたの組織、あなたの請求

これらがいずれも当てはまらず、ユーザーが Cloud で満足している場合は、そう伝えてください：移行の必要はなく、現在はバックアップとしてエクスポート + 一時停止でほとんどの懸念をカバーできます。

前提条件

要件	必要な対象	セットアップ方法
Cloud が有効な Lovable アカウント	すべて	-
Supabase アカウント	すべて	https://supabase.com
プロジェクトに接続された GitHub	すべて (関数コードはリポジトリ経由で移動します)	エディター > + メニュー > GitHub > 接続
Lovable MCP	インベントリとソース側のチェックに強く推奨。オプションのパスワードハッシュ保持ルートに必要	Claude Code で /mcp、または claude.ai の設定 > コネクタ - https://docs.lovable.dev/integrations/mcp-servers
Supabase MCP	宛先側の自動化 (プロジェクト作成、すべての検証の実行)	Claude Code に組み込み - https://supabase.com/docs/guides/getting-started/mcp
zstd 対応の pg_restore 16+	同一プロジェクトパスのステップ 14	macOS: brew install postgresql@18
GitHub CLI (gh)	新規プロジェクトパスのみ	brew install gh + gh auth login
Supabase CLI	オプション - 関数のデプロイとストレージのアップロードが高速化	https://supabase.com/docs/guides/getting-started

Claude Code と claude.ai で動作し、Cursor など他の MCP 互換エージェントでも動作します。MCP がまったくなくても、同一プロジェクトパスは機能します - ユーザーが Cloud パネルから手動でカウントを読み取り、Claude がターミナル手順を案内します。

移行レベルを選択

開始する前に、ユーザーにどのレベルを希望するか尋ねてください：

レベル	対象者	動作
ガイド付き	初回の移行、技術者ではない	各フェーズを説明し、進む前に確認し、何が起きているかを示す
標準	Supabase/Lovable を知っている	主要な決定を確認し、最小限の一時停止でフェーズを実行
エクスプレス	上級者、経験あり	ソース + 宛先を尋ね、すべてを実行し、ゲートで報告

すべてのレベルは同じハードチェックポイントで停止します：コストの確認、フェーズ 7 のゲート、そして削除のクリックです。

重要な事実

ネイティブエクスポート

• 形式: pg_dump v18 の カスタム形式、zstd 圧縮（ソースは Postgres 17）。
• 復元には、zstd 対応でビルドされた pg_restore v16 以上が必要です。Homebrew の libpq ビルドには zstd が含まれておらず、バージョン番号が問題なく見えても「does not support compression with zstd」で失敗します。postgresql@18 を使用してください（Trap 18）。
• Lovable のドキュメントには、パスワード関連の情報は使用可能な形式ではエクスポートされないと記載されています。エクスポートにはユーザーは含まれるが使用可能なパスワードは含まれないものとして扱い、オプションの MCP ルートを完了して検証しない限り、リセットを計画してください。
• サポートされているデータベースフローに含まれるもの: スキーマとデータ、RLS ポリシー、トリガー、カスタム関数、シーケンス、cron およびストレージのメタデータ。エクスポートの仕様は変わる可能性があるため、すべてのコンポーネントをベースラインと照合して検証してください。
• 含まれないもの: ストレージのファイル（実際のバイト列）、edge function のコード（リポジトリ内にあります）、edge function のシークレット値、vault シークレットの値（行は復元されますが、古いプロジェクトのキーで暗号化されているため、プロジェクト間では復元できません）。
• エクスポートは、プロジェクト自身の Cloud ストレージ内に database_export_06_07_26 のような名前のバケットとして保存されます。Cloud を削除する前にダウンロードしてください - Cloud とともに失われます（Trap 17）。制限: 5 GB、24 時間に 1 回のエクスポート。
• 「メールで送信します」というトーストは信頼できません。メールを待たずに、Storage でエクスポートバケットを確認してください（小規模なデータベースなら約 1 分）。

パスワード: 公式のデフォルト vs 高度な MCP ルート

• 公式のデフォルト: Lovable は、パスワードは使用可能な形式ではエクスポートされないと述べています。Cloud を削除する前に、パスワードリセットフローを構築してテストしてください。
• 高度なオプション: カウントのみを返し、ハッシュは決して返さないケイパビリティチェックを実行します。空でないハッシュにアクセスできる場合は、値が MCP/エージェントの実行を経由することを説明し、明示的な承認を得たうえで、必要最小限の認証フィールドのみを移行します。
• ハッシュをチャットに貼り付けたり、印刷したり、コミットしたり、通常のプロジェクトフォルダに保存したりしないでください。ログインテスト後は、保護された一時的な成果物を削除してください。
• ケイパビリティチェックが失敗した場合、エージェントがシークレットを安全に扱えることを保証できない場合、または想定されるパスワードユーザーにハッシュがない場合は、そのユーザーにはリセットの経路を使用してください。OAuth ユーザーとパスワードレスユーザーは、ハッシュを持たないのが正しい場合があります。パスワードを独自にでっち上げないでください。

Lovable 側

• 自身の Supabase を接続した後、Lovable エージェントは edge function をそこにデプロイできます（エージェントに直接確認済み、config.toml が尊重されます）。edge function のシークレットは設定できません - 設定できるのはユーザーだけであり、Supabase ダッシュボードで行います。
• LOVABLE_API_KEY は管理されたワークスペースシークレットであり、Cloud とは独立しています。Cloud の削除後も存続します。再配線後も AI 機能は動作し続けます（Trap 25）。
• Supabase 統合を接続すると、.env が自動的に書き換えられます（正しい URL とキー、手動編集は不要）。ただし、最新の（TanStack）スタックプロジェクトで SSR を壊すテンプレートで src/integrations/supabase/client.ts を上書きする場合もあります（Trap 23）。
• GitHub 同期は双方向です。Supabase で削除した一時的なヘルパー関数は、リポジトリにまだ残っていれば戻ってきます - すべての場所で削除してください（Trap 24）。
• 移行において Remix は依然として動作しません - Lovable Cloud を継承します。

セキュリティ

• .backup ファイルには個人データと認証データが含まれ、機密性の高い認証情報が含まれている可能性があります。パスワードと同様に扱ってください: ローカルに保管し、決してコミットせず、移行後に削除してください。
• 移行中にデータベースのパスワードがチャット、スクリプト、または AI セッションに触れた場合は、最後にローテーションしてください（Dashboard > Settings > Database）。
• 移行の成果物を公開リポジトリにプッシュする前に、プロジェクトの参照、キー、メールアドレス、個人データがないかスキャンしてください。

聖なる順序

1. EXPORT      the database (button)
2. DOWNLOAD    the export + the storage files    ← they live inside Cloud
3. BUILD       the new Supabase (restore, fix, upload, deploy)
4. AUTH        test password reset, or explicitly run the MCP hash route
5. VERIFY      the 12-count gate — ALL GREEN or stop
6. REMOVE      Lovable Cloud                     ← only now, nothing before this is destructive
7. CONNECT     your own Supabase to the same project

置き換えが稼働し検証されるまで、何も削除しません。ステップ 6 より前のどの段階でも、アプリは Cloud 上でそのまま動作し続けます。いずれかのステップが失敗したら、停止して修正してください - ゲートがグリーンになるまで、Cloud がセーフティネットです。

同一プロジェクトパス（プライマリ）

全 33 ステップのプレイブックは references/same-project-path.md にあります。 実際に移行を実行するときに読んでください。全体像は次のとおりです。

フェーズ	ステップ	何が起こるか	人間の関与
1. ベースライン + GitHub	1-4	12 項目のインベントリ、リポジトリの接続、verify_jwt + シークレットのマップ	未接続なら GitHub を接続
2. エクスポート + ダウンロード	5-8	公式エクスポートを実行、Storage で検出、ダウンロード、ストレージファイルのダウンロード	エクスポートのクリック、ダウンロード
3. 移行先の作成	9-12	Supabase プロジェクト、セッションプーラーの接続文字列	コストの確認
4. リストア	13-16	zstd 対応の pg_restore、identities 修正パス、認証の判断、スナップショットの確認	高度なハッシュルートを承認するかリセットを使用
5. リストア後の修正	17-21	Cron の再作成 + ゾンビの探索、ゴースト行の削除、ファイルのアップロード、URL の書き換え、シーケンス	-
6. 関数 + シークレット	22-25	デプロイ（CLI/MCP/エージェント）、シークレットの再入力、AI の再接続、一時ヘルパーをすべて削除	シークレットの入力
7. ゲート	26-28	12 カテゴリの監査 vs ベースライン + テスト済みの認証パス + 画像の表示	ゲートの判断
8. 削除 + 接続	29-33	Cloud の削除、自分の Supabase への接続、統合の上書きの修正、最終的な整理	削除 + 接続のクリック

ハードストップ（どの移行レベルでも、決して省略しない）

1. Supabase プロジェクトを作成する前のコスト確認（ステップ 9）。
2. ゲート（ステップ 28）：すべての件数がグリーン + 選択した 認証パス（MCP による保持後の元のパスワード、または完了したリセット）を通した テスト済みのログインが 1 件、なければ続行しないでください。Cloud は安全網として残します。
3. 削除は唯一の破壊的なクリック（ステップ 29）であり、常にユーザーの 手によるもので、自動化されることはなく、ゲートより前に実行されることもありません。

いつ何を読むか

状況	読むもの
プライマリの移行を実行する	references/same-project-path.md
エクスポートが利用できない、DB が 5 GB 超、または元のプロジェクトをそのままにしておく必要がある	references/fresh-project-path.md
エクスポート方法の選択・比較	references/export-methods.md
ストレージヘルパー関数（fresh-project パス）	references/migrate-storage-function.md
症状に対する修正が必要	references/same-project-path.md の症状表、次に references/troubleshooting.md

新規プロジェクトパス（レガシーフォールバック）

完全な v3.1 フロー - 68 の決定論的ステップ、9 フェーズ、MCP 駆動のスキャンと 新しい Lovable プロジェクトへの再構築 - は references/fresh-project-path.md にあります。

次の場合に使用します。

• データベースが 5 GB のエクスポート上限を超えている（手動エクスポートについては、 プロジェクト ID を添えて [email protected] にメールしてください）。
• そのプロジェクトでエクスポート機能が利用できない、または失敗する。
• ユーザーが元の Cloud プロジェクトを稼働させたまま／そのままにしておきたい （元のプロジェクトへのリスクがゼロのステージング形式の移行）。

このリファレンスは独自のトラップ表（トラップ 1-16）とトラブルシューティングの行を 保持しています。

v4 で追加されたトラップ (17～26、すべて実際に発生し検証済み)

トラップ	重大度	説明	防止策
17	Critical	エクスポートは Cloud ストレージへ保存される - 削除すると消える	厳守すべき順序: エクスポート -> ダウンロード -> 最後に削除 (手順 5～7、29)
18	Blocker	brew libpq の pg_restore は zstd を欠き、.backup で失敗する	まず pg_restore --list でテストする。postgresql@18 (手順 13)
19	Critical	リストア時の FK 順序により auth.identities が失われる	件数チェック + 2 回目のデータのみパス (手順 15)
20	Silent bug	cron.job のリストア = 権限拒否。復元・再作成されたコマンドは古いプロジェクト URL を指し、死んだエンドポイントに対して実行される	cron.schedule + ゾンビ探索 + cron.alter_job (手順 17)
21	Silent bug	storage.objects のゴースト行がアップロードを妨げる (「resource already exists」)。protect_delete が SQL DELETE をブロックする	アップロード前に Storage API/CLI 経由で消去する。SQL は決して使わない (手順 18)
22	Silent bug	署名付き URL (?token=) は古いプロジェクトとともに無効になる。テキスト置換すると移行済みに見えてしまう	再生成するか NULL にする。決して書き換えない (手順 20)
23	Breaker	Supabase 連携が client.ts を上書きし、モダンなスタックで SSR を壊す	接続後の修正プロンプトで明示的な禁止事項を指定する (手順 31)
24	Zombie	一時的なヘルパー関数が双方向の GitHub 同期で復活する	Supabase とリポジトリの両方で削除する (手順 25)
25	Surprise (good)	LOVABLE_API_KEY は Cloud 削除後も残る (ワークスペースシークレット)	再配線する: サーバー関数 (推奨) またはキーをコピーする (手順 24)
26	Data loss	リストアはエクスポート時点のスナップショットであり、その後の書き込みは含まれない	書き込みがいつ停止したかを確認する。再エクスポートするか差分を再適用する (手順 16)

v4.1 で追加されたトラップ

トラップ	重大度	説明	防止策
27	Account lockout	現在の Lovable ドキュメントによると、公式エクスポートには使用可能なパスワードが含まれない	既定ではリセットする。MCP ハッシュ経由の方法は、機能確認・明示的な承認・安全な取り扱いの後でのみ使用する

人手による支援が必要な箇所 (同一プロジェクトのパス)

手順	ユーザーが行う必要があること	自動化できない理由
1	エディタで GitHub に接続する	ダッシュボード専用のフロー
5	Export project data をクリックする	ダッシュボード専用のボタン
7	エクスポート zip をダウンロードする	ブラウザでのダウンロード
8	ストレージファイルをダウンロードする (小規模プロジェクト)	ブラウザでのダウンロード (大規模ならスクリプト化可能)
23	Edge Function のシークレットを入力する	MCP/エージェントはシークレットを設定できない
29	Remove Lovable Cloud をクリックする	破壊的な操作であり、意図的に手動
30	自分の Supabase に接続する	ダッシュボードの OAuth フロー
33	OAuth プロバイダー、JWT シークレット	ダッシュボード専用の設定
コスト	Supabase プロジェクトのコストを確認する	MCP には明示的な確認が必要

プランの要件

ツール	必要なプラン	コスト
Lovable	Cloud を含む任意のプラン	変動制
Supabase	空きスロットがあれば Free でも可	$0～$10/月
Claude Code (オプション、すべてを自動化)	Pro または Max	$20/月～
claude.ai (オプション、CLI なしのルート)	Free/Pro	$0～
GitHub	Free	$0

ドキュメントリンク

リソース	URL
Lovable Cloud の詳細設定 (エクスポート、一時停止、削除)	https://docs.lovable.dev/features/advanced-settings
Lovable GitHub 連携	https://docs.lovable.dev/integrations/github
Lovable MCP	https://docs.lovable.dev/integrations/mcp-servers
Supabase: バックアップをリストアする	https://supabase.com/docs/guides/platform/migrating-within-supabase/dashboard-restore
Supabase: データベースのバックアップ	https://supabase.com/docs/guides/platform/backups
Supabase MCP	https://supabase.com/docs/guides/getting-started/mcp
Supabase Edge Functions	https://supabase.com/docs/guides/functions
Supabase Storage	https://supabase.com/docs/guides/storage
Supabase Auth	https://supabase.com/docs/guides/auth

Carol Monroe によるリソース

• このスキルが自動化する手動のウォークスルー: https://carolmonroe.com/blog/export-remove-lovable-cloud
• AI を使った移行ガイド（claude.ai ルート + Claude Code ルート）: https://carolmonroe.com/blog/migrate-lovable-cloud-with-ai
• レガシー MCP 移行ガイド（新規プロジェクトのパス）: https://carolmonroe.com/blog/lovable-cloud-mcp-migration
• claude.ai チャット向けの MCP セットアップ: https://carolmonroe.com/blog/connect-lovable-supabase-mcp-to-claude