Lovableを本番前に使うなら：Cloud・Supabase・GitHub syncを分ける基準

3行まとめ

このテーマをもう少し広げて見るなら、v0を本番前に使うなら：Project・Environment Variables・GitHubを分ける基準 と Replit Agentを本番前に使うなら：Checkpoints・Database・Deploymentを分ける基準 も合わせて確認してください。同じapp builder型の本番前チェックとして、環境変数、GitHub、公開設定の分け方を比較できます。

>

Cloud

Lovable Cloudか確認する。

Supabase

DBとauthの権限を見る。

GitHub

sync前提を守る。

Publish

metadataと公開範囲を見る。

Lovableは公開まで近いので、backendとhostingを先に分けます。

• Lovableはpromptからappを作り、Lovable CloudまたはSupabaseでbackendを持ち、publishまで進められるAI app builderです。
• 本番前に使うなら、backendがLovable CloudなのかSupabaseなのか、GitHub syncの前提、external hosting時のenvironment variables、publish時のmetadataを分けて確認します。
• 特にSupabaseを使う場合は、接続できたかだけでなく、auth provider、redirect URL、RLS、dev/stage/prod database、外部hosting側のenv varsまで見ます。

本文の事実確認には、Lovable公式docsのGetting Started、Supabase integration、GitHub integration、Publish、external deployment/hosting、Supabase troubleshooting、およびSupabase公式docsを使っています。Xで見かけるLovable、Lovable Cloud、Supabase、GitHub syncへの投稿は需要シグナルとして扱い、本文の根拠にはしていません。

この記事でわかること

Backend

Lovable CloudとSupabase。

Env

外部hostingへ移す値。

Sync

GitHub repoの移動やrename。

Review

UIとdata flowを確認。

Lovableでは、生成UIだけでなく接続先と共有先を確認します。

• Lovableを本番前に使う時に最初に分ける運用境界
• Lovable CloudとSupabase backendを見分ける考え方
• Supabase接続時にauth、RLS、env varsを確認する理由
• GitHub syncが止まりやすいrepo移動やrenameの注意
• Lovable外へhostingする時のenvironment variablesとOAuth redirect
• publish前にmetadata、SEO、公開範囲を確認する方法

Lovableは、AI app builderとして「作る」と「公開する」が近い道具です。Getting Started docsでも、backend capabilitiesをLovable CloudまたはSupabaseで追加し、step by stepでappをpublishできると説明されています。

便利ですが、本番前には「Lovableで動く」と「外部hostingでも安全に動く」を分ける必要があります。backend、database、GitHub、hosting、env varsがどこにあるかを曖昧にしないことが大事です。

前提知識

項目	内容	見方
Project		promptからappを作る。
Lovable Cloud		backend capabilitiesを提供。
Supabase		auth、storage、database連携。
GitHub		code syncと外部開発。

Lovableはapp builderとして使いつつ、backendとsource controlを分けて理解します。

Lovable公式docsでは、最初のproject作成、dashboard操作、backend capabilities追加、publishの流れが説明されています。backendはLovable CloudまたはSupabase integrationとして扱われ、GitHubやIDEでcode changeを行いながらLovableとsyncできることも説明されています。

Supabase integration docsでは、Lovable appをSupabase databaseへlinkし、authentication、data storage、backend featuresを使えるようにする流れが説明されています。external deployment docsでは、Lovable Cloudを使うprojectでは.envの値が必要になることも説明されています。

この記事の扱う範囲

項目	役割
Lovable Cloud	Lovable内で使うbackend capabilities
Supabase	authentication、database、storageの外部backend
GitHub sync	Lovableとrepositoryの同期
Publish	Lovable上でappを公開する
External hosting	Lovable外へdeployする
Environment variables	Supabase URL、publishable key、API keyなど
OAuth redirect	hosting先に合わせたcallback URL
Human review	UI、auth、data、secretの確認

