A simple stack for your Firebase Rules

A simple workflow to increase security, readability and maintenance of your Realtime Database Rules.

I first got introduced to Firebase at the bootcamp of Google’s Launchpad Acceleration Program, on Jan 2016. At the time, Firebase had just been acquired by Google, and on it's way to become the full suite of applications to ease the process of mobile/web development.

The core of Firebase is it's Realtime Database and Authentication system. The RTDB is a happy marriage between WebSockets and JSON. It's a wild idea that works very well: Your database is one huge JSON file, and the clients can setup listeners to any path in it. When a change is made to a path in your database, firebase notifies every client that is listening and you can update your view. Brilliant: no more page refreshes!

Realtime Database works how you would think it works

To make all of this secure, Firebase relies on a Rules system that specifies what can be written to a path, as well as who can read and write to it. After almost two years working with Firebase, it is clear to me that Firebase Rules is one of the points that has greater importance than the amount of attention it gets.

Working on the Console

The very first attempt at writing rules is probably done straight on the console. With this, there are a few problems that are going to become apparent as your app scales:

  • Your rules are not kept under version control, and yet they are one of the most important parts of your code.
  • The console tests are great to debug, but there's no easy way to run a set every time you change your rules.
  • People in charge of writing rules might not have access to the Firebase console.

Firebase CLI

Once you start using the Firebase CLI, you can create a database.rules.json file and keep it in under version control. This solves one major issue, but will cause other problems:

  • JSON are not meant to have line breaks. Depending on your business logic and how tight your rules are, you can easily expect lines with 1000 characters. Good luck figuring that out.
  • JSON are not meant to have comments. The Firebase CLI and console can work with them just fine, but if you need to do any sort of manipulation/merging, node.js will not let you import them.
  • You'll soon find out there are many duplicated logic (like checkin user roles).


Bolt is an oficial language that compiles to Firebase rules. It's been around for a while but works very well. Bolt files can be composed of functions, types and paths:

Snapshot for syntax highlight. You can get the code here.

Five stars for readability and comprehension. You can compile this with:

$ firebase-bolt rules.bolt --output rules.json

You will generate this set of rules:


The other library I think everyone that uses Firebase should use (or at least know about) is Targaryen. This library lets you write tests that you can enforce before each deploy, which is a great way to avoid disasters.

The easiest way to use it is to create a json file with three keys:

  • root: The simulated database you will use on your tests
  • users: The set of users you'll refer to on tests
  • test: The tests as an object, where the key is the path to test

Running this test with:

$ targaryen --verbose rules.json tests.json

You'll get a nice table with your tests, results, expected outcome and a nice description in case of any tests have failed.


If you want to dig a little deeper, there's a repo I have created with a slightly more detailed example, nodemon and package.json setup. Let me know of any problems you find on the comments.

If this article was useful to you don't forget to give it a few claps 👏🏻