Multi-tenancy patterns in Firebase - Commands & Configuration

Introduction

Multi-tenancy means sharing one app or database for many users or groups, called tenants. It helps save money and makes managing many users easier by keeping their data separate but using the same system.

When you build a SaaS app that serves many companies but wants to keep their data private.

When you want to save costs by using one Firebase project for multiple user groups.

When you want to manage user access and data isolation easily in one place.

When you want to scale your app without creating many separate Firebase projects.

When you want to customize features or data views for different user groups.

Config File - firestore.rules

firestore.rules

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Each tenant has its own collection
    match /tenants/{tenantId}/{document=**} {
      allow read, write: if request.auth != null && request.auth.token.tenantId == tenantId;
    }
  }
}

This Firestore security rule ensures data isolation by allowing users to access only their tenant's data. The tenantId in the path matches the tenant claim in the user's authentication token. This way, users from one tenant cannot read or write data from another tenant.

Commands

Deploys the Firestore security rules to enforce tenant data isolation.

Terminal

firebase deploy --only firestore:rules

Expected Output

=== Deploying to 'my-firebase-project'...



i  deploying firestore.rules

✔  firestore.rules: Rules deployed successfully



✔  Deploy complete!

→

--only firestore:rules - Deploy only Firestore security rules without affecting other services

Imports users with tenant information in their custom claims to Firebase Authentication.

Terminal

firebase auth:import users.json --hash-algo=SCRYPT --rounds=8 --mem-cost=14

Expected Output

✔ Imported 3 users successfully.

→

--hash-algo=SCRYPT - Specifies the password hashing algorithm used for imported users

Sets a configuration value for tenant ID to use in Firebase Functions for tenant-specific logic.

Terminal

firebase functions:config:set tenant.id="tenant123"

Expected Output

✔  Functions config updated.

Deploys Firebase Functions that can use tenant config and enforce tenant-specific behavior.

Terminal

firebase functions:deploy

Expected Output

=== Deploying to 'my-firebase-project'...



i  deploying functions

✔  functions: Finished running predeploy script.

✔  functions: functions deployed successfully



✔  Deploy complete!

Key Concept

If you remember nothing else from this pattern, remember: keep each tenant's data separate by using security rules that check tenant identity in user tokens.

Common Mistakes

Not setting tenant info in user authentication tokens.

Without tenant info, security rules cannot restrict data access properly, risking data leaks.

Always assign tenant IDs as custom claims in user tokens during authentication or user import.

Writing security rules that do not check tenant ID in the document path.

This allows users to access data from other tenants, breaking data isolation.

Structure your Firestore data with tenant IDs in the path and enforce tenant ID checks in rules.

Deploying functions or rules without testing tenant access.

Errors in rules or functions can cause unexpected access or failures.

Test tenant-specific access with different user accounts before deploying to production.

Summary

Use Firestore security rules to isolate tenant data by checking tenant IDs in user tokens.

Deploy rules and functions with tenant-aware logic to enforce data separation and custom behavior.

Import users with tenant info in authentication tokens to enable secure multi-tenancy.