Six months ago we released Firebase Hosting! We’ve been amazed by the apps you’ve deployed and we’re excited to see many more to come. Since the launch, our hosting service has had 99.99% uptime and we’ve seen nearly 6,000 websites deployed a total of 100,000 times. These sites have uploaded more than 700 GB of HTML, CSS, JavaScript, image data, and more to their websites, and many of them are using Firebase to host their own custom domains - including Pathwright and Thinkster.io. If you haven’t tried Firebase Hosting yet, you can dive right in by watching our screencast or checking out the five minute quickstart.

After getting feedback from developers using Firebase Hosting in development and production, I want to share some hints on using the hosting tools effectively.

Managing Development, Staging, and Production Environments

A common question we see is how to manage different environments with hosting. To start, I’d recommend creating a separate Firebase for each environment (i.e. my-app-dev, my-app-staging, my-app-prod). With our Hacker Plan you can create up to ten free Firebases, and creating multiple Firebases allows you to test things like rewrite rules and redirects before deploying to production. If you have a deploy script, you can easily switch out the name of your Firebase in your app to match your current environment. Only Firebases with a custom domain need to be on a paid plan for Firebase Hosting.

Firebase Tools For Use in Scripting and CI

The firebase-tools repo is constantly being improved and a lot of the features explained here have been added since v1.0.0. If you’re on an older version make sure you’ve updated to the latest by running:

npm update -g firebase-tools

You can just as easily run Firebase tools from a script as you would from the command line. Here are a few hints that might make things a little easier:

• Use the -s (“silent”) flag to prevent the tools from prompting for information it needs that wasn’t provided through command line arguments. Instead, it will display a message and exit with a non-zero error code.
• Every command also accepts the --email and --password parameters which allow you to override the authentication credentials stored in your ~/.firebaserc file. This is useful for circumventing the 30 day expiration on access tokens, but should be used with caution. It’s best practice to have a deploy user who is a collaborator on the Firebases for the different environments, so that only their password is distributed to any build machines. This will ensure that they have limited access to the Firebases (they can’t, for example, delete them), and that they can easily be removed as a collaborator should the credentials be compromised. It’s also useful to pass them through as environment variables so that they don’t show up in the command history.
• The firebase field in the firebase.json can be overridden with the --firebase command line argument to the firebase deploy command. This can be useful when integrating with a build tool to make separate tasks to deploy to staging and production.

We’d Like Your Feedback!

Many of you have requested support for uploading user-generated content like images and files in hosting, and improved SEO support in single page apps. Thank you for your feedback - these features are definitely on our roadmap.

We’re always looking for more ways to improve hosting and we’d love to hear what you think. Share your feedback or show us an app you’ve deployed with hosting in our Google Group or mention @Firebase on Twitter.