Firebase App Hosting is a secure, serverless web hosting product that manages everything from the build, to the CDN, and server-side rendering.

One of the most requested features since announcing the public preview of App Hosting at Google I/O was to make it easier to deploy the same codebase to many environments, using a different set of environment variables and runtime settings in each environment.

We’re happy to announce that Firebase App Hosting now supports environment-specific apphosting.yaml files! With this new feature, you can create configuration files such as apphosting.production.yaml and apphosting.staging.yaml, each with their own set of environment variables and runtime settings. And you can still use apphosting.yaml to store safe fallback values that are shared across environments.

App Hosting also has a new Deployment settings tab, where you can disable automatic rollouts and change your backend’s live branch and root directory.

Keep reading to learn more!

Environments

Each App Hosting backend now has an Environment name setting. You can name your environment whatever you’d like (e.g. production, prod, staging).

Then, when an App Hosting rollout is triggered for your backend (either on git push or manually through the console), App Hosting will check for an apphosting.ENVIRONMENT_NAME.yaml file before falling back to apphosting.yaml.

Why does this matter?

Production data is sensitive, and using it to test new features in a staging environment puts it at risk of being corrupted or exposed. You also might want to use different different runtime settings in production, where performance matters more. For example, it’s common to set minInstances to 1 in production to reduce cold starts, and set it to 0 in staging to keep costs low.

Check out our documentation to learn more about how the environment-specific overrides work.

Disable automatic rollouts

While CI/CD is considered a best practice, there are reasons you might want to disable it. If a feature is still under development and not ready for deployment, disabling automatic rollouts will prevent it from being accidentally deployed.

With the new Deployment settings tab in the Firebase console, you can now disable (and enable) automatic rollouts for your App Hosting backend.

When automatic rollouts are enabled, App Hosting automatically builds and deploys the live branch when changes are pushed/merged on GitHub. When automatic rollouts are disabled, you can still create a rollout manually from the App Hosting dashboard.

Update live branch and root directory

You can also edit your backend’s live branch and root directory in the new Deployment settings tab.

The live branch is the GitHub branch that App Hosting uses for rollouts. When you manually create a rollout from the dashboard, you can choose to roll out a different branch, but the live branch is used by default.

The root directory is where App Hosting runs your build command. This is usually where your package.json file is located.

Steady improvements

We’re always looking for ways to improve App Hosting based on your feedback. Here are some of the other enhancements and bug fixes we’ve rolled out:

• New: Published reference docs for the Firebase App Hosting REST API
• Fix: Addressed bug that was preventing the default domain from being provisioned for new backends
• Fix: Addressed bug where framework build output logs were not visible in Cloud Build logs
• Fix: Addressed bug that was preventing projects using yarn from being built properly
• Fix: The request timeout limit is now 5m instead of 1m

What’s next?

We’ve heard from many of you that getting Authentication working on App Hosting is difficult, given the current lack of support for Cookies. We’re working to address these limitations and have a more seamless experience with our SDKs in the future. In the meantime, we’re shipping updates to our Google Codelab and session management with Service Workers guide to ensure the workarounds are more approachable.

That’s all for this update! We hope these new features and bug fixes will help you go even further with Firebase App Hosting.

We’re looking forward to seeing the apps you build with Firebase App Hosting. If you haven’t already, head over to the Firebase console and explore our documentation to deploy your first app.

As always, if you have questions, you can hit us up on any of our support channels, or post questions on Stack Overflow. And if you have ideas for any new features, let us know on User Voice!