Welcome to the March update for Firebase App Hosting: our modern, serverless hosting product for full-stack web apps. We’re excited to share new features to make it easier to build, deploy, and manage web apps with Firebase App Hosting.

Recover from production incidents in seconds with instant rollbacks

Picture this: You’ve just deployed an update to your web app. Suddenly, reports flood in - a critical bug has slipped through the cracks, impacting your users. You need to revert the change quickly, and in a risk-free way.

We understand that production incidents happen, even with rigorous testing. That’s why we’ve introduced instant rollbacks: a feature designed to minimize downtime and restore your peace of mind by safely reverting changes in seconds.

What makes a rollback “instant”

Typically, when you create an App Hosting rollout (either by pushing/merging changes to GitHub or manually through the Firebase console) it’s a two step process: build and deploy. At build time, App Hosting runs your framework build command, generates static assets, and creates a container image. During the deploy step, we take that container image and make it live by directing traffic to it.

With the new instant rollbacks feature, you can restore a previous version of your app without rebuilding. Rather than creating a new build from an old commit, App Hosting simply takes the old container image and makes it live again. This is an important distinction because it means:

1. Faster recovery. We’re skipping the build process entirely, which significantly reduces rollout times and eliminates the chance of the build failing.
2. Consistent environment configurations. Your app’s environment configuration (env vars, secrets, runtime settings) are baked into the container image at build time. With the rollback feature, you have peace of mind that you’re rolling back your app and its configuration together, preventing breaking changes.

Restore a previous version of your app without rebuilding

To start a rollback, visit the App Hosting dashboard and find the build you want to roll back to. In the menu, select “Roll back to this build.”

Confirm the change

App Hosting will now route new visitors to your web app to the selected build, so you can get back to fixing that bug.

Easily deploy across environments with automatic initialization of the Firebase SDKs

If you’ve built web apps with Firebase, you’ve probably copied and pasted the Firebase config object more times than you can count. What if you didn’t have to? On the server, the Firebase Admin SDKs can be initialized without arguments, and if you host your Firebase code with App Hosting, now you can call initializeApp in the client JS SDK without any arguments, too! We call this automatic initialization.

import { initializeApp } from 'firebase/app';

// No config object needed
const app = initializeApp();

Besides just being convenient, automatic initialization makes it simpler to juggle multiple environments (development, staging, production) to ensure your backend services and deployments are correctly configured for each.

It’s important to make sure the staging version of your web app talks to your staging database, and your production app talks to the production one, to prevent corruption of real user data. Before automatic initialization, you would have had to carefully configure the JS SDK with the appropriate project config object for each environment.

Now, if you deploy to Firebase App Hosting, we take care of all of this for you. No need to hardcode or dynamically set the config through environment variables.

Here’s how it works.

Code once, deploy to any App Hosting backend

The App Hosting build environment has an environment variable called FIREBASE_WEBAPP_CONFIG set automatically. When npm install is run, the Firebase JS SDK automatically checks for the FIREBASE_WEBAPP_CONFIG environment variable in a postinstall hook and includes it in its source so that it knows what Firebase config object to use if you call it without arguments.

This automatic configuration enables you to seamlessly deploy the same codebase across many environments, without hardcoding your Firebase project config. Automatic environment configuration helps to:

• Eliminate the risk of using the wrong database in your testing/production environments
• Accelerate development velocity by reducing configuration overhead
• Create a shareable, universal codebase (since the source code doesn’t contain a specific Firebase project config)

Improved UX for debugging builds

To make it easier to debug build failures, we’re now surfacing error messages in the App Hosting dashboard, so that you don’t need to dig through build logs in Google Cloud. However, you can always follow the link to the Cloud Build logs if you do need to dig deeper.

Connect your app to a VPC network

We’re rolling out support for connecting your App Hosting backend to a VPC network!

Why does this matter? Your app may need to access backend services in your Cloud project that are not accessible on a public IP address. For example, your app might query non-Firebase databases like Cloud SQL or Spanner, cache with the Redis or Memcache APIs on Cloud Memorystore, or make calls against internal microservices deployed to Compute Engine or Kubernetes.

With this App Hosting release, your app will be able to access resources in a VPC network in two ways: direct VPC Egress and serverless connectors. You configure this in apphosting.yaml.

Importantly, instead of providing a fully qualified network or connector name, you can provide an ID for your VPC network. If you use an ID, we will use the connector with that ID in your region and project, allowing you to use one apphosting.yaml across staging and production projects to use different connectors/networks with the same ID.

To enable direct VPC access (recommended for most projects because it’s faster and cheaper), add your network information to your app’s runConfig in apphosting.yaml:

runConfig:
 vpcAccess:
   # Default value if omitted
   egress: PRIVATE_RANGES_ONLY
   networkInterfaces:
   # At least one of network and/or subnetwork must be specified
   - network: my-network-id
     subnetwork: my-subnetwork-id

Or, to use a serverless connector (recommended for larger-scale apps where the number of IP addresses is a concern), specify the connector instead:

runConfig:
 vpcAccess:
   egress: ALL_TRAFFIC
   connector: connector-id

Summary

We hope that these new features will enhance your experience with App Hosting and we’re excited to see what you build!

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.