Bolt.newを本番前に使うなら：Version History・Database・GitHubを分ける基準

3行まとめ

Version

codeの復元点として見る。

Database

BoltとSupabaseを分ける。

GitHub

共同作業とreviewに使う。

Hosting

公開先を先に決める。

Boltは作る速度が速いぶん、戻せるものと戻せないものを分けて見ます。

• Bolt.newはbrowser内でappを作りやすいAI app builderですが、Version History、database、GitHub、hosting、environment variablesは別々に扱う必要があります。
• Bolt公式docsでは、Version Historyは過去versionのpreviewとrestoreに使えますが、database restoreには対応しないと説明されています。
• 本番前に使うなら、Bolt DatabaseとSupabase、GitHub連携、Bolt hosting/Netlify、環境変数の共有範囲、公開前reviewを分けて確認します。

本文の事実確認には、Bolt公式support docsのVersion History、Backups、Database、Supabase、GitHub、Netlify/hosting、Project settings、Sharing、およびSupabase公式docsを使っています。Xで見かけるBolt.new、StackBlitz、Supabase連携、Netlify公開への投稿は需要シグナルとして扱い、本文の根拠にはしていません。

この記事でわかること

Restore

Version Historyの対象。

Supabase

database接続とdata保護。

Env

secretと共有権限。

Review

user flowとdata flow。

Bolt.newではUIだけでなく、dataと公開経路を分けると安全に進められます。

• Bolt.newを本番前に使う時に最初に分ける運用境界
• Version Historyで戻せるものと戻せないもの
• Bolt DatabaseとSupabaseの使い分け
• GitHubをreviewと外部公開の基盤として使う考え方
• Bolt hostingとNetlifyをどう分けるか
• 環境変数と共有権限を公開前に確認する理由

Bolt.newは、browserでappを作りながら、その場でpreviewし、必要に応じてdatabaseやhostingへつなげられる道具です。prototypeを素早く作るには便利です。

ただし、app builder型の道具は「動いた」から「本番で安全」までの距離が見えにくくなります。特にdatabase、environment variables、deployment、version restoreは、UIの見た目とは別に確認します。

前提知識

項目	内容	見方
Version History		過去versionをpreview、restore。
Bolt Database		projectに作られるdatabase。
Supabase		外部database連携。
GitHub		version controlと外部deploy。

Boltはapp builderとして使いつつ、version管理とdata管理を分けて理解します。

Bolt公式support docsでは、Version Historyがprojectの過去versionをtimelineとして見られ、previewしてrestoreできる機能として説明されています。また、GitHubを使うとBolt外でversion control、共同作業、branching、詳細な履歴、他hostingへの公開がしやすくなると説明されています。

Database docsでは、Bolt DatabaseとSupabaseの選択肢があり、新規projectではBolt Databaseが扱いやすい一方、より高度なdatabase管理や既存Supabase projectを使う場合はSupabaseが選択肢になると説明されています。

この記事の扱う範囲

項目	役割
Version History	Bolt内で過去versionをpreview、restoreする
Backups	自動または手動で戻れるcopyを持つ
Bolt Database	Bolt project向けのdatabase
Supabase	外部database管理や既存project連携
GitHub	version control、review、外部deploy
Bolt hosting	Bolt内の既定公開先
Netlify	代替hostingとdeploy先
Environment variables	keys、URLs、secretの管理

2026年6月1日時点で公開されているBolt公式support docsとSupabase公式docsを確認しています。導入時には、利用中のBolt agent、projectのdatabase種別、hosting設定、Supabase権限、GitHub連携、secret管理を改めて確認してください。

注意点

この記事は、Bolt.newを否定するものではありません。むしろ、素早くappを作れるからこそ、code、data、hosting、secretを分けて本番前に点検するための記事です。

まず6つの境界に分ける

項目	内容	見方
Prompt		依頼と完了条件。
Version		codeのrestore。
Database		schemaとdata。
GitHub		branchとreview。
Hosting		公開先と制約。
Env		secretと閲覧権限。

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

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

境界	確認すること
Prompt	依頼内容、制約、完了条件
Version	Version Historyとrestore対象
Database	Bolt Database、Supabase、data restore
GitHub	branch、review、外部deploy
Hosting	Bolt hosting、Netlify、backend制約
Env	secret、URL、閲覧権限

この6つを分けると、Boltで作ったappを「できたから公開」ではなく、「どこを確認したから次へ進む」と説明できます。

Boltで速く作れるもの

Boltは、frontend、basic app flow、database付きprototype、authentication周りの初期形を速く作る用途に向きます。Supabaseやhostingに近い導線もあるため、prototypeから公開候補まで進めやすいです。

本番前に止めるもの

