如何匯出並自行託管 AI 建置的 App

要自行託管 AI 建置的 App，請先把程式碼取出來（下載，或同步到你擁有的 GitHub 儲存庫），把機密資料重新設定為環境變數，搬移或重建資料庫，然後部署到符合 App 類型的託管服務：純前端就用靜態託管，任何有後端的東西則用能執行伺服器或容器的平台。程式碼通常是最簡單的部分。真正費工的是資料、機密資料，以及建置工具在背後默默替你執行的服務。

為什麼要匯出

把程式碼帶走有很好的理由，也有一些不太好的理由。

好的理由：

• 所有權與保險。 在你自己的儲存庫中保存一份程式碼，能在建置工具變更價格、功能或條款時保護你。
• 交給開發人員。 工程團隊會希望程式碼放在 Git 中，配合他們慣用的工具與審查流程。
• 特定需求。 資料落地地點、特定的雲端供應商、公司的資安政策，或建置工具未提供的基礎設施。
• 規模或成本。 當規模大到自行營運基礎設施確實划算時。

**不太好的理由：**為了每個月省下一點錢，就搬移只有少數使用者的小型 App。自行託管會把工作轉到你身上：更新、備份、監控、安全修補。這可能是正確的取捨，只是要清楚知道自己在做什麼。

一個明智的折衷方案：繼續在目前的地方建置和託管，但**從一開始就同步到你自己的 GitHub 儲存庫。**你能獲得保險，又不必承擔營運工作。如果你還不熟悉 Git，請先閱讀什麼是 GitHub。

匯出內容包含與不包含什麼

在依賴匯出內容之前，請先打開檢查。通常會是這樣：

機密資料是刻意排除的，因為你可能會用電子郵件寄送或提交到版本庫的封存檔，絕不應包含正式環境的金鑰。相依套件則會從鎖定檔重新建置，所以也不會包含在內。

步驟一：把程式碼取出來

兩種常見的方式：

• 下載封存檔。 快速，適合一次性的搬移或備份。
• 同步到 GitHub。 更適合需要持續進行的情況：保有完整歷史紀錄，能輕鬆複製到任何地方，而且大多數託管服務在每次推送時都會直接從 GitHub 儲存庫部署。

無論哪種方式，都要在電腦（或雲端開發環境）上複製或解壓縮，並尋找 README。如果沒有，離開前先請建置工具中的 AI 幫你寫一份：

撰寫一份 README，說明如何在此平台之外執行這個專案：技術棧、所需的執行環境版本、安裝與建置指令、啟動指令與連接埠、程式碼讀取的每個環境變數（只寫名稱與用途，不寫值），以及如何執行資料庫遷移。

這一則提示詞就能省下好幾個小時，因為它會把原本隱含在設定中的部分寫成文字。

步驟二：先在本機執行

在部署到任何地方之前，先確認 App 能夠獨立運作：

1. 安裝執行環境，即 README 中指定的 Node.js、Python、Java 或 .NET，並使用相符的版本。
2. 安裝相依套件（npm install、pnpm install、pip install -r requirements.txt，或對應的指令）。
3. 建立本機的 .env 檔案，填入環境變數，盡量使用測試金鑰。不要把它放進 Git。什麼是環境變數與機密資料說明了這個概念。
4. 連接資料庫，例如本機的 Postgres，或託管服務提供的免費開發用資料庫。
5. 執行遷移，接著啟動 App，並實際點擊過主要流程。

在這裡出現的任何問題，部署到託管服務後也會出現，而且在自己的電腦上除錯容易得多。常見的意外包括：寫死了建置工具預覽的網址、建置工具自動注入但你漏掉的環境變數，或是只存在於該平台上的服務（檔案儲存、圖片縮放）。

步驟三：搬移資料

如果 App 有真實使用者，資料比程式碼更重要。

