[[["わかりやすい","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-31 UTC。"],[],[],null,["\u003cbr /\u003e\n\nIt's common to have multiple environments deployed from the same codebase, each\nwith slightly different configuration. For example, you might want to assign\nless CPU and RAM to your staging environment, or you might want to make sure\nyour production environment keeps at least 1 instance active and ready to serve\nrequests. You might also want to specify different environment variables and\nsecrets depending on the environment and resources you want to use.\n\nThis guide describes how to deploy a production and staging environment, each to\na separate Firebase project. Following the same principles, you can deploy to\nother different kinds of environments. To learn more about environments, check\nout the [Overview of\nenvironments](/docs/projects/dev-workflows/overview-environments) and [General\nbest practices for setting up Firebase\nprojects](/docs/projects/dev-workflows/general-best-practices).\n\nPrerequisites\n\n- Your application code is already stored in GitHub.\n- You have already created a distinct project for each of your environments---for example `my-production-firebase-project` and `my-staging-firebase-project`. Make sure to to tag your production Firebase project with the [\"production\" environment\n type](/docs/projects/dev-workflows/overview-environments#prod-environment).\n- In each project, you've created an App Hosting backend, with the live branch set to the GitHub branch you want to deploy (such as `main`). See [Get started with App Hosting](/docs/app-hosting/get-started) for more information.\n\n| **Note:** While it is technically possible to deploy multiple environoments to multiple backends created in the same project, it isn't recommended. See [GCP\n| guidance](https://cloud.google.com/dataflow/docs/guides/develop-and-test-pipelines#deployment-environment) and [Firebase guidance](/docs/projects/dev-workflows/overview-environments) on setting up and deploying across multiple environments.\n\nStep 0: Create a default configuration in apphosting.yaml\n\nApp Hosting supports a configuration file called `apphosting.yaml` to manage\nruntime settings (CPU, concurrency, memory limits, etc.) and environment\nvariables for your app. It also supports references to secrets managed with\nCloud Secret Manager, making it safe to check into source control. For more\ninformation, see [Configure a\nbackend](/docs/app-hosting/configure#configure-backend).\n\nTo get started, create an `apphosting.yaml` file in your app's root directory.\nThis is the fallback configuration file that is used when an\nenvironment-specific configuration file isn't found. The values stored in\n`apphosting.yaml` should be defaults that are safe to use for all environments.\n\nThe next sections explain how to override default values in `apphosting.yaml`\nfor specific environments. This example flow creates a staging environment.\n\nStep 1: Set Environment name\n\nEach App Hosting backend has an **Environment name** setting. This field is\nused to map your backend to an environment-specific configuration file, and can\nbe changed at any time. You can only set one environment name per backend.\n\nTo set your backend's environment name,\n\n1. In the Firebase console, select your staging project (in this example, my-staging-firebase-project).\n2. Select App Hosting from the left nav.\n3. Click **View dashboard** on your chosen backend.\n4. In the **Settings** tab, select **Environment**.\n5. Under **Environment name,** enter the name of your environment. You can name the environment whatever you like. In this example, it's **staging**.\n6. Click **Save**.\n\nWhen an App Hosting rollout is triggered for your backend (either on git\npush or manually through the console), App Hosting will check for an\n`apphosting.`\u003cvar translate=\"no\"\u003eENVIRONMENT_NAME\u003c/var\u003e`.yaml` file before\nfalling back to `apphosting.yaml`.\n\nStep 2: Create your environment-specific `apphosting.yaml` file\n\nFor your environment-specific configuration, create a file with the name\n`apphosting.`\u003cvar translate=\"no\"\u003eENVIRONMENT_NAME\u003c/var\u003e`.yaml` in order to\nspecify environment-specific overrides. This file has the same format as the\ndefault [apphosting.yaml](/docs/app-hosting/configure) and must be located in\nyour app's root directory alongside `apphosting.yaml`.\n\nAt build time, App Hosting merges these two files, with priority given to\nvalues in the environment-specific YAML file over the base `apphosting.yaml`\nfile.\n\nIn this example, you'll create a file named `apphosting.staging.yaml` in the\napp's root directory: \n\n\n runConfig:\n cpu: 1\n memoryMiB: 512\n concurrency: 5\n\n env:\n - variable: API_URL\n value: api.staging.service.com\n availability:\n - BUILD\n\n - variable: DATABASE_URL\n secret: secretStagingDatabaseURL\n\nSuppose you already had an `apphosting.yaml` that looked like: \n\n runConfig:\n cpu: 3\n memoryMiB: 1024\n maxInstances: 4\n minInstances: 0\n concurrency: 100\n\n env:\n - variable: API_URL\n value: api.service.com\n availability:\n - BUILD\n - RUNTIME\n\n - variable: STORAGE_BUCKET\n value: mybucket.firebasestorage.app\n availability:\n - RUNTIME\n\n - variable: API_KEY\n secret: secretIDforAPI\n\nThe final merged output, which you can inspect in your Cloud Build logs, would\nlook like this: \n\n runConfig:\n cpu: 1\n memoryMiB: 512\n maxInstances: 4\n minInstances: 0\n concurrency: 5\n\n env:\n - variable: API_URL\n value: api.staging.service.com\n availability:\n - BUILD\n\n - variable: STORAGE_BUCKET\n value: mybucket.firebasestorage.app\n availability:\n - RUNTIME\n\n - variable: API_KEY\n secret: secretIDforAPI\n\n - variable: DATABASE_URL\n secret: secretStagingDatabaseURL\n\nNote that certain `runConfig` values such as CPU have been overwritten as well\nas any overlapping environment variables.\n| **Note:** You'll still need to grant the proper service accounts access to any secrets that you create, the same as you would for `apphosting.yaml` secrets. See [store and access secret\n| parameters](/docs/app-hosting/configure#secret-parameters) for more information._\n\nStep 3: Deploy your codebase\n\nOnce you are finished editing your environment specific `apphosting.`\u003cvar translate=\"no\"\u003eENVIRONMENT_NAME\u003c/var\u003e`.yaml` file, push your file to GitHub: \n\n $ git add apphosting.\u003cENVIRONMENT_NAME\u003e.yaml\n $ git commit -m \"Added environment specific yaml file\"\n $ git push\n\nAny backends tagged with this environment name will use the specific override\nvalues you have specified in its corresponding YAML file, and fall back to\n`apphosting.yaml` when a value isn't found. For backends without an associated\nenvironment name, you can continue to use apphosting.yaml.\n\nNext steps\n\n- Go deeper: walk through a Firebase codelab that integrates a hosted app with Firebase Authentication and Google AI features: [Next.js](https://firebase.google.com/codelabs/firebase-nextjs) \\| [Angular](https://firebase.google.com/codelabs/firebase-web)\n- [Connect a custom domain](/docs/app-hosting/custom-domain).\n- [Configure your backend](/docs/app-hosting/configure).\n- [Monitor rollouts, site usage, and logs](/docs/app-hosting/rollouts)."]]