2026年6月1日時点で公開されているLovable公式docsとSupabase公式docsを確認しています。導入時には、利用中のLovable plan、workspace設定、backend種別、Supabase project、GitHub repository、hosting先、secret管理を改めて確認してください。

注意点

この記事は、Lovableを否定するものではありません。Lovableはprototypeを速く形にするには便利です。ただし、本番前にはbackendとhostingの境界を人間が理解している必要があります。

まず6つの境界に分ける

項目	内容	見方
Prompt		依頼と完了条件。
Backend		Lovable CloudかSupabase。
Auth		providerとredirect。
GitHub		syncとreview。
Hosting		Lovableか外部hosting。
Data		開発用、確認用、本番用。

境界を分けると、Lovableで作ったappを本番前に点検しやすくなります。

Lovableを本番前に使うなら、最初に6つの境界を分けます。

境界	確認すること
Prompt	依頼内容、制約、完了条件
Backend	Lovable CloudかSupabaseか
Auth	provider、redirect URL、RLS
GitHub	repo、owner、branch、sync
Hosting	Lovable publishかexternal hostingか
Data	dev、stage、prodのdatabase分離

この6つを分けると、Lovableで作ったappを「Lovable上で動いた」だけで終わらせず、どの環境で何を確認したか説明できます。

app builder型の強み

app builder型の強みは、UI、database、auth、hostingまで近い距離で進められることです。Lovableもこの流れに合っています。アイデアをすぐappとして触れる形にできます。

app builder型の注意点

近い距離で進められるほど、backendやsecretの境界が見えにくくなります。Lovable CloudなのかSupabaseなのか、GitHubに何がsyncされているのか、外部hostingで必要なenv varsは何かを分けます。

判断基準

迷ったら、「appのcodeはどこにあるか」「backendはどこにあるか」「databaseはどこにあるか」「公開URLはどこで管理されているか」を紙に書けるかで判断します。

Lovable CloudとSupabaseを見分ける

Lovable Cloud

内蔵backendとして扱う。

Supabase

外部projectとして管理。

Settings

backend settingsを見る。

Exit

移行時のdata扱いを確認。

backendの種類が分からないまま公開しないことが出発点です。

Lovable Getting Started docsでは、backend capabilitiesとしてLovable CloudまたはSupabase integrationを使えると説明されています。一方、Supabase troubleshooting docsでは、Lovable backendがLovable CloudなのかSupabaseなのかを見分ける必要がある場面が説明されています。

最初に確認するのは、backendがどこにあるかです。

Lovable Cloudの場合

Lovable Cloudは、Lovable内でbackend capabilitiesを扱う流れです。external hostingへ出す時は、Lovable Cloudの値を.envから移す必要があることがdocsで説明されています。

見ること	理由
backend settings	Lovable Cloudか確認する
.env values	external hostingで必要になる
export/migration	外へ出す時の手順を確認する
access	誰がbackendを管理できるか

Supabaseの場合

Supabaseを使う場合は、Supabase側のproject、auth、RLS、storage、database backup、branchingを見ます。Lovable上で動いても、Supabase側のpolicyが弱いと本番では危険です。

移行時の注意

Supabase troubleshooting docsでは、Lovable Cloudを使う場合にSupabase projectへ直接accessできないケースや、backendをclone/migrateする必要があるケースが説明されています。外へ出す可能性があるなら、早めにbackend種別を確認します。

backend台帳を作る

projectごとに、backend種別、owner、database、auth provider、deployment先、env varsを台帳化します。app builderでは、この台帳が後から効きます。

Supabase接続はauthとRLSまで確認する

項目	内容	見方
Project		接続先を確認。
Auth		OAuth providerとredirect URL。
RLS		Row Level Security。
Env		URLとpublishable key。

Supabaseは接続だけでなく、authとdata policyまで確認します。