本番data、payment、user authentication、admin機能、public deployment、secretは止めて確認します。AIが作ったかどうかに関係なく、ここは人間が見るべき層です。

判断基準

迷ったら、「Version Historyで戻るのはcodeか、dataも戻るのか」「GitHubにreview可能な履歴があるか」「環境変数を誰が見られるか」を確認します。

Version Historyはcodeの復元点として見る

Preview

戻す前に内容を見る。

Label

分かる名前を付ける。

Restore

project filesを戻す。

GitHub

高度な履歴はrepoで管理。

Version Historyは便利ですが、database restoreとは分けて考えます。

Bolt docsでは、Version Historyを使ってprojectの古いversionをbrowse、preview、label、restoreできると説明されています。Backups, restore, and version history docsでも、Version Historyがrecommendedなrestore方法として示されています。

これは便利です。ただし、Version Historyを万能のrollbackと考えない方がよいです。

Version Historyで見る項目

項目	見ること
preview	戻す前に画面とfileを確認する
label	意味の分かる名前を付ける
restore	project filesを戻す
chat history	直近のversionへ戻る手がかり
manual backup	local copyとして保管する

database restoreではない

Bolt docsでは、Version History and database restoresについて、以前のproject versionへrestoreしてもcurrent databaseは変わらないと説明されています。これはとても重要です。

つまり、UIやcodeを戻しても、database schemaやdataがその時点へ戻るとは限りません。

GitHubと役割を分ける

Bolt内のVersion Historyは、個人作業やsimple editsには便利です。一方で、advanced collaboration、branching、detailed historyが必要な場合はGitHubが必要になるとBolt docsで説明されています。

restore前の確認

restoreする前に、現在のdatabase、環境変数、外部serviceの状態を見ます。codeだけ戻しても、外部状態が残っているとappが別の壊れ方をすることがあります。

DatabaseはBoltとSupabaseで戻し方が違う

項目	内容	見方
Bolt Database		新規projectで扱いやすい。
Supabase		高度な管理や既存project向け。
Restore		version復元ではdataは戻らない。
Claim		Bolt databaseをSupabase側で扱う。

databaseはVersion Historyの外側にあるものとして扱います。

Bolt Database docsでは、新規projectでAgentが必要に応じてdatabaseを作れること、databaseが必要ない場合はpromptでdatabaseを使わないように明示できることが説明されています。Supabase integration docsでは、BoltからSupabaseへ接続し、既存projectまたは新規projectを使えることが説明されています。

重要なのは、Bolt DatabaseとSupabaseを同じものとして扱わないことです。

Bolt Databaseに向く場面

場面	理由
新規prototype	setupが少なく始めやすい
simple app	標準機能で足りる
早い試作	database導入の摩擦が少ない
Bolt内完結	外部運用を増やさずに済む

Supabaseに向く場面

場面	理由
既存Supabase projectがある	現在のdataやauthを使える
高度なDB管理が必要	SQL editorやmonitoringを使いたい
teamでDBを運用する	Supabase側の権限やbranchingを見る
本番運用に近い	migrationやRLSを明示できる

data lossの注意

Bolt Supabase docsでは、既存Bolt databaseがあるprojectにSupabase databaseをconnectするとconnectionが置き換わり、data lossにつながる可能性があると説明されています。既存dataを維持したい場合は、Bolt databaseをSupabaseでclaimする選択肢が説明されています。

database種別を台帳に残す

projectごとに、Bolt DatabaseなのかSupabaseなのか、誰がownerなのか、restore方法は何かを残します。後から見て分からない状態にしない方が安全です。

Supabase接続は環境変数と権限を先に見る

Connect

account連携を確認。

Project

既存か新規かを選ぶ。

Env

keysとURLを変数で扱う。

RLS

data accessを制御する。

Supabaseを使うなら、接続先とsecret管理を先に確認します。

Bolt Supabase docsでは、Supabase accountをBoltへconnectし、project settingsからSupabase databaseを扱えると説明されています。Introduction to databases docsでは、databaseへ接続する時、keysやURLsはenvironment variablesへ置くpatternが推奨されています。

Supabaseを使うなら、接続より先に環境変数と権限を見ます。

Supabase接続前に見る項目

項目	確認すること
account	誰のSupabase accountで接続するか
project	既存projectか新規projectか
org owner	claimや管理に必要な権限
env vars	URL、anon key、service keyの扱い
RLS	Row Level Securityとpolicy
data	sample dataか本番dataか

service roleをclientへ出さない

Supabaseでは、client側で使ってよいkeyと、server側で守るべきkeyがあります。Boltで生成されたcodeをreviewする時は、service roleのような強いkeyがbrowser側へ出ていないかを確認します。

Supabase branchingも検討する

