瞭解 App Hosting 及其運作方式
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
App Hosting 會處理一系列複雜的背景工作，簡化應用程式的部署作業。本頁面說明工作流程的重要部分，並提供相關資訊，讓您視應用程式需求自訂流程。
重要字詞和定義
如要瞭解 App Hosting 流程的詳細資料，建議您先明確定義一些術語。以下是基本重要字詞：
- 後端：App Hosting 建立的一系列受管理資源，用於建構及執行網路應用程式。
- 建構：應用程式的特定修訂版本，通常會連結至 git 提交。建立建構作業的程序包含許多子程序，特別是建構 Cloud Build 中的應用程式，以及在 Cloud Run 中部署修訂版本 (最初會提供 0% 的流量，直到推出為止)。
- 推出：將建構版本設為有效，開始放送流量的程序。
當 App Hosting 因 Git 提交而自動觸發時，會先使用使用中的分支版本建立建構版本，然後建立推出作業，將使用中的流量導向該版本。
- 上線分支版本：GitHub 存放區的分支版本，會部署至上線網址。通常是合併功能分支或開發分支的分支。
Google Cloud 和App Hosting架構
App Hosting 會協調一組 Google Cloud 產品，方便您部署、提供及監控網路應用程式。應用程式是使用 Cloud Build 建構，在 Cloud Run 上提供，並快取在 Cloud CDN 中。Cloud Secret Manager 等整合式服務可確保 API 金鑰安全無虞。
- 將提交內容推送至即時分支時，Google Cloud Developer Connect 會將事件傳送至 Firebase App Hosting。
- 回應這項事件時，Firebase App Hosting 會為連結至存放區的後端建立新的建構作業。
- 首先，Firebase App Hosting 會為您的提交內容建立新的 Cloud Build 建構作業。在這項工作中，Google Cloud 建構套件會判斷應用程式使用的架構，然後建立適合應用程式的容器和設定 (包括環境變數、密碼、最低或最高執行個體數、並行記憶體、CPU 和 VPC 設定)。詳情請參閱App Hosting建構程序。
- Cloud Build 工作完成後，容器會儲存在專為 Firebase App Hosting 建立的 Artifact Registry 存放區中。Firebase App Hosting 接著會使用您的映像檔和設定，在 Cloud Run 服務中新增 Cloud Run 修訂版本。
- Cloud Run 修訂版本完成並通過健康狀態驗證後，Firebase App Hosting 會修改流量設定，將所有新要求導向新的 Cloud Run 修訂版本。此時，推出作業已完成。
- 當要求傳送至 Firebase App Hosting 上託管的網站時，Google Cloud 負載平衡器會提供要求，並啟用 Cloud CDN。未快取的要求會傳送至 Cloud Run 服務。如要瞭解如何透過 Cloud CDN 提升效能，請參閱「快取應用程式內容」。
架構整合
App Hosting 提供預先設定的建構和部署支援，適用於以這些架構開發的網頁應用程式：
- Next.js 13.5.x 以上版本
- Angular 18.2.x 以上版本
如要瞭解特定版本和支援級別的詳細資訊，請參閱支援時間表。
除了 Next.js 和 Angular 之外，App Hosting 也支援任何可提供符合輸出組合規格的建構輸出內容的網頁架構。如要進一步瞭解 App Hosting 支援的架構、架構轉接程式和相關工具，請參閱架構和工具App Hosting。
App Hosting 存放區整合的運作方式
GitHub 存放區與 App Hosting 後端之間的重要連結是由 Developer Connect 處理，這是 Google Cloud 適用於外部 DevOps 工具的連線平台。建立 App Hosting 後端時，Developer Connect 的 UI 工作流程會引導您安裝 Firebase GitHub 應用程式。這個程序的關鍵步驟如下：
- 授予 Developer Connect「Secret Manager 管理員」角色。這樣一來，系統就能在 Cloud Secret Manager 中，以「密鑰」的形式安全地儲存憑證。
- 授權 Firebase GitHub 應用程式存取 GitHub 存放區。您可能需要額外的 GitHub 權限，才能存取正確的存放區。
- Developer Connect 會在專案的 Secret Manager 存放區中儲存專屬的 GitHub 授權權杖，請勿修改或刪除這個權杖。
此外，App Hosting 會與 GitHub Checks API 整合，提供發布檢查。這項檢查可讓您在 GitHub 中查看推出狀態，並在發生錯誤時偵錯部署程序。
與 Firebase 和其他 Google 服務整合
App Hosting 會設定建構和執行階段環境，方便您使用 Google 應用程式預設憑證初始化 Firebase Admin SDK。這樣一來，後端就能在建構和執行階段與其他 Firebase 產品通訊。如要進一步瞭解如何初始化應用程式，以及其他 Firebase SDK 相關主題，請參閱「在網頁應用程式中整合 Firebase SDK」。
App Hosting 個位置
App Hosting 會在特定位置 (稱為主要區域) 建立後端資源。App Hosting 會整合全球 CDN，加快內容傳遞速度，但未快取的內容會從應用程式的主要區域提供。網頁應用程式位置的彈性有以下主要優點：
- 將資料地理位置移近使用者，提升效能並縮短延遲時間。
- 如果某個區域發生災難性故障，在其他區域部署的網頁應用程式不會受到影響。App Hosting
透過控制台或 Firebase CLI 建立 App Hosting 後端時，您可以選擇下列任一區域：
us-central1 (愛荷華州)asia-east1 (台灣)europe-west4 (荷蘭)
App Hosting 後端服務帳戶
在建構和執行階段，App Hosting 後端會使用服務帳戶向其他 Google 服務進行驗證。首次在 Firebase 專案中啟用 App Hosting 時，系統會建立用於上述用途的預設服務帳戶：
firebase-app-hosting-compute@PROJECT ID.iam.gserviceaccount.com
這個服務帳戶預設適用於所有後端，且具備最少的權限，可供您建構、執行及監控應用程式。此外，這個帳戶也具備使用應用程式預設憑證驗證 Admin SDK 的權限，可執行從 Cloud Firestore 載入資料等作業。請參閱「Firebase App Hosting 角色」。
如果應用程式在建構期間或從執行中的後端與其他 Google 服務互動，您可以新增角色來自訂預設服務帳戶。舉例來說，如果您的應用程式需要 Vertex AI 的權限，您可能需要新增 roles/aiplatform.user 或某些相關角色。
除非另有註明，否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權，程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間：2025-08-08 (世界標準時間)。
[null,null,["上次更新時間：2025-08-08 (世界標準時間)。"],[],[],null,["\u003cbr /\u003e\n\nApp Hosting handles a complex series of background tasks to simplify the\ndeployment of your app. This page describes key parts of that task flow,\nproviding information about points where you might want to customize the flow\ndepending on your app's needs.\n\nKey terms and definitions\n\nTo understand the details of the App Hosting flow, it's helpful to define\nsome of the terminology very specifically. Here are the fundamental key terms:\n\n- **Backend** : The collection of managed resources that App Hosting creates to build and run your web app.\n- **Build:** A specific revision of your app, typically linked to a git commit. The [process of creating a build](/docs/app-hosting/build) has numerous subprocesses, notably the *building* of your app in Cloud Build, and the *deployment* of a revision (initially serving 0% of traffic until it is rolled out) in Cloud Run.\n- **Rollout** : The process of setting a build to actively serving traffic. When automatically triggered by a git commit, App Hosting first creates a build using your live branch, then creates a rollout to direct live traffic to it.\n- **Live branch**: The branch of your GitHub repository that gets deployed to your live URL. Often, it's the branch into which feature branches or development branches are merged.\n\nGoogle Cloud and App Hosting architecture\n\nApp Hosting orchestrates a set of Google Cloud products so you can\ndeploy, serve, and monitor your web app. Apps are built with Cloud Build,\nserved on Cloud Run, and cached in Cloud CDN. Integrated services like\nCloud Secret Manager keep your API keys safe.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n1. When a commit is pushed to your live branch, Google Cloud Developer Connect sends an event to Firebase App Hosting.\n2. Responding to this event, Firebase App Hosting creates a new build for the backend connected to the repository.\n 1. First, Firebase App Hosting creates a new Cloud Build build for your commit. In this job, [Google Cloud buildpacks](https://cloud.google.com/docs/buildpacks/overview) determine which framework is being used in your application to create a container and configuration (including environment variables, secrets, minimum or maximum instances, concurrency memory, CPU, and VPC configuration) that suits your application. See [the App Hosting build process](/docs/app-hosting/build) For more information.\n 2. When the Cloud Build job is complete, your container is stored in an Artifact Registry repository dedicated to Firebase App Hosting. Firebase App Hosting then adds a new Cloud Run Revision to a Cloud Run service using your image and configuration.\n3. Once your Cloud Run Revision is complete and verified healthy, Firebase App Hosting modifies its traffic configuration to point all new requests to your new Cloud Run Revision. At this point, the rollout is complete.\n4. When a request is sent to a website hosted on Firebase App Hosting, the request is served by Google Cloud Load Balancer with Cloud CDN enabled. Uncached requests are sent to your Cloud Run service. See [Cache app content](/docs/app-hosting/optimize-cache) for guidance on how to optimize performance with Cloud CDN.\n\nFramework integration\n\nApp Hosting provides preconfigured build and deploy support for web apps\ndeveloped in these frameworks:\n\n- Next.js 13.5.x and higher\n- Angular 18.2.x and higher\n\nSee the\n[support schedules](/docs/app-hosting/frameworks-tooling#next.js-support) for\ndetails on specific versions and levels of support.\n\nIn addition to Next.js and Angular, App Hosting also supports any web\nframework that is able to provide a build output that matches our [output bundle\nspecification](https://github.com/FirebaseExtended/firebase-framework-tools#app-hosting-output-bundle).\nSee [Frameworks and tooling for\nApp Hosting](/docs/app-hosting/frameworks-tooling) for more information\nabout frameworks, framework adapters, and related tooling supported by\nApp Hosting.\n\nHow App Hosting repository integration works\n\nThe important connection between your GitHub repository and the App Hosting\nbackend is handled by\n[Developer Connect](https://cloud.google.com/developer-connect/docs/overview),\nGoogle Cloud's connectivity platform\nfor external DevOps tools. During the creation of an App Hosting backend,\nDeveloper Connect's UI workflow guides you through the installation of the\nFirebase GitHub app. The key steps in this process are:\n\n1. You grant Developer Connect the [Secret Manager Admin](https://cloud.google.com/secret-manager/docs/access-control#secretmanager.admin) role. This allows the system to store credentials securely as \"secrets\" in [Cloud Secret Manager](https://cloud.google.com/secret-manager/docs).\n2. You authorize the Firebase GitHub app to [access your GitHub repository](https://docs.github.com/en/apps/using-github-apps/installing-a-github-app-from-a-third-party). You may need additional [GitHub permissions](https://docs.github.com/en/apps/using-github-apps/installing-a-github-app-from-github-marketplace-for-your-organizations#requirements-to-install-a-github-app-on-an-organization) in order to access the right repository.\n3. Developer Connect stores a dedicated GitHub authorization token in your project's secret manager repository; don't modify or delete this token.\n\nAdditionally, App Hosting integrates with the GitHub checks API to provide a\ncheck for rollouts. This check lets you view the status of your rollout in\nGitHub and debug the deployment process in case of any errors.\n\nIntegration with Firebase and other Google services\n\nApp Hosting sets up both your build and runtime environments so you can\n[initialize the Firebase Admin SDK](/docs/admin/setup#initialize-sdk) with\nGoogle Application Default Credentials. That way, your backend can communicate\nwith other Firebase products at both build and run time. See [Integrate\nFirebase SDKs in your web app](/docs/app-hosting/firebase-sdks) for more\ninformation on initializing your app and other Firebase SDK-related topics.\n\nApp Hosting locations\n\nApp Hosting creates your backend resources in a specific location, called\nyour primary region. While App Hosting integrates with a global CDN for fast\ndelivery, uncached content is served from your app's primary region. This\nflexibility in the location of your web app has key advantages:\n\n- Improved performance and reduced latency by bringing the data geographically closer to your users.\n- A catastrophic failure for App Hosting in one region wouldn't affect web apps deployed in other regions.\n\nYou can choose any of these regions when you create an\nApp Hosting backend from the console or the Firebase CLI:\n\n- `us-central1` (Iowa)\n- `asia-east1` (Taiwan)\n- `europe-west4` (Netherlands)\n\nThe App Hosting backend service account\n\nDuring build and at runtime, your App Hosting backend authenticates with\nother Google services with a service account. A default service account for\nthese purposes is created the first time you enable App Hosting in a\nFirebase project:\n\n`firebase-app-hosting-compute@`\u003cvar translate=\"no\"\u003ePROJECT ID\u003c/var\u003e`.iam.gserviceaccount.com`\n\nThis service account applies to all backends by default and has a minimal set of\npermissions to allow you to build, run, and monitor your app. It also has\npermission to\n[authenticate the Admin SDK with Application Default Credentials](/docs/admin/setup#initialize-sdk), for\nperforming operations like loading data from Cloud Firestore. See\n[Firebase App Hosting roles](/docs/projects/iam/roles-predefined-product#app-hosting).\n\nIf your app needs to interact with additional Google services either at build\ntime or from a running backend, you can customize the default service account by\nadding roles. For example, if your app requires permissions for Vertex AI, you\nmight need to add\n[`roles/aiplatform.user`](https://cloud.google.com/iam/docs/understanding-roles#aiplatform.user)\nor some related role."]]
