如何匯出並自行託管 AI 建構的應用程式

要自行託管 AI 建構的應用程式，請把代碼取出（下載，或同步至你擁有的 GitHub 儲存庫），把機密資料重新設定為環境變數，搬遷或重建資料庫，然後部署到與應用程式性質相符的託管服務：純前端用靜態託管，任何有後端的則用能運行伺服器或容器的平台。代碼通常是最容易的部分，真正吃力的是資料、機密資料，以及建構工具在背後默默替你運行的服務。

為什麼要匯出

把代碼帶走有好的理由，也有不太好的理由。

好的理由：

• 擁有權與保障。 你自己的儲存庫裡有一份代碼副本，萬一建構工具更改收費、功能或條款，你仍然受到保護。
• 交給開發人員。 工程團隊會想把代碼放在 Git 中，用他們慣用的工具和審查流程處理。
• 特定要求。 資料駐留地、特定的雲端供應商、公司的安全政策，或建構工具沒有提供的基礎設施。
• 規模或成本達到一定程度，運行自己的基礎設施確實划算。

**不太好的理由：**為了省下少量的每月費用，而搬遷一個只有少數用戶的小型應用程式。自行託管會把工作轉移到你身上：更新、備份、監察、安全修補。這可能是正確的取捨，只是要清楚知道自己在做這個決定。

一個穩妥的折衷做法：繼續在現有地方建構和託管，但從一開始就同步到你自己的 GitHub 儲存庫。這樣你就有了保障，而不必承擔營運工作。如果你對 Git 還不熟悉，請先閱讀什麼是 GitHub。

匯出包括什麼、不包括什麼

依賴匯出之前，先打開檢查。一般情況如下：

機密資料是刻意排除的：一個你可能會用電郵傳送或提交到 Git 的壓縮檔，絕不應含有有效的金鑰。依賴項之所以排除，是因為它們會根據鎖定檔案重新建構。

第一步：取出代碼

兩種常見的做法：

• 下載壓縮檔的專案。快捷，適合一次性的搬遷或備份。
• 同步到 GitHub。 更適合持續進行的工作：完整的歷史紀錄，方便複製到任何地方，而且大多數託管服務在每次推送時都會直接從 GitHub 儲存庫部署。

無論哪種方式，都要把它複製或解壓到一部電腦（或雲端開發環境），並查找 README。如果沒有，離開之前先在建構工具中請 AI 寫一份：

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

這個提示能省下數小時，因為它會把那些隱含在設定裡的部分寫成文字。

第二步：先在本機運行

在部署到任何地方之前，先證明應用程式可以獨立運行：

1. 安裝執行環境，即 README 所指定的 Node.js、Python、Java 或 .NET，並使用相符的版本。
2. 安裝依賴項（npm install、pnpm install、pip install -r requirements.txt，或同類指令）。
3. 建立本機的 .env 檔案，填入環境變數；如可能，使用測試金鑰。不要把它放進 Git。什麼是環境變數和機密資料解釋了這個概念。
4. 連接到資料庫，例如本機的 Postgres，或託管服務提供的免費開發資料庫。
5. 執行遷移，然後啟動應用程式，逐一測試主要流程。

在這裡出錯的東西，在託管服務上也一樣會出錯，而且在自己的機器上除錯容易得多。常見的意外包括：寫死了建構工具預覽的網址、建構工具自動注入的環境變數遺失、只存在於平台上的服務（檔案儲存、圖片調整大小）。

第三步：搬遷資料

如果應用程式有真實用戶，資料比代碼更重要。

• 匯出資料庫。 對於 Postgres，pg_dump 會產生一個檔案，可以用 pg_restore 或 psql 還原到新資料庫。如果你無法直接存取，請讓建構工具的 AI 執行它，並說明它產生了什麼。
• 搬遷上傳的檔案。 如果用戶上傳了圖片或文件，它們存放在與資料庫分開的物件儲存空間。把它們複製到新的儲存空間（例如相容 S3 的儲存桶），並更新儲存的網址（如果網址包含舊主機名稱）。
• 規劃切換步驟。 對於正在運行的應用程式，簡單的做法是安排一段短暫的維護時段：停止寫入，進行最後一次匯出，在新主機上還原，切換 DNS，然後重新開放。事先把每一步寫下來。
• 在正式搬遷前，先把還原測試到一個臨時資料庫。

如果你不熟悉 Postgres，什麼是 Postgres會講解基本概念。

第四步：選擇託管地點

讓託管服務與應用程式的性質相配。以下的名稱只是各類別中一些知名供應商的例子，截至 2026 年 9 月，並非排名；請到它們的網站查看最新功能和收費。

你還需要：

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

公平地說，兩者各有取捨。平台式主機（前四行）設定和維護都較快，但你的掌控權較少，費用可能會隨流量上升。虛擬伺服器在穩定負載下通常較便宜，並完全由你掌控，但修補、TLS、備份、監察和復原都要你自己負責。如果團隊中沒有人想承擔這份工作，就選平台。有關託管服務的基本概念，請參閱什麼是網頁託管。

第五步：部署與切換

1. 把儲存庫連接到主機，或推送容器映像。
2. 在主機的控制台設定環境變數，即 README 中的每一項，並填入正式值。
3. 設定建構和啟動指令以及連接埠。許多主機會透過 PORT 環境變數傳遞連接埠；應用程式應監聽該連接埠，並接受所有網絡介面（0.0.0.0），而不只是 localhost。
4. 對新資料庫執行遷移。
5. 在切換 DNS 之前，先在主機提供的臨時網址上測試。
6. 更新指向舊網址的外部服務：付款 webhook、登入用的 OAuth 重新導向網址、電郵連結、允許的來源。
7. 透過更新 DNS 記錄把網域移到新主機。如何連接自訂網域說明了這些記錄。
8. 短時間內保留舊部署，直至你確定無誤，然後才停用。

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

第六步：接管營運工作

自行託管之後，建構工具原本替你處理的工作就變成你的責任。至少要有：自動資料庫備份，並且測試過還原；錯誤追蹤；正常運行時間警報；依賴項更新；以及一份記錄誰能存取各個帳戶的清單。如何把 AI 原型推向正式營運會更詳細地講解這份清單。

匯出檢查清單

• 代碼在你擁有的儲存庫中，並附有涵蓋執行、建構和環境變數的 README
• 應用程式能從乾淨的複製品在本機運行
• 資料庫已匯出並測試過還原；上傳的檔案已複製
• 已按應用程式的性質選定主機，並配備託管資料庫和儲存空間
• 所有環境變數都已在新主機上設定正式值
• Webhook、OAuth 重新導向和電郵連結都已更新
• DNS 已切換，舊部署已短時間保留，之後移除
• 備份、監察和存取名單都已就緒

從 Mythex 匯出

在 Mythex，你擁有自己建構的代碼。Pro 方案的用戶可以在專案設定 → 匯出下載專案壓縮檔，或連接 GitHub，並與你自己的儲存庫推送和拉取；免費方案的用戶只能以唯讀方式查看代碼，無法匯出或同步。匯出內容不包括機密資料和 node_modules，因此你需要在新主機上重新設定機密資料。文件中有匯出並在別處運行和 GitHub、匯出與匯入的步驟說明。你也可以繼續在 Mythex 託管，並把 GitHub 同步純粹當作你自己的副本和交接途徑；如果你確實要搬遷，請在新主機上線後取消發佈 Mythex 上的應用程式。

常見問題