Supabase公式docsでは、GitHub workflowやbranchingによりpreview environmentを作れることが説明されています。本番前には、production databaseへ直接変更するのではなく、previewやstagingでmigrationを確認する流れを検討します。

RLSは後回しにしない

AI app builderで作ったappは、UIが動くことを優先しがちです。Supabaseを使うなら、RLSとpolicyが想定通りかを早めに確認します。

GitHubは共同作業と公開前reviewに使う

項目	内容	見方
History		変更履歴をrepoに残す。
Review		PRで差分を見る。
Branch		公開前の検証を分ける。
Deploy		他hostingへつなげる。

Bolt内のVersion HistoryとGitHubは、用途を分けて併用します。

Bolt Version History and GitHub docsでは、Bolt内のVersion HistoryとGitHubの役割が分けて説明されています。GitHubを使うと、version control、共同作業、branching、詳細な履歴、他hostingへの公開がしやすくなります。

本番前には、GitHubをreviewの場所として使います。

GitHubで見る項目

項目	役割
repository	codeをBolt外にも残す
branch	公開前の変更を分ける
pull request	差分とreviewを残す
actions	testやbuildを自動化する
deploy	hosting serviceへつなげる

Bolt内だけで完結しない判断

個人prototypeならBolt内だけでも進められます。teamで本番へ近づけるなら、GitHubへ出し、PRでreviewし、CIで最低限のtestを走らせます。

commit前に整える

Boltで生成されたcodeは、使わないfile、hardcoded secret、test不足、巨大なdiffが残ることがあります。GitHubへ出す前に、差分を読みやすくします。

PR templateを使う

PRには、Boltで作った目的、確認したflow、database種別、環境変数、未確認事項を書きます。AI生成だからこそ、人間がreviewできる形へ戻します。

HostingはBolt hostingとNetlifyを分ける

項目	内容	見方
Bolt hosting		新規projectの既定公開先。
Netlify		選択肢として使える。
Backend		hostできる範囲を確認。
Domain		custom domainを管理する。

hostingは公開ボタンではなく、app構成に合う公開先として選びます。

Bolt hosting docsでは、新規projectはBolt hostingでpublishされるのが既定であり、Netlifyも選択肢として使えると説明されています。既存projectや以前の公開時期によって、Netlifyで公開されている場合もあります。

hostingは「どこでも同じ」ではありません。

Bolt hostingに向く場面

場面	理由
Bolt内で完結したい	publish導線が近い
simple frontend	管理が少ない
custom domainもBoltで扱う	設定をまとめやすい

Netlifyに向く場面

場面	理由
既存Netlify運用がある	teamのdeploy flowに乗せやすい
GitHub連携を使う	PR previewやCIに寄せやすい
hosting設定を細かく管理したい	Netlify側の機能を使える

backend制約を見る

Bolt Netlify docsでは、Netlifyはdatabaseやtraditional backendをhostできない例が説明されています。frontendだけのhostingと、databaseやbackendが必要なappを混同しないようにします。

公開先を後から変える時

公開済みprojectのhostingを変える場合、domain、env vars、database接続、redirect、auth callback URLを確認します。hosting変更は単なる公開先変更ではありません。

環境変数はviewerとeditorの違いまで見る

Editors

環境変数を扱える。

Co-owners

管理権限を確認。

Viewers

secretを見られない。

Runtime

値がないと動かない機能がある。

環境変数は動作だけでなく、共有権限も確認します。

Bolt Sharing docsでは、environment variablesを見られるのはEditorsとCo-ownersに限られ、Viewersは見られないと説明されています。また、環境変数に依存するprojectでは、Viewers側で一部がloadされない場合があると説明されています。

これはsharing時に重要です。

環境変数で見る項目

項目	確認すること
key name	client用とserver用を分ける
value	secretを直書きしていないか
scope	projectごとに必要な値か
role	editor、co-owner、viewerの違い
deploy	hosting側にも設定されているか

viewerで壊れる場合

Viewersが環境変数を見られないため、projectの一部が動かないことがあります。共有する相手に何を見せたいのか、previewなのか、共同編集なのかを分けます。

hosting側のenvも確認する

Bolt内で動いても、Netlifyや他hosting側に環境変数がなければ動かないことがあります。deploy先ごとにenv varsを確認します。

secret露出の確認

生成されたfrontend codeにsecretが直接入っていないかを見ます。Supabase anon keyのようにclientで使う前提のkeyと、serverで守るkeyを混同しないようにします。

公開前レビューはuser flowとdata flowに分ける

項目	内容	見方
User flow		画面操作を通す。
Data flow		保存、更新、削除を見る。
Auth		ログインと権限を見る。
Secrets		client露出を確認。

AIが作ったappほど、flowとdataを実際に触って確認します。