Lovable Supabase integration docsでは、Lovable appをSupabase databaseへlinkし、authentication、data storage、backend featuresを使えるようにする流れが説明されています。OAuth providerを使う場合は、Supabase側とLovable UI側の設定を合わせる必要があります。

接続できたかだけで判断しない方がよいです。

Supabaseで見る項目

項目	確認すること
project	どのSupabase projectへ接続しているか
auth	email、OAuth provider、redirect URL
RLS	Row Level Securityが有効か
policy	userごとのread/write範囲
env vars	URL、publishable key、service key
storage	public/private bucket設定

redirect URLを環境ごとに分ける

external deployment docsでは、Google ConsoleやGitHubなどOAuth app settingsでredirect URLsを新しいSupabase project URLへ更新する必要があると説明されています。hosting先が変わる時は、redirect URLも変わります。

RLSを後回しにしない

LovableでUIができると、dataが見えることに安心しがちです。しかしSupabaseではRLSとpolicyが本番の安全性を左右します。AIが生成したqueryが正しくても、policyが弱ければ他userのdataが見える可能性があります。

service keyをclientへ出さない

Supabaseの強いkeyはserver側で守る必要があります。Lovableで生成されたcodeをGitHubへ出す前に、client bundleへsecretが入っていないか確認します。

GitHub syncはrepo移動とrenameに注意する

項目	内容	見方
Repo name		renameに注意。
Owner		user/org変更に注意。
Branches		外部開発と同期を分ける。
Review		PRで差分を見る。

GitHub syncは便利ですが、repoの場所が前提になります。

Lovable GitHub integration docsでは、GitHubでcode changeを行いながらLovableとsyncできることが説明されています。一方で、repositoryをoriginal locationやoriginal nameから変えるとsyncが止まる可能性があることも説明されています。

GitHub syncは便利ですが、repoの場所が前提になります。

syncで守ること

項目	注意点
repository name	renameするとsyncが止まる可能性
owner	user/org変更に注意
repository location	original locationを保つ
branch	外部開発とLovable編集の対象を分ける
PR review	Lovable外の差分を人間が見る

GitHubをreview場所にする

Lovable内で動いたappでも、本番前はGitHubに出してPR reviewします。AIが作ったcodeほど、差分、secret、env vars、database access、auth flowを人間が見ます。

repo名を変えたくなった時

repo名やorgを変えたい時は、Lovableとのsyncを先に確認します。変えた後にsyncが止まると、Lovable側とGitHub側のどちらが正なのか分かりにくくなります。

PR templateを使う

PRには、Lovableで作った目的、backend種別、Supabase project、env vars、publish先、未確認事項を書きます。app builderの差分は、見た目だけでなく接続先もreview対象です。

外部hostingはenv varsを移す作業として見る

Build

外部環境でbuildする。

Env

必要な値を移す。

OAuth

redirect URLを更新。

Backend

Lovable Cloud依存を確認。

外部hostingはdeploy先変更ではなく、環境の再構成です。

Lovable external deployment docsでは、Lovable Cloudを使うprojectを外部hostingへdeployする場合、projectの.env fileから値が必要になると説明されています。Supabaseを使う場合も、URLやpublishable keyなどの値をhosting先へ設定します。

外部hostingは、deployボタンを押すだけではありません。環境を再構成する作業です。

外部hosting時に見る項目

項目	確認すること
build command	外部環境でbuildできるか
env vars	必要な値がhosting側にあるか
backend	Lovable Cloud依存があるか
OAuth	redirect URLを更新したか
domain	custom domainとcallback URL
logs	hosting側のerror log

.envをそのままGitHubへ置かない

.envにはsecretやbackend接続情報が含まれることがあります。GitHubへ出す時は、.env.exampleとsecret storeを分けます。

external hostingで壊れる理由

Lovable上では動いたが外部hostingでは壊れる場合、env vars不足、OAuth redirect URLのズレ、Supabase RLS、backend依存の移行漏れがよくあります。

env var checklist

