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.

Note: App Hosting is a preview release. This means that App Hosting is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of the Service Specific Terms. Pre-GA features are available "as is" and might have limited support. For more information, see the launch stage descriptions.

Framework integration

App Hosting provides preconfigured 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.

Framework adapters

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) and generate an output bundle that can be processed by the rest of the App Hosting infrastructure.
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.

The source for Next.js and Angular adapters is available in firebase-framework-tools.

Other frameworks

In addition to Nextjs and Angular, App Hosting also supports any web framework that is able to provide a build output that matches our output bundle specification. Framework authors can take advantage of the output bundle specification to ensure their framework is supported by App Hosting.

Note: Express apps with a "start" and "build" script configured generally work in App Hosting, but support is not guaranteed. If there exists a more specific adapter available, we recommend setting your project up with that adapter.

If you want additional frameworks supported, you can create an adapter, or reach out to the framework's maintainers to convert build outputs into the App Hosting format. The Nextjs and Angular adapters are good reference examples for anyone creating an adapter.

Supported frameworks can be found on Firebase Open Source.

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.

App Hosting locations

App Hosting deployment creates your backend resources in a specific location. This flexibility in the location of your web app has key advantages:

• Improved performance and reduced latency by bringing the data geographically closer to your users.
• A catastrophic failure for App Hosting in one region wouldn't affect web apps deployed in other regions.

You can choose any of these regions when you create an App Hosting backend from the console or the Firebase CLI:

• us-central1 (Iowa)
• asia-east1 (Taiwan)
• europe-west4 (Netherlands)

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:

• 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.
• Image optimization is done in Cloud Run by default, and optimized images are not persisted—we recommend disabling image optimization or manually specifying a loader until a better solution is available.
• 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.
• 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.
• Next.js middleware, rewrites, and redirects are executed in Cloud Run, behind the CDN. As these won't protect cached responses, be sure to set appropriate control directives for the content you're rendering.