Boltで作ったappは、画面が動くところまで早く到達します。だからこそ、公開前reviewはuser flowとdata flowに分けます。

user flowを見る

flow	確認すること
signup/login	auth、error、logout
create	入力、validation、保存
update	編集と反映
delete	確認、権限、復元
search/filter	empty stateとerror
admin	access control

data flowを見る

flow	確認すること
database write	正しいtableへ入るか
database read	他user dataを読めないか
migration	schema変更が管理されているか
backup	戻し方があるか
env	deploy先で値がそろっているか

AIが作った説明を鵜呑みにしない

AIが「完了」と言っても、人間がappを触って確認します。特にauth、database、payment、admin、deploymentは、実際のflowで確認します。

公開前の最低ライン

公開前には、主要flow、database権限、environment variables、hosting設定、rollback方法、GitHub上の差分を見ます。これが揃うまでは、prototypeとして扱います。

導入初週の進め方

1. 1日目

   databaseなしのprototype。

2. 2日目

   Version Historyを試す。

3. 3日目

   GitHub連携を確認。

4. 5日目

   database接続とenvを確認。

5. 7日目

   hostingと公開前reviewを整理。

初週は公開速度より、戻し方と共有範囲を確認します。

Bolt.newは、最初の1週間で「速く作る」だけでなく「戻せる」「reviewできる」「公開前に止められる」を確認します。

日	やること	目的
1日目	databaseなしの小prototypeを作る	promptとVersion Historyを見る
2日目	Version Historyでpreviewとrestoreを試す	codeの戻し方を理解する
3日目	GitHub連携を確認する	review場所を作る
4日目	Bolt Databaseを使う小機能を試す	data flowを見る
5日目	Supabase接続とenv varsを確認する	外部databaseの扱いを見る
6日目	Bolt hostingまたはNetlifyでpreviewする	公開先の違いを見る
7日目	公開前checklistを作る	本番へ進める条件を決める

初週の評価軸

評価軸	見ること
version	戻したい場所へ戻れるか
database	data restoreの制約を理解したか
GitHub	diffをreviewできるか
env	secretと共有権限を説明できるか
hosting	app構成に合う公開先か

広げる条件

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

• Version Historyとdatabase restoreの違いを説明できる
• GitHubにreview可能な履歴がある
• database種別とownerが分かる
• environment variablesのscopeと閲覧権限が整理されている
• hosting先ごとの制約を確認している
• user flowとdata flowを人間が確認している

FAQ

Restore?

databaseは戻らない前提。

Supabase?

必要な時だけ選ぶ。

GitHub?

reviewと外部deployに使う。

Env?

secretと権限を見る。

迷ったら、codeとdataを別々に戻せるかで判断します。

BoltのVersion Historyでdatabaseも戻りますか？

Bolt docsでは、Version Historyでproject versionをrestoreしてもcurrent databaseは変わらないと説明されています。codeとdataは分けて戻し方を考えます。

Bolt DatabaseとSupabaseはどちらがよいですか？

新規prototypeならBolt Databaseが簡単です。既存Supabase projectがある、SQLやmonitoringを使いたい、teamでDBを管理したい場合はSupabaseを検討します。

Supabaseを接続すれば安全ですか？

接続だけでは安全になりません。RLS、policy、environment variables、client/server keyの分離、migration管理を確認します。

GitHub連携は必要ですか？

個人prototypeなら必須ではありません。team開発、本番前review、branching、CI、外部hostingを使うならGitHubへ出す方が扱いやすくなります。

Netlifyで公開すれば全部動きますか？

frontend hostingだけで足りるappなら候補になります。ただし、databaseやtraditional backendの扱いは別に確認します。Bolt docsでもNetlifyがdatabaseやtraditional backendをhostできない例が説明されています。

Viewersに共有したらappが動きません。

Bolt docsでは、Viewersはenvironment variablesを見られないため、env varsに依存するprojectの一部が動かない場合があると説明されています。共有目的に応じてEditor、Co-owner、公開URLを分けます。

参照した主な情報源

• https://support.bolt.new/building/using-bolt/rollback-backup
• https://support.bolt.new/concepts/version-history-github
• https://support.bolt.new/cloud/database
• https://support.bolt.new/integrations/supabase
• https://support.bolt.new/integrations/git
• https://support.bolt.new/building/deploy
• https://support.bolt.new/building/using-bolt/sharing
• https://supabase.com/docs/guides/deployment

次に読むなら

更新履歴

1. 2026年6月1日

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

導入時には利用中のBolt agent、database、hosting設定を確認してください。

• 2026年6月1日: Bolt公式support docsのVersion History、Database、Supabase、GitHub、hosting、sharingとSupabase公式docsを確認し、初版を作成しました。