外部hostingへ出す前に、必要なenv var名、値の置き場所、clientに出てよいか、serverで守るべきか、preview/prodで違うかを確認します。

Publishはmetadataと公開範囲を確認する

項目	内容	見方
URL		workspace URLやcustom domain。
Metadata		title、description、OG image。
SEO		reviewを実行する。
Access		誰に公開するか。

Publishは生成完了ではなく、公開情報を整える段階です。

Lovable Publish docsでは、publish時にworkspace-branded URLやmetadata、browser tab、search result、link preview、favicon、Open Graph imageなどを設定できることが説明されています。SEO reviewを実行できることも示されています。

Publishは、生成完了ではありません。公開情報を整える段階です。

publish前に見る項目

項目	確認すること
URL	workspace URLやcustom domain
title	browser tabや検索結果
description	検索結果やlink preview
OG image	共有時の見た目
favicon	Lovable logoのままか
SEO review	公開前に確認したか

公開範囲を分ける

社内preview、limited beta、public launchを分けます。app builderでは公開が簡単ですが、publicにする判断は別です。

metadataもreview対象

AIが作ったmetadataは、genericな表現になりやすいです。product名、対象ユーザー、説明文、OG imageを人間が確認します。

共有前に触る

URLを共有する前に、主要flow、auth、data、mobile layout、error stateを触ります。metadataだけ整っていても、appが壊れていては意味がありません。

Dev・Stage・Prodはdatabaseごと分ける

開発用

試作用DB。

確認用

公開前確認。

本番用

本番data。

Branch

Git branchとDBを対応。

Git branchだけでなく、databaseとenv varsも分けます。

Supabase managing environments docsでは、feature branchとlocal database、develop branchとstaging database、main branchとproduction databaseのように、branchとdatabaseを対応させる考え方が説明されています。

Lovableでも同じ発想が必要です。Git branchだけ分けても、databaseが同じなら安全ではありません。

environmentの分け方

環境	database	目的
Dev	試作用database	Lovableでの作業
Stage	staging database	公開前確認
Prod	production database	本番user data

env varsも分ける

dev、stage、prodでSupabase URL、publishable key、OAuth redirect、external API keyを分けます。Lovableとhosting先で同じ値になっているかを確認します。

branchだけでは足りない

GitHub branchを分けても、Supabase projectが同じならdataは共有されます。dataを守るには、databaseも分ける必要があります。

migrationの扱い

schema変更は、developmentで試し、stagingで確認し、productionへ適用します。AIが作ったmigrationをそのままproductionへ当てないようにします。

公開前レビューは生成UIとdata flowを分ける

項目	内容	見方
UI		主要画面とerror。
Auth		loginと権限。
Data		保存、更新、削除。
Secrets		client露出を確認。

AIが作ったappほど、UIとdataを別々に触って確認します。

Lovableで作ったappは、見た目が早く整いやすいです。だからこそ、公開前reviewではUIとdata flowを分けます。

生成UIを見る

観点	確認すること
layout	mobile、desktop、overflow
copy	genericすぎないか
empty state	dataがない時
error state	失敗時の表示
navigation	戻る、遷移、権限

data flowを見る

観点	確認すること
create	正しいuserに紐づくか
read	他user dataが見えないか
update	権限外更新ができないか
delete	誤削除や復元
auth	sessionとredirect
storage	public/private bucket

AIの完了報告だけで終わらせない

AIが「実装しました」と言っても、実際のuser flowを人間が触ります。特にauth、database、storage、payment、adminは手動確認を残します。

review logを残す

公開前には、確認したflow、未確認flow、使ったbackend、env vars、publish URL、GitHub commitを残します。後から戻す時の手がかりになります。

導入初週の進め方

1. 1日目

   backendなしprototype。

2. 2日目

   Lovable Cloudを確認。

3. 3日目

   Supabase接続を試す。

4. 5日目

   GitHub syncとPR review。

