Lovableの代替案は2つのカテゴリに分かれます。異なる質問に答えるものです。プロダクトを立ち上げるときは、ワークフローを選択し、最初のパスが機能したあとにバックエンドを誰が運用するかを決めます。すでにLovableアプリを運用している場合、最初の仕事は棚卸しです。Lovableの公式ドキュメントでは、アプリケーションのソースはあなたのものであり、それを移動することは書き直しではなくデプロイメント変更だと述べています。難しい仕事は別のところにあります。データとサービスが実際の仕事を要求します。以下は5つのセクションです。順番に、新規構築テーブル、現在のポータビリティ事実、フレームワークチェック、既存アプリテーブル、本番受け入れチェックリストです。
2人の読者、2つの異なる決定
ゼロから始める場合は、各ツールがあなたのワークフローにどうフィットし、デモが動いたあとに何を保守しなければならないかを比較してください。デモは簡単な部分です。ビルダーの優劣より、6ヶ月後にデータベース、デプロイメントパイプライン、ログインシステムを誰が運用するかが重要です。
すでに機能しているアプリについては、別のツールでリビルドするのは待ってください。棚卸しから始めましょう。それが何に依存しているかを特定します。コードがどこにあるか、フロントエンドがどこで動くか、バックエンドがデータをどこに保存しているか、どのAI機能とコネクターがLovableを通じて実行時にルーティングされているかです。
ここは人が飛ばす部分です。Lovableに留まることは完全に有効な選択肢です。Lovableの所有権ガイドは、マネージドセットアップをほとんどのアプリの推奨として標識し、データの保存地域マンデート、サポートされていないネットワーク、自己管理ホスティングを必要とするポリシーなどの実際の制約に直面するときだけコンポーネントを移動するよう述べています。これらが適用されず、チームの誰もが追加の運用を所有したくない場合、移動はリターンのないコストです。
新規構築：決定テーブル
このテーブルは私の判断を表しています。利用可能な各ベンダーの公式ドキュメントから引き出しました。ランキングではなく、どのツールがより良いアプリを生産するかについての主張はしません。
| オプション | 適したワークフロー | ソースとリポジトリモデル | バックエンドとデプロイメント責任 | 適合性確認タスク |
|---|---|---|---|---|
| Lovable | 1つのプラットフォームが編集、ホスティング、バックエンドを処理するチャット駆動のビルド | Lovableで管理されたコード。すべてのプランでGitHub、GitLab、BitbucketへのGit同期 | Lovableはホスティングと組み込みバックエンドを実行できます。移動する部分についてのみ運用を引き継ぎます | フローをビルドし、Gitに同期し、ローカルでクローンして実行します |
| v0 | レビューとデプロイメントで終わるプロンプト・ツー・アップ作業 | 実際のコード。v0はデプロイメントまたはレビュー用のプルリクエストを開くことを説明しています | Vercelベースのインフラストラクチャへのワンクリックデプロイ。バックエンドは統合を通じて接続 | フローをデプロイし、プルリクエストを通じて変更します |
| Bolt | ブラウザベースのビルダー。独自のGitヒストリーが必要な場合に使用 | BoltはGit統合をドキュメント化しています。テストリポジトリでラウンドトリップを確認してください | Bolt Cloudはホスティング、組み込みデータベース、認証、ストレージ、サーバー機能を含みます | 永続的なデータとサインインを備えたフローを構築し、公開して、Gitワークフローを検証します |
| Replit | 1つのクラウドワークスペース内でのビルドとホスティング | プロジェクトはReplit ワークスペース内に存在します。現在のGitオプションを確認してください | RepilitはDeploymentsを通じた公開をドキュメント化しています。どのタイプがサーバーコードを実行するかを確認してください | フローを公開し、再デプロイして、データが保持されることを確認します |
| 開発者が管理するリポジトリとツーリング | エンジニア、コードレビュー、既存パイプラインを持つチーム | 独自のリポジトリ、任意のエディターまたはコーディングエージェント | CI/CD、ホスティング、データベース、認証を自社で運用 | スターターをスカフォルドし、フローを構築し、パイプラインを通じてデプロイします |
最後の行はオフザシェルフの製品ではなくワークフローを説明しています。パーツを自分で組み立てます。スタック、ホスト、エージェントまたはエディターを選択し、さらに下記の全ての運用作業を担当します。そのルートのフレームワークを検討している場合、Astro対Next.jsおよびNext.jsとSupabaseのページが標準的な出発点をカバーしています
証明タスクはすべての候補に対して同じ形状をとります。小規模に保ちますが、現実的にします。永続的なデータ、認証、ライブデプロイメントを備えた1つの現実的なユーザーフローを構築します。生成されたスクリーンショットは何も証明しません。アカウントの登録、レコードの永続化、ログアウト、ログバックイン、そのレコードの再表示は大いに証明します
Lovableが実際に持ち出せるもの
現在のポータビリティの事実はLovableのデプロイメントガイドと所有権ガイドから来ています:
- Git同期は全プランで利用可能です(GitHub、GitLab、Bitbucket)。コードベースのダウンロード(1回限りの.zipスナップショット)は有料プランで利用可能です
- どちらのパスもアプリケーションソース(設定とデータベースマイグレーションファイルを含む)を提供します。どちらもデータベース内のレコードまたはストレージ内のファイルは含みません
- データベース行とストレージファイルは別々にエクスポートが必要で、元のものを廃棄する前に宛先で検証します
- Lovableを開発ツールとして保つことができますが、別のホストが本番環境を提供します。Git同期でリポジトリを接続し、別のホストがそこからデプロイするようにします
GitHub統合は注目する価値のある制約を持っています。いくつかは運用上不便です。Lovableは一度に1つのブランチのみ編集および同期します。Git同期は常に新しいリポジトリをプロビジョニングし、既存のものにプロジェクトを接続することはできず、切断後の再接続は別の新しいリポジトリを作成します。リポジトリはデフォルトで非公開です。削除すると同期が停止します
コードはロックインされていません。それは有用ですが、移行の全部ではありません。ソースをリポジトリに保存することで、Lovableへの実行時依存性は解消されません。既存アプリテーブルではその区別に留意してください
フレームワークを確認してからホストを選ぶ
Lovableのドキュメントでは、2026年5月13日以降に作成された新しいアプリはTanStack Startを使用し、サーバーコードを実行します。それより前のアプリは異なります。ReactとViteに依存し、静的ファイルにビルドされます。Supabase統合ドキュメントでは、2026年6月22日がエンタープライズプランに関連する機能（あなた自身のSupabaseプロジェクトでの組み込み支払い）について記載されているため、全アカウントに一括の作成日ルールを適用することは避けてください。
実際のプロジェクトを確認してください。コードタブでpackage.jsonを開きます。TanStack Startプロジェクトはdependencies下に@tanstack/react-startをリストアップしています。古いReactおよびViteプロジェクトはそうではありません。
ホスティングの影響は異なります。
- TanStack Start: ホストはサーバー部分（サーバーサイドレンダリング、サーバー関数、APIルート）を実行する必要があります。静的ファイルのみを受け取るホストはこれらの機能を実行しません。オブジェクトストレージやCDNだけでは十分ではありません。Lovableはコンテナまたは独自のサーバーなど、Nitroが検出するプラットフォームを指しています。また、package.jsonにnitroがリストアップされていることを確認してください。ないとビルドがLovable外のホスト向けにアプリをパッケージ化できません。
- 古いReactおよびVite:
dist/の静的出力をNginxなどの静的ホスト、CDN、またはウェブサーバーにデプロイし、クライアント側のルートが機能するようにindex.htmlへのフォールバックを設定します。
もう一つの落とし穴: VITE_というプレフィックスの付いた変数はビルド時に埋め込まれ、実行時には読み込まれません。これはチームを引っかかります。組み込みバックエンドを使用する場合、Lovableはnpm run buildを実行する前にVITE_SUPABASE_URLとVITE_SUPABASE_PUBLISHABLE_KEYを設定するよう指示します。
ここではプロバイダー別のデプロイメントレシピを省略しました。これは意図的なスコープ管理です。Lovableのガイドに現在のステップが詳しく記載されており、サーバーレンダリングプロジェクトの場合は、トラフィックを切り替える前にサーバーレンダリングページの読み込みとサーバー関数の実行などのチェックを規定しています。
既存アプリ: 4つのパスの比較
| パス | 変わらないもの | 移動するもの | 引き続きLovableが請求または運営 | 検証する作業 | 運用責任者 |
|---|---|---|---|---|---|
| 完全管理型セットアップを保持 | すべて | なし | ホスティング、組み込みバックエンド、AI機能およびコネクタ。クラウド使用はワークスペースクレジットから引かれます | コンプライアンスおよびリリース要件を満たしていることの確認 | Lovableがインフラストラクチャを実行、あなたが製品を所有 |
| フロントエンドホスティングのみを移動 | 組み込みバックエンド、AI機能、コネクタ。Lovableは編集ツールのままでいられます | フロントエンドのビルドとデプロイ | バックエンド、AIおよびコネクタはLovableを通じて実行し続ける | ホスト環境変数、サーバーシークレット、サインインリダイレクトURL、ビルド時のVITE_値、TanStack Startのサーバー機能 | フロントエンドパイプラインとログはあなた、バックエンドはLovable |
| ビルトインバックエンドを自分のSupabaseプロジェクトに移動する | Gitで同期するコード。フロントエンドは現在地に留まるか移動するか選択可能 | データベース、認証、ストレージ、機能をマネージドまたはセルフホスト型Supabaseに移す | AI機能とコネクターは引き続きLovableを経由して実行される可能性がある | データ復元、認証、ストレージ、アクセスポリシー、Edge Functions、シークレット | Supabaseダッシュボード内およびあなたのSupabase課金下で、すべてあなた |
| Lovableから完全に離脱する | ソースコード | フロントエンド、バックエンド、データ、およびAIとコネクター呼び出しの代替 | 代替が完成して受け入れられたら何もない | 下のチェックリスト全体 | すべてについてあなた |
そのテーブルの中に間違えやすい項目が2つある。
まず、バックエンドの移行はトグルスイッチではない。Lovableは、ビルトインバックエンドからSupabaseへのプロジェクト転送を1ステップで行うことができず、逆プロセスも同じだと述べている。ドキュメント化されたルートはより手動的だ。スキーマの再作成とデータの手動移動が必要になる。アクティブなバックエンドからエクスポートし、新しいバックエンドを接続し、Lovableにスキーマの再構築を指示する。
次に、サポートされるターゲットはマネージドSupabaseとセルフホスト型Supabaseのみだ。PostgreSQLデータベースだけを移すと、認証、ストレージ、リアルタイム機能、Edge Functionsが残される。プレーンなPostgreSQLか別のプロバイダーに切り替えるには、これらの代替を自分で構築する必要があり、Lovableはこのパスをサポートしていない。それは直接的な移行ではなく、本物のエンジニアリング労力だ。そのルートを取る場合、サーバーレスデータベースの概要がターゲットを比較するのに適切な場所だ。
ビルトインバックエンドを離脱すると、ネイティブツーリングも削除される。エディター内のDatabase、Users、Storage、Secrets、Jobs、Logsビュー、ワンクリック復元対応の日次バックアップ、Lovable設定のGoogleサインインなどのマネージド認証を失う。自分のSupabaseプロジェクトを実行するには、自分のSupabaseサブスクリプションと直接的なインフラ管理が必要だ。
そしてソースの中に別のビルダーが完全なLovableバックエンドをインポートするという記述はない。起こらないと想定しておこう。
本番環境受け入れチェックリスト
インベントリから始めよう。実際のプロジェクトについて、以下をリストアップする。
- データとスキーマ(移行ファイルは
supabase/migrations/の下にある) - 認証ユーザーとプロバイダー
- ストレージファイルとアクセスポリシー
- リアルタイムサブスクリプション
- エッジ関数またはサーバー関数
- シークレット
- スケジュール済みジョブとウェブフック
- AIアクセスとアプリコネクター
その後、以下の順序で進めます。
- リポジトリをクローンして、実際のコードをローカルで実行します。これにより、インストール内容、依存関係、環境から読み込まれる内容が明らかになります。
- フレームワークとランタイムを特定します(上記の
package.jsonチェックを参照)。 - データエクスポートを本番環境ではなくステージング プロジェクトに復元します。
- More → Storageからストレージファイルをダウンロードし、ステージング ストレージに読み込みます。
- サインアップ、ログイン、OAuthリダイレクトをテストし、アカウント継続性を確認します。Lovableのデータベース エクスポート ドキュメントでは、Supabaseプロジェクトに復元するとユーザーのパスワードが保持されること、切り替え時にサインインしていたユーザーは再度サインインする必要があることが記載されています。推測せず、検証して、Supabaseの現在のユーザー移行ガイダンスに従ってください。認証ページも参照してください。
- 異なるロールの実際のアカウントで、ファイルアクセスと権限をテストします。
- Row Level Securityをチェックします。すべてのテーブルには、各行の読み取りと書き込みができるユーザーを制限するポリシーが必要であり、Lovableではこれらをsupabaseダッシュボードで自分で検証するよう指示しています。
- テストモードで重要な有料流またはステート変更フローを実行し、実顧客に課金しないようにします。
- レコード数を比較し、ストレージから代表的なファイルを開きます。
- ログ、バックアップ、復旧、ロールバック パスを検証します。
- Lovableを通じて実行されたすべてのものを置き換えます。AIアクセス、コネクター、スケジュール済みジョブです。
- その後のみ、元のサービスを削除します。
ステップ12は警告に値します。これを真剣に受け取ってください。Lovableデータベースを削除すると、ファイルと一緒にエクスポートも削除されるため、事前にダウンロードして検査してください。このプロセスの処理中に、認証情報をチケット、チャット、リポジトリに貼り付けないでください。
もう1つの落とし穴。2つのLovableプロジェクトが単一のSupabaseプロジェクトを共有する場合、互いのシークレット(LOVABLE_API_KEYを含む)を上書きして、それに依存するすべての機能を破損させます。
現状を保つ、ハイブリッドにする、または離れる
ほとんどの実際の決断はその中間に落ち着きます。
- 別のデプロイパイプラインの要件は、フロントエンドの移動のみで対応できる場合もあります。
- 独自のアカウントにデータベースが必要な場合は、バックエンド移行が必要な場合もあり、それ以上は必要ありません。
- オーサリング体験への不満は、自分のエディターでエクスポートされたリポジトリで作業することのみを意味する場合もあります。一方、LovableはGit同期を通じて接続されたままです。
メンテナンス所有者を割り当て、サービスをキャンセルする前にすべての残りのランタイム依存関係をマップします。ドキュメントは簡潔にしてください。誰がデプロイするか、誰がバックアップを復元するか、誰がシークレットをローテーションするか、どの機能がまだLovableを呼び出すかを述べる必要があります。所有者を指定できない場合は、今のところ現状を保ってください。
ハンドオーバーについて別の意見が欲しければ、リポジトリ、デプロイメント マップ、エンジニアリング監督を要するユーザー フローを エージェント型エンジニアリング チーム に送信して、オーナーシップの境界と残り作業の評価を受けてください。求めることについては正確に伝えてください。これは評価であり、保証されたプッシュボタン型の救済ではありません。
FAQ
Lovable エディタとエージェントをセルフホストできますか？
いいえ。Lovable は、エディタと AI エージェントはマネージド サービスとして動作し、セルフホストもカスタマー VPC 内への導入もできないと明記しています。ただし、これらで構築したアプリケーションはどこでもホストできます。
別のビルダーに切り替えたら、バックエンドを引き継げますか？
ソースには引き継げることを示す情報がありません。別の作業として計画してください。データとファイルをエクスポートし、Git または ダウンロード経由でコードベースを転送し、転送先で認証、シークレット、サポート サービスを再度設定してください。
無料プランを使っている場合、.zip ダウンロードだけで足りますか？
Lovable の直接コードベース .zip ダウンロードは有料プランで利用可能です。Git 同期は異なります。Git 同期はすべてのティアで利用可能なため、まずそのルートをテストしてください。
主な注意点は明確です。エクスポートされたコードはあなたのものですが、データベース レコード、ストレージ ファイル、認証設定、Lovable 管理の AI とコネクタは個別のマイグレーションが必要であり、自動的には実行されません。カットオーバー前にインベントリを行ってください。package.json を確認し、すべての依存関係をインベントリして、何もキャンセルする前にステージングでマイグレーションをテストしてください。