Understand App Hosting and how it works

App Hosting handles a complex series of background tasks to simplify the deployment of your app. This page describes key parts of that task flow, providing information about points where you might want to customize the flow depending on your app's needs.

Framework support

App Hosting provides no-config-needed build and deploy support for Web apps developed in these frameworks:

  • Next.js 13+
  • Angular 17.2+

App Hosting identifies which framework you're using by inspecting the package-lock.json file or other lock file in your repository. If you try to deploy a Node.js app that is missing a lock file, App Hosting will fail to build and run your app. You can create package-lock.json by running npm install in your root directory.

App Hosting framework adapters have two key roles:

  1. They parse your source code and any framework-specific config files (such as next.config.js) in order to understand your app's configured behavior.
  2. They run your app's build command to generate static assets and create an optimized version of your app for production.

The framework adapters build your Node.js app with npm run build, working best with the default build scripts for each framework: next build for Next.js and ng build for Angular. App Hosting will attempt builds with custom build commands, but cannot dependably guarantee success.

How App Hosting repository integration works

The important connection between your GitHub repository and the App Hosting backend is handled by Developer Connect, Google Cloud's connectivity platform for external DevOps tools. During the creation of an App Hosting backend, Developer Connect's UI workflow guides you through the installation of the Firebase GitHub app. The key steps in this process are:

  1. You grant Developer Connect the Secret Manager Admin role. This allows the system to store credentials securely as "secrets" in Cloud Secret Manager.
  2. You authorize the Firebase GitHub app to access your GitHub repository.
  3. Developer Connect stores a dedicated GitHub authorization token in your project's secret manager repository; don't modify or delete this token.

Additionally, App Hosting integrates with the GitHub checks API to provide a check for rollouts. This check lets you view the status of your rollout in GitHub and debug the deployment process in case of any errors.

Integration with Firebase and other Google services

App Hosting sets up both your build and runtime environments so you can initialize the Firebase Admin SDK with Google Application Default Credentials. That way, your backend can communicate with other Firebase products during both build and deploy.

The App Hosting backend service account

During build and at runtime, your App Hosting backend authenticates with other Google services with a service account. A default service account for these purposes is created the first time you enable App Hosting in a Firebase project:

firebase-app-hosting-compute@PROJECT ID.iam.gserviceaccount.com

This service account applies to all backends by default and has a minimal set of permissions to allow you to build, run, and monitor your app. It also has permission to authenticate the Admin SDK with Application Default Credentials, for performing operations like loading data from Cloud Firestore. See Firebase App Hosting roles.

If your app needs to interact with additional Google services either at build time or from a running backend, you can customize the default service account by adding roles. For example, if your app requires permissions for Vertex AI, you might need to add roles/aiplatform.user or some related role.

Key terms and definitions

  • Backend: The collection of managed resources that App Hosting creates to build and run your web app.
  • Rollout: A specific version of your live app, linked to a git commit.
  • 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.

Known issues and limitations

The App Hosting preview has some known limitations:

  • Projects with nested package.json files are currently not supported, regardless of whether root\_directory is configured with the Firebase console or the CLI. A fix will be available in a later release.
  • Image optimization is not yet available.
  • In some cases, an App Hosting backend may return Intermittent connection error messages at your app's URL. A fix will be available in a later release.
  • Cache-Control headers are modified to limit CDN caches to 60s; in the future, when App Hosting has the ability to quickly purge the cache on deploy, this limit will be lifted.
  • Set-Cookie headers are stripped from responses served through the App Hosting dataplane. A fix will be available in a later release.
  • Uncached static files are served out of Cloud Run; in a later release, they'll be stored and served from the App Hosting origin for better performance.
  • Wildcard subdomains as custom domains will be available in a later release.
  • App Hosting SKUs may not be displayed in the backend usage page in the Firebase console. They will be available in a later release.
  • The Firebase console may intermittently show a "build was not found and is invalid" error on backend creation.
  • Currently, all backends in the same project share a GitHub org/account. They can be connected to different repositories under that org/account. To create backends that are connected to different GitHub accounts, put them in separate projects.
  • At this time, only the us-central1 region is supported.