5. 7日目

   publishとexternal hostingを整理。

初週は公開速度より、backendとsyncの前提を確認します。

Lovableは、最初の1週間で「速く作る」だけでなく「backendを理解する」「GitHubとhostingへ出せる」「dataを分けられる」を確認します。

日	やること	目的
1日目	backendなしの小prototypeを作る	promptと生成UIを見る
2日目	Lovable Cloudを確認する	backend種別を理解する
3日目	Supabase接続を試す	auth、RLS、env varsを見る
4日目	GitHub syncを設定する	repo review場所を作る
5日目	外部hostingをdry-runする	env varsとOAuth redirectを見る
6日目	publish metadataを整える	public URL前の見え方を確認
7日目	dev/stage/prod方針を作る	本番化条件を決める

初週の評価軸

評価軸	見ること
backend理解	CloudかSupabaseか説明できるか
sync	GitHub repoが正しくつながるか
env vars	外部hostingに移せるか
auth	redirectとRLSが整っているか
review	UIとdata flowを確認できるか

広げる条件

次の条件を満たしたら、本番に近いtaskへ広げます。

• backend種別が分かる
• GitHub syncの前提を守っている
• Supabase RLSとauth providerを確認している
• external hostingに必要なenv varsを整理している
• dev/stage/prod databaseを分ける方針がある
• publish前のmetadataとSEO reviewを確認している

FAQ

Cloud?

backend settingsを見る。

Supabase?

RLSとredirectを確認。

GitHub?

repo位置を変えない。

Hosting?

env varsを移す。

迷ったら、appのcode、backend、hostingがどこにあるかを分けて確認します。

Lovable CloudとSupabaseのどちらを使うべきですか？

新規prototypeならLovable Cloudで早く始める選択肢があります。既存Supabase project、細かいDB運用、RLS、branching、外部hostingを重視するならSupabaseを検討します。

backendがどちらか分からない時は？

Lovableのbackend settingsとSupabase側のprojectを確認します。Supabase troubleshooting docsにも、Lovable backendがLovable CloudかSupabaseかを識別する考え方が示されています。

GitHub repoをrenameしてもよいですか？

Lovable docsでは、repositoryのoriginal locationやoriginal nameが変わるとsyncできなくなる可能性があると説明されています。renameやowner変更の前に、Lovable側のsync条件を確認します。

外部hostingで動かない時は何を見ますか？

env vars、OAuth redirect URL、Supabase RLS、backend依存、build command、hosting logを見ます。Lovable内で動いたappでも、外部環境では値やURLが違います。

Publish前にSEOまで見る必要がありますか？

public URLとして共有するなら見た方がよいです。Lovable docsではmetadata、browser tab、search results、link preview、favicon、OG imageの設定とSEO reviewが説明されています。

Dev・Stage・ProdはGitHub branchだけで十分ですか？

十分ではありません。Supabase docsではbranchとdatabaseを対応させる考え方が説明されています。branchだけ分けても、databaseが同じなら本番dataへ影響する可能性があります。

---

次に読むなら

参照した主な情報源

• https://docs.lovable.dev/introduction/getting-started
• https://docs.lovable.dev/integrations/supabase
• https://docs.lovable.dev/integrations/git-integration
• https://docs.lovable.dev/features/publish
• https://docs.lovable.dev/tips-tricks/external-deployment-hosting
• https://supabase.com/docs/guides/troubleshooting/identify-lovable-cloud-or-supabase-backend
• https://supabase.com/docs/guides/deployment/managing-environments

次に読むなら

更新履歴

1. 2026年6月1日

   Lovable公式docsとSupabase公式docsを確認して初版を作成しました。

導入時には利用中のLovable plan、backend、Supabase、GitHub設定を確認してください。

• 2026年6月1日: Lovable公式docsのGetting Started、Supabase integration、GitHub integration、Publish、external hostingとSupabase公式docsを確認し、初版を作成しました。