• 匯出資料庫。 對 Postgres 來說，pg_dump 會產生一個檔案，可以用 pg_restore 或 psql 還原到新的資料庫。如果你沒有直接存取權，請建置工具的 AI 幫你執行，並說明產出的內容。
• 搬移上傳的檔案。 如果使用者上傳了圖片或文件，這些檔案通常儲存在與資料庫分開的物件儲存空間中。請把它們複製到新的儲存空間（例如 S3 相容的 bucket），如果儲存的網址包含舊的主機，也要一併更新。
• 規劃切換。 對於正在運作中的 App，簡單的做法是預留一段短暫的維護時間：停止寫入、做最後一次匯出、在新主機上還原、切換 DNS，然後重新開放。先把每個步驟寫下來。
• 在正式搬移前，先測試還原，把資料還原到一個暫存資料庫。

如果你對 Postgres 不熟悉，可以參考什麼是 Postgres了解基本概念。

步驟四：選擇託管地點

讓託管服務配合 App 的類型。以下名稱是截至 2026 年 9 月各類別中知名的供應商範例，並非排名；請到他們的網站確認最新功能與價格。

你還需要：

• 代管資料庫。 許多 App 託管服務都提供 Postgres，而 Neon 或 Supabase 等專門服務也會單獨提供。代管非常值得：備份與更新都由別人負責。
• 物件儲存，用於上傳的檔案（如果 App 有這項功能）。
• 郵件寄送、付款與 AI 供應商：這些通常只需要在新主機上設定相同的 API 金鑰。

客觀來說，這些取捨是這樣的：平台型託管（前四列）設定與維護較快，但你的掌控權較少，且成本可能隨流量上升。虛擬伺服器在穩定負載下通常較便宜，並完全由你掌控，但修補、TLS、備份、監控與復原都要你自己負責。如果團隊沒有人想接下這份工作，就選擇平台。若想了解託管的基本概念，請參考什麼是網頁託管。

步驟五：部署並切換

1. 把儲存庫連接到託管服務，或推送容器映像檔。
2. 在託管服務的控制台設定環境變數：README 中列出的每一個都要設定，並填入正式的值。
3. 設定建置與啟動指令以及連接埠。許多託管服務會透過 PORT 環境變數傳入連接埠；App 應該監聽該連接埠，並監聽所有介面（0.0.0.0），而不只是 localhost。
4. 對新資料庫執行遷移。
5. 在託管服務提供的暫時網址上測試，然後才去動 DNS。
6. 更新指向舊網址的外部服務：付款 webhook、登入用的 OAuth 重新導向網址、郵件中的連結、允許的來源。
7. 透過更新 DNS 記錄，將網域移到新主機。如何連接自訂網域說明了這些記錄。
8. 舊的部署先保持運作一段時間，確定沒問題後再下線。

步驟六是最常被忘記的：搬移後登入或付款悄悄失敗，通常都是因為回呼網址仍指向舊主機。

步驟六：接手營運工作

自行託管之後，建置工具原本處理的事情就都變成你的責任。至少包括：自動資料庫備份，並經過還原測試；錯誤追蹤；上線監控與告警；相依套件更新；以及記錄每個帳號的存取權限擁有者。如何把 AI 原型推向正式上線會更詳細地走過這份清單。

匯出檢查清單

• 程式碼位於你擁有的儲存庫中，並附有涵蓋執行、建置與環境變數的 README
• App 能從乾淨的複製環境在本機執行
• 資料庫已匯出並測試過還原；上傳的檔案已複製
• 已依 App 類型選定託管服務，並備妥代管資料庫與儲存空間
• 所有環境變數都已在新主機上設定正式的值
• Webhook、OAuth 重新導向與郵件連結都已更新
• DNS 已切換，舊的部署短暫保留後移除
• 備份、監控與存取權限清單已就位

從 Mythex 匯出

在 Mythex 上，你建置的程式碼歸你所有。Pro 方案可以在專案設定 → 匯出中，將專案下載為封存檔，或連接 GitHub，並與你自己的儲存庫進行推送與拉取；免費方案只能以唯讀方式檢視程式碼，無法匯出或同步。匯出內容不包含機密資料與 node_modules，因此你需要在新主機上重新設定機密資料。文件中有這些步驟的說明：匯出並在其他地方執行，以及GitHub、匯出與匯入。你也可以繼續使用 Mythex 託管，只把 GitHub 同步當作自己的備份與交接管道；如果真的要搬移，請在新主機上線後，再取消發佈 Mythex 上的 App。

常見問題