App Hosting vs. the original Hosting: Which one do I use?

If you’re building a full-stack web app with modern, server-rendered frameworks like Angular and Next, use Firebase App Hosting. If you’re building a static website, use the original Firebase Hosting.

In case you missed it at Google I/O, we announced the release of Firebase App Hosting, our next-generation serverless web hosting product for full-stack apps!

If you’re thinking, Doesn’t Firebase already have a web hosting product?, you’re not alone. And we’re here to clear things up.

Firebase’s original hosting product is for hosting static websites. Firebase App Hosting is for full-stack web apps built with modern frameworks like Angular and Next.js; it’s for web apps that require a backend.

So why did we build another hosting product? And when would you choose one over another? Well, let’s talk about what’s new and different with App Hosting, and why you might want to use it for your next web app.

The evolution of Firebase Hosting

When we built Firebase Hosting in 2014, single page apps were all the rage. Hosting was designed for easy, local deployment of static web apps, and it still does that very well.

What we didn’t see coming, is that server-side rendering would come back in style.

Over the past few years, we added features to make the original Hosting work better with full-stack apps that require a backend. In 2022, we launched a “web frameworks” experiment: a framework-aware CLI that stitches Firebase Hosting and Cloud Functions for Firebase together. In 2023, we continued to experiment with full-stack preview channels and rollbacks.

While this “web frameworks” experiment smooths over some of the problems faced by developers deploying full-stack apps to Firebase, it has its limitations. It’s a tooling-based approach constrained by ten-year-old abstractions and infrastructure.

It was time to take everything we’ve learned from the “web frameworks” experiment and partner with the rest of Google to re-envision what a white-glove web development experience could be for shipping modern, full-stack web apps.

Firebase Hosting evolution
Firebase Hosting evolution

What’s different with App Hosting?

App Hosting is not a drop-in replacement for the original Firebase Hosting. It fills a specific gap. It’s designed to support modern, server-rendered frameworks end-to-end and to follow the latest best practices for enterprise-ready applications.

App Hosting is a serverless, full-stack solution

Firebase App Hosting manages everything from the CDN to server-side rendering. When it’s time to deploy, App Hosting builds your app’s static assets in Cloud Build, deploys dynamic content to Cloud Run, and serves cached content on Cloud CDN. As full-stack Javascript frameworks like Next.js and Angular blur the lines between frontend and backend code, having a single solution for deploying static and dynamic content together is becoming increasingly important.

Not only does App Hosting create your backend, it manages your backend for you. App Hosting is an opinionated abstraction of Cloud Run, giving you smart defaults to optimize your app’s performance and cost. Your App Hosting-managed Cloud Run service automatically scales up with additional traffic and scales down to zero when idle to save you money. And because App Hosting is built on Cloud Run directly (rather than the Cloud Functions for Firebase abstraction of Cloud Run), we’ll be able to expose new Cloud Run features in App Hosting much faster.

App Hosting is framework-aware

All of the lessons we learned in the “web frameworks” experiment have gone into the development of Firebase App Hosting.

Firebase App Hosting has no-config-needed build and deploy support for Angular and Next.js, with more frameworks coming soon.

Firebase App Hosting uses build adapters to inspect your source code, interpret your framework configuration, and create build and deploy instructions for your app based on what’s detected in source. These build adapters are built on Google’s open-source collection of Cloud Native Buildpacks, which means all of Google (and you, if you’re interested in contributing) can collaborate to improve framework-specific optimizations across Firebase and Google Cloud.

App Hosting’s Angular support was built in close collaboration with the Angular team. They even released new versions of Angular specifically designed to support the App Hosting build process!

App Hosting is git-centric

We designed Firebase App Hosting to be deeply integrated with source control providers, so that rolling out to production is as safe and efficient as possible.

When you create an App Hosting backend in the Firebase console, you install the Firebase GitHub app on your source code repository. After that, deploying is as easy as “git push.” You don’t even have to install the Firebase CLI to use App Hosting!

When you push a change to your live branch, App Hosting builds the branch in a reproducible Cloud Build environment, ensuring your local machine’s quirks don’t ship to production.

In the App Hosting dashboard UI, you can track each version of your web app to the exact git commit it was built with, so that you know which changes were live at a certain time:

App Hosting dashboard UI
App Hosting dashboard UI

Built on modern architecture

Best practices in the industry have changed over the last ten years. We’ve designed App Hosting with new best practices in mind, ensuring it has better fault tolerance, supports more regions, and is 100% built on Google.

The original Firebase Hosting is a single shard: one service handles your uploads and one CDN fronts your traffic. A single failure could hypothetically cause a global outage across all customers.

Firebase App Hosting is a regional service. Your traffic is still served across the globe, but the entire infrastructure of App Hosting is isolated based on your backend’s region. This means a catastrophic failure in us-central1 wouldn’t affect customers in europe-west1.

Why you might still want to use the original Hosting

Firebase App Hosting is not a drop-in replacement for the original Hosting product; it’s optimized for server-rendered web apps that require a backend. It’s also in preview, while the original Hosting is a mature product. Expect App Hosting to add more features over time, but for now, here are some use cases to keep in mind.

Static apps

While we’re working on improving the way App Hosting handles static files, we recommend using the original Hosting for purely static web apps, as it will be more performant and cost effective in these scenarios.

Preview channels

If you’d like to deploy previews of your site to temporary URLs on each pull request, then stick with the original Firebase Hosting for now, until App Hosting supports previews.

More web frameworks

The original Firebase Hosting’s framework-aware experiment has support for frameworks like Flutter, Svelte, and Astro that App Hosting doesn’t support yet.

Spark plan

While both App Hosting and the original Firebase Hosting have no-cost usage tiers, the original Firebase Hosting can be used on the Spark pricing plan, while App Hosting requires the Blaze plan. Learn more on the Firebase pricing page.

Still not sure?

Take a look at App Hosting’s product comparison guide to see how it compares to a number of Firebase and Cloud products, including the original Firebase Hosting, Cloud Functions for Firebase, Google Cloud Functions, and Cloud Run.

Interested in getting started with App Hosting?

There’s a lot we think you’ll be able to do with Firebase App Hosting and we’re excited to see what kinds of apps you’re able to build with it!

To get started, head over to the Firebase console and check out our documentation.

As always, if you have questions, you can hit us up on any of our support channels, or post questions on Stack Overflow. Good luck, and have fun!