Easier configuration for Firebase on the web

Mature applications separate configuration from code. Doing so lets you easily switch between staging and production, deploy an open-source code sample, or spin up a new QA environment (see also “store config in the environment” from the 12 Factor App pattern).

Historically, this has been difficult for Firebase projects on the web, because you needed to keep track of the configuration options for firebase.initializeApp(). You might have had to write code that looked like this:

switch (location.hostname) {
  case 'myapp.com': firebase.initializeApp(prodConfig); break;
  case 'myapp-staging.com': firebase.initializeApp(stagingConfig); break;
  default: firebase.initializeApp(devConfig); break;

Not the best experience, plus it exposes your various staging environments in public-facing code. Today we’re excited to announce some new features of Firebase Hosting and the Firebase CLI that makes configuring Firebase on your Web app and working with multiple environments much simpler.

On-Demand Firebase SDK Auto-configuration

We’ve introduced some new reserved URLs to Firebase Hosting that will let you load the Firebase SDK and automatically configure it for the current environment without having to write any custom code. All you have to do is include the right script tags:

<!doctype html>


    <!-- Import and initialize the Firebase SDK -->
    <script src="/__/firebase/3.7.4/firebase-app.js"></script>
    <script src="/__/firebase/3.7.4/firebase-auth.js"></script>
    <script src="/__/firebase/init.js"></script>
      // The Firebase SDK is ready to rock!
      firebase.auth().onAuthStateChange(function(user) { /* … */ });

This works on sites deployed to Firebase Hosting, and also works locally when using firebase serve! The new URLs available are:

  • /__/firebase/{VERSION}/firebase-{app,auth,database,messaging,storage}.js - modular SDK files (recommended)
  • /__/firebase/{VERSION}/firebase.js - the complete Firebase JS SDK
  • /__/firebase/init.js - script that auto-initializes the SDK when included. Must be loaded after any Firebase SDKs.
  • /__/firebase/init.json - JSON representation of the configuration for firebase.initializeApp(). You can use this to fetch config and initialize Firebase SDKs asynchronously.

When serving locally, init.js initializes the currently selected project for your project directory (see “Using Project Aliases” for more information). When deployed, it initializes for the deployed project. In addition, when deployed, the scripts are served over HTTP/2 and you can enjoy the benefits of loading the SDK from the same origin without having to manage your own dependencies.

Note: You will need at least version 3.6.0 of the Firebase CLI to use these features, and may need to reauthenticate. If you see a warning message when running firebase deploy, run firebase login --reauth to enable init.js.

Integrating into Existing Toolchains

What if you’re not on Firebase Hosting or already bundle or otherwise build your JavaScript? You may want to have other ways to get the configuration for a given project. We’ve added the new firebase setup:web command to version 3.6.0 of the Firebase CLI. This can serve as a handy reference for copy and paste. The command prints out config information, but can also be integrated with your existing Node.js build process by using the Firebase CLI as a module.

To do so, first install firebase-tools as a dependency:

$ npm install --save firebase-tools@^3.6 

Next, require it and call the command. For example:

const fbcli = require('firebase-tools');
const fs = require('fs');

// by default, uses the current project and logged in user
fbcli.setup.web().then(config => {

// alternatively, you can pass project or token information
  project: 'my-custom-project',
  token: process.env.FIREBASE_TOKEN

We think these updates will make it much simpler to build mature, multi-environment web applications on Firebase, and we’re excited to see the creative ways you use them. Let us know what you think!