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
--passwordparameters which allow you to override the authentication credentials stored in your
~/.firebasercfile. 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.
firebasefield in the
firebase.jsoncan be overridden with the
--firebasecommand line argument to the
firebase deploycommand. 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.