Firebase App Hosting 是我不可或缺的 Firebase 服務之一。它讓 Angular 應用程式的部署變得非常快速且容易。在定義 App Hosting 時，我設定了後端 ID、區域、環境、發布流程（Rollout），並連結了 GitHub 存放庫。當提交（Commit）推送到遠端存放庫時，就會觸發部署並將最新變更推送到線上運作環境。

Firebase MCP 目前並未提供在 App Hosting 中建立後端的工具，因此我們需要手動建立。

有兩種方法可以完成這項操作：

1. 透過 Firebase UI
2. 透過 Firebase CLI

這篇部落格文章將示範這兩種方法，讓您可以自由選擇要使用哪一種。

透過 Firebase UI 在 App Hosting 中新增後端

1. 前往 Firebase 使用者介面 (UI) 並從專案下拉式選單中選取專案
2. 點擊左側選單中的 App Hosting，然後點擊 Get Started 按鈕
3. 隨即出現 Set up App Hosting 表單

• 選取 asia-east1 (Taiwan)
• 選擇 Connect GitHub
• 點擊 Connect to GitHub
• 安裝或重複使用現有的 GitHub 應用程式安裝
• 選取要匯入的存放庫
• 選擇線上分支 main 以及應用程式根目錄 '/'
• 建立後端 ID，並選取 Node 24。環境變數將在 apphosting.yaml 中進行設定
• 將 App Hosting 關聯至現有的 Web 應用程式
• 點擊 Finish and Deploy 按鈕

當部署完成時，線上站台便會啟動並開始運作。URL 為 線上測試站台網址。

提示 Antigravity CLI 透過 Firebase CLI 在 App Hosting 中新增後端

如果我們不想使用 Firebase UI，可以提示 Antigravity CLI 使用正確的後端 ID、區域和 Web 應用程式 ID 來建立後端。

提示詞 1 是列出預設 Firebase 專案的 Web 應用程式。

Please list the web app name of the default Firebase project

該專案有一個 Web 應用程式，我們將使用它。

下一個提示詞是指示 Gemini 分析如何使用 Firebase CLI 建立新的 Firebase App Hosting。

Let's discuss a plan to enable Firebase App Hosting via Firebase CLI for <project name>. Web app name is <app name> and app id is <app id>. Do not modify anything until I approve.

我略過了分析部分，直接閱讀計畫以評估所需的工作量。

該計畫看起來很棒，除了我必須提供後端 ID、正確的區域（台灣），並將後端指派給現有的應用程式。

我透過提供以下指示來調整計畫。

Choose the backend ID ng-test, and the region is Taiwan. Do not proceed until I approve

Gemini 呼叫了 Firebase CLI，以預期的後端 ID、區域和應用程式建立新的後端。

它還在根目錄層級建立了 ``apphosting.yaml和firebase.json`。

runConfig:
  minInstances: 0
  maxInstances: 5
  concurrency: 80
  cpu: 1
  memoryMiB: 512

我明天會更新 apphosting.yaml，調低 maxInstances 和 concurrency 的值。

{
  "apphosting": [
    {
      "backendId": "ng-test",
      "rootDir": "./",
      "ignore": [
        "node_modules",
        ".git",
        "firebase-debug.log",
        "firebase-debug.*.log"
      ]
    }
  ]
}

我希望將設定檔和指令碼整理到 firebase/ 資料夾中，因此我將 firebase.json 移至該子資料夾以覆寫空白檔案。

然而，後端並沒有連結到我的 GitHub 存放庫。Gemini 表示這個流程無法自動化，我必須手動執行這項一次性操作。因此，我前往 Settings -> Environment 將 GitHub 存放庫連接至後端。

接著，我點擊「Automatic base image updates」，從基底映像檔下拉式選單中選擇 Node 24。

Firebase 本地部署的問題

Firebase 本地部署建置應用程式失敗，因為我將 firebase.json 保留在子資料夾中。最簡單的解決方案是將檔案移回根目錄。然而，我堅持將 firebase.json 保留在目前的位置。在 Antigravity CLI 中與 Gemini 討論後，解決方案是暫時將 firebase/firebase.json 複製到 .，並在部署後將其刪除。

"scripts": {
  "firebase:deploy": "cp firebase/firebase.json .; firebase deploy --only apphosting; rm firebase.json"
}

npm run firebase:deploy

指令碼將原始碼壓縮並將 zip 檔案上傳至後端。接著，我點擊 URL 驗證變更。

當我想將尚未提交的變更部署到 App Hosting 查看成果時，firebase deploy 非常好用。如果結果不理想，我可以復原到上一個已知的良好 Git 提交。

驗證自動部署

我修改了 app.html，提交了更改並將其推送到 GitHub 倉庫。系統自動進行了部署，幾分鐘後便能看到變更生效。

編輯 reCAPTCHA Enterprise 金鑰的網域

我們已經有了線上站台，因此可以將網域新增至 reCAPTCHA Enterprise 金鑰。

前往 Google Cloud Console，點擊 Fraud Defense，然後從專案下拉式選單中選取 Firebase 專案。

開啟 reCAPTCHA Enterprise 金鑰卡片，然後點擊 Edit Key 按鈕。新增網域，刪除虛設的 example.come，並儲存變更。

如果請求帶有 reCAPTCHA Enterprise 金鑰，只有在來自 ng-test--fb-awesome-proj.asia-east1.hosted.app 時，該請求才會成功。否則，請求將被中止且 HTTP 回應將擲出錯誤。

我們為 Firebase App Hosting 建立了一個後端，並在 reCAPTCHA Enterprise 金鑰中新增了新網域。

當我們推送變更至 main 分支時，GitHub webhook 會通知 Firebase App Hosting 處理部署事宜。App Hosting 會提取程式碼、建置檔案，並將正式環境產出檔案（Production bundle）複製到 Firebase 基礎設施。接著，我們便可以在線上站台上驗證應用程式的運作行為。

今天就到這裡。明天我們將在 apphosting.yaml 中定義環境變數，並使用 Firebase CLI 在 pre-push hook 中更新 Secret 數值。

相關資源

Firebase App Hosting 官方文件