25 個 Lovable 從 Lovable Cloud 遷移到 Supabase + AWS - TAN-studio 香港網頁設計 - 香港HK WordPress, OpenCart, Shopify...

過去一個月，25 個 Lovable 成功從 Lovable Cloud 遷移到 Supabase + AWS 基礎設施。

這個階段似乎是許多 Builder 在產品逐漸成熟時都會遇到的轉折點，因此我想把這段時間累積的經驗整理出來，分享給有類似需求的你。

Lovable 的優勢與極限

Lovable 真的是目前從「想法」到「可運行的產品」最快速的工具之一。
它的開發體驗極度順暢，大幅降低了建構產品的摩擦，讓人能專注在核心價值上。
但當專案開始需要：

• 更嚴格的資料主權與安全性控制
• 獨立擴展的能力
• 完全擁有後端與資料的自主權

很多創作者就會希望把後端搬到自己完全掌控的 Supabase 專案與 AWS 環境。
Lovable 雖然允許你匯出完整程式碼，但要把後端穩定運行在 Lovable Cloud 之外，其實有不少非顯而易見的細節要處理。Discord 社群與各處討論裡，常看到大家卡在類似的地方，卻缺少一份完整、清晰的端到端指南。

典型的遷移流程（技術層面）

根據我多次實戰的經驗，完整遷移大致包含以下幾個主要步驟：

1. 重建 Supabase 專案結構
2. 在全新的 Supabase 專案中，手動（或半自動）重建：
3. 資料庫 schema、資料表
4. 外鍵關聯、索引
5. Row Level Security (RLS) 策略
6. 確保新舊後端行為 100% 一致

遷移 Edge Functions 與後端邏輯

把 Supabase Edge Functions 完整提取出來，重新部署到新專案，並處理相關的環境變數與權限設定，讓 API 路由與後端邏輯正常運作。
重新設定環境變數與 Auth 整合
更新：

• Supabase URL、anon key、service_role key
• JWT 相關設定
• 讓 Lovable 前端正確連接到新的後端

在 AWS 上部署配套基礎設施

視需求設定：

• 前端靜態託管（S3 + CloudFront）
• 自訂域名、SSL
• 權限與安全群組
• 監控、備份、CI/CD 等生產級配置

保留 Lovable 作為主要開發環境
這是最重要的一點：
遷移完成後，Lovable 仍然可以正常使用！
你可以繼續在 Lovable 裡用自然語言迭代 UI、功能、資料結構，而生產環境的後端已經完全跑在你自己的 Supabase + AWS 上。

遷移後獲得的價值

1. 資料與後端完全自主掌控，不再依賴第三方平台
2. 基礎設施選擇更彈性（可優化成本、效能、地域）
3. 安全性設定可做到更細緻（自訂 RLS、加密、金鑰管理等）
4. 未來擴展不受限，可獨立 scale 資料庫、運算資源

我的核心體悟

多次操作下來，我發現真正耗費心力的部分其實不在 Lovable 本身，而是：
「如何在 Lovable Cloud 之外，正確地運行與管理一個 Supabase 相容的生產級後端」
Lovable 的價值在於讓你極速驗證想法；而遷移的挑戰，主要來自於對 Supabase 生態（尤其是 auth、RLS、edge functions）的理解深度。

如果你現在的專案還在早期，建議先專注把產品做出來；但當你開始有真實用戶、商業考量或合規需求時，提早規劃這條「自主後端」的路徑會讓未來少走很多彎路。

希望這篇分享能幫到正在猶豫、或已經卡在遷移路上的你。

有類似經驗或遇到具體問題，也歡迎留言討論，一起讓更多 Lovable 專案順利「畢業」！ 🚀

文章來源： https://www.reddit.com/r/lovable/comments/1rd11ih/i_helped_25_projects_migrate_from_lovable_heres/