ビルド時または実行中のバックエンドからアプリが追加の Google サービスとやり取りする必要がある場合は、ロールを追加してデフォルトのサービス アカウントをカスタマイズできます。たとえば、アプリで Vertex AI の権限が必要な場合は、roles/aiplatform.user または関連するロールを追加する必要があります。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["必要な情報がない","missingTheInformationINeed","thumb-down"],["複雑すぎる / 手順が多すぎる","tooComplicatedTooManySteps","thumb-down"],["最新ではない","outOfDate","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["サンプル / コードに問題がある","samplesCodeIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-08-08 UTC。"],[],[],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."]]
