DEV Community: hello world_leo

Building a Multi-Tenant Firebase Application: Environment Setup and Role-Based Access Control

hello world_leo — Sat, 14 Feb 2026 14:27:01 +0000

Recently, I worked on deploying a multi-tenant Progressive Web App (PWA) using Firebase as the backend platform. The application needed to support multiple organizations with different user roles, work offline, and maintain separate development, staging, and production environments.

Here's what I learned about Firebase infrastructure setup, custom claims for role-based access control, and multi-environment deployment strategies.

The Requirements

The application needed:

Multi-tenant architecture - Multiple organizations using one platform
Role-based access control - Different permission levels per organization
Multi-environment deployment - Separate dev, staging, and production
Offline-first capability - Works without internet connection
Real-time updates - Data syncs instantly across devices
Automated backups - Production data protection

Tech Stack Overview

Frontend: React + TypeScript
Backend: Firebase (Authentication, Firestore, Cloud Storage, Hosting)
Build System: pnpm workspaces
CI/CD: GitHub Actions + Firebase CLI
Backup: Google Cloud Console

Multi-Environment Firebase Setup

I created three separate Firebase projects for proper environment isolation:

Environment	Purpose	Deployment
Development	Local testing with emulator	Manual
Staging	Pre-production testing	Automated via GitHub Actions
Production	Live users	Automated via GitHub Actions

Each project has completely isolated:

Firebase Authentication users
Firestore database
Cloud Storage bucket
Hosting deployment

Why separate projects instead of one project with different databases?

Firebase doesn't support multiple databases per project for the free tier, and separating projects provides:

Complete isolation (no risk of staging affecting production)
Independent security rules per environment
Separate usage quotas
Different service account permissions

Environment Configuration Pattern

Managing environment variables correctly was critical. Here's the structure:

app/
├── .env                    # Development (uses emulator)
├── .env.staging            # Staging deployment
├── .env.production         # Production deployment
└── src/
    └── config/
        └── firebase.ts     # Firebase initialization

Development (.env):

REACT_APP_FIREBASE_PROJECT_ID=my-app-dev
REACT_APP_USE_EMULATOR=true
REACT_APP_FIREBASE_API_KEY=your-dev-api-key
REACT_APP_FIREBASE_AUTH_DOMAIN=my-app-dev.firebaseapp.com

Production (.env.production):

REACT_APP_FIREBASE_PROJECT_ID=my-app-production
REACT_APP_USE_EMULATOR=false
REACT_APP_FIREBASE_API_KEY=your-prod-api-key
REACT_APP_FIREBASE_AUTH_DOMAIN=my-app-production.firebaseapp.com

Firebase Custom Claims for Multi-Tenant RBAC

The key challenge was implementing role-based access control (RBAC) that works across multiple organizations.

Why Custom Claims?

Instead of storing user roles in Firestore and checking them on every request, I used Firebase Custom Claims:

✅ Built into ID tokens - No extra database reads
✅ Enforced at security rules level - Server-side validation
✅ Multi-tenant support - One user, multiple organizations, different roles
✅ Works offline - Cached in the client

Custom Claims Structure

interface CustomClaims {
  isAdmin?: boolean;                       // Platform super-admin
  organizations?: Record<OrgId, Role>;     // Org-specific roles
}

// Example: User with different roles in two organizations
{
  "isAdmin": false,
  "organizations": {
    "org_abc123": "admin",
    "org_xyz789": "viewer"
  }
}

Setting Custom Claims (Firebase Admin SDK)

I created a helper script for managing custom claims:

// scripts/set-user-claims.js
const admin = require('firebase-admin');

admin.initializeApp({
  credential: admin.credential.cert('./service-account.json')
});

async function setUserClaims(email, organizations) {
  try {
    const user = await admin.auth().getUserByEmail(email);

    await admin.auth().setCustomUserClaims(user.uid, {
      isAdmin: false,
      organizations: organizations
    });

    console.log(`✅ Claims updated for ${email}`);
  } catch (error) {
    console.error('❌ Error:', error.message);
  }
}

// Usage
setUserClaims('user@example.com', {
  'org_abc123': 'admin'
});

Important: Custom claims have a 1,000 byte limit per user. For large-scale multi-tenant systems, consider storing detailed permissions in Firestore and using claims only for organization IDs.

Firestore Security Rules with Custom Claims

Security rules enforce multi-tenant isolation using custom claims:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {

    // Helper function to check organization access
    function hasOrgAccess(orgId, allowedRoles) {
      return request.auth != null && 
             request.auth.token.organizations[orgId] in allowedRoles;
    }

    // Organization data - only accessible by members
    match /organizations/{orgId} {
      allow read: if hasOrgAccess(orgId, ['admin', 'editor', 'viewer']);
      allow write: if hasOrgAccess(orgId, ['admin']);
    }

    // Organization documents - different access levels
    match /organizations/{orgId}/documents/{docId} {
      allow read: if hasOrgAccess(orgId, ['admin', 'editor', 'viewer']);
      allow create, update: if hasOrgAccess(orgId, ['admin', 'editor']);
      allow delete: if hasOrgAccess(orgId, ['admin']);
    }
  }
}

Testing security rules: Always use Firebase Console → Firestore → Rules → Rules Playground before deploying to production.

GitHub Actions Deployment Pipeline

Automated deployment to staging when pushing to the staging branch:

# .github/workflows/deploy-staging.yml
name: Deploy to Staging

on:
  push:
    branches: [ staging ]

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      - name: Install pnpm
        run: npm install -g pnpm

      - name: Install dependencies
        run: pnpm install

      - name: Build for staging
        run: |
          cp .env.staging .env
          pnpm build

      - name: Deploy to Firebase Hosting
        uses: FirebaseExtended/action-hosting-deploy@v0
        with:
          repoToken: '${{ secrets.GITHUB_TOKEN }}'
          firebaseServiceAccount: '${{ secrets.FIREBASE_SERVICE_ACCOUNT_STAGING }}'
          projectId: my-app-staging
          channelId: live

Pro tip: Store Firebase service account JSON as GitHub secrets, not in your repository.

Production Backup Strategy

I implemented three backup layers for production Firestore:

1. Daily Automated Backups (7-day retention)

gcloud firestore backups schedules create \
  --database='(default)' \
  --recurrence=daily \
  --retention=7d

2. Weekly Automated Backups (8-week retention)

gcloud firestore backups schedules create \
  --database='(default)' \
  --recurrence=weekly \
  --retention=8w \
  --day-of-week=SUN

3. Monthly Exports to Cloud Storage (365-day retention)

# Create storage bucket
gsutil mb -l us-central1 gs://my-app-backups

# Create Cloud Scheduler job for monthly exports
gcloud scheduler jobs create http firestore-monthly-export \
  --location=us-central1 \
  --schedule="0 2 1 * *" \
  --uri="https://firestore.googleapis.com/v1/projects/my-app-production/databases/(default):exportDocuments" \
  --http-method=POST \
  --oauth-service-account-email=backup-sa@my-app-production.iam.gserviceaccount.com \
  --headers="Content-Type=application/json" \
  --message-body='{"outputUriPrefix":"gs://my-app-backups/monthly"}'

Cost: Native backups are free (pay only on restore). Cloud Storage exports cost ~$0.02-0.05/GB/month. Total estimated cost: under $5/month for most applications.

Five Key Lessons Learned

1. Environment Variables Must Be Explicit

Don't rely on build scripts to automatically switch .env files. Always explicitly copy the correct environment file:

# WRONG - relies on environment detection
pnpm build

# RIGHT - explicit environment file
cp .env.production .env && pnpm build

I learned this the hard way when staging accidentally connected to production Firebase.

2. Firebase Emulator is Essential

The Firebase Emulator Suite is not optional for development:

firebase emulators:start --only auth,firestore,storage

Benefits:

No API quota consumption
Fast reset (just restart)
Offline development
No accidental production writes

3. Custom Claims Require Admin SDK

Firebase Console has no UI for custom claims. You must use Firebase Admin SDK or create helper scripts.

I maintain a firebase-admin-scripts/ directory with:

set-claims.js - Set user custom claims
get-claims.js - View user's current claims
list-users.js - List all users with claims

4. Security Rules Need Comprehensive Testing

Write security rules tests alongside your rules:

// firestore.test.js (using @firebase/rules-unit-testing)
describe('Organization access', () => {
  it('should allow org member to read documents', async () => {
    const db = getFirestore(testEnv, {
      uid: 'user123',
      token: { organizations: { org_abc: 'viewer' } }
    });

    const doc = db.collection('organizations').doc('org_abc');
    await assertSucceeds(doc.get());
  });

  it('should deny non-member access', async () => {
    const db = getFirestore(testEnv, { uid: 'user456' });

    const doc = db.collection('organizations').doc('org_abc');
    await assertFails(doc.get());
  });
});

5. Document Your Deployment Process

Create a DEPLOYMENT.md file documenting:

How to deploy to each environment
Environment variable setup
Service account configuration
Rollback procedures
Common troubleshooting steps

Your future self (and team members) will thank you.

Key Takeaways

If you're building a multi-tenant Firebase application, here's what matters most:

Use separate Firebase projects per environment - Don't share databases between dev/staging/prod
Leverage custom claims for RBAC - More secure than Firestore lookups, works offline
Implement multiple backup layers - Daily, weekly, and monthly with different retention periods
Test security rules rigorously - Use Rules Playground and unit tests
Automate deployments - GitHub Actions or similar CI/CD
Use Firebase Emulator for development - Saves quota and prevents production accidents
Create Admin SDK helper scripts - Manual custom claims management gets tedious fast

Conclusion

Firebase is powerful for building multi-tenant applications, but proper infrastructure setup is crucial. The key is treating Firebase like any production infrastructure:

Multiple isolated environments
Automated deployments
Comprehensive backups
Strong security rules
Clear documentation

Invest time upfront in environment configuration, custom claims architecture, and backup automation. It pays off when you need to debug authentication issues, restore data, or onboard new team members.

Have you built multi-tenant applications with Firebase? What challenges did you face with custom claims or security rules? Share your experience in the comments!

Useful Resources

Questions about Firebase infrastructure or DevOps? Connect with me on LinkedIn or visit my portfolio.

Emergency Server Recovery: A 4-Hour Race Against Time

hello world_leo — Tue, 18 Nov 2025 15:57:06 +0000

The 3AM Wake-Up Call

You know that feeling when your phone buzzes at an ungodly hour and your stomach drops? That was me, staring at a frantic message: "Site is showing weird content. Help!"

I grabbed my laptop. The WordPress site was serving pharmaceutical spam to visitors. Classic compromise. The clock started ticking.

Hour 1: Damage Assessment (03:00 - 04:00)

First rule of server emergencies: don't panic, but move fast.
What I Did First
SSH into the server, check if I still had access. Good news: credentials still worked. Bad news: everything else.

#Check recent file modifications

find /var/www/html -type f -mtime -7 -ls | head -20

Tons of suspicious PHP files scattered everywhere. The wp-content/uploads folder was full of backdoors. Someone had gotten in through an outdated plugin, probably.
Quick Isolation
Pulled the site offline with a maintenance page. Better to show "down for maintenance" than spam pills to your visitors.

#Quick nginx block

location / {

    return 503;

}

Took a snapshot of everything before touching anything. You need evidence, and you might need to rollback if things go sideways.

Hour 2: The Cleanup (04:00 - 05:00)

Finding the Entry Point
Checked Apache/Nginx logs for unusual POST requests:

grep -i "POST" /var/log/nginx/access.log | grep -E "\.(php|asp|jsp)" | tail -100

Found it. An old contact form plugin with a known vulnerability. They uploaded a shell through a file upload field that wasn't properly validated.
Nuclear Option with Surgical Precision
Here's the thing about compromised WordPress sites: you can't trust anything. But you also can't just delete everything because you need the data.

My approach:

Backed up the database (even though it might be compromised)
Downloaded all uploaded media files
Saved the wp-config.php (to get database credentials)
Nuked everything else

#### Backup first

mysqldump -u dbuser -p dbname > backup_$(date +%Y%m%d_%H%M%S).sql

#### Fresh WordPress install

wget https://wordpress.org/latest.tar.gz

tar -xzf latest.tar.gz

Database Surgery
The database had malicious entries in these tables:

wp_options (autoload hooks)
wp_posts (spam content injected)
wp_users (unknown admin accounts)

Cleaned them manually. Yes, manually. Running automated scripts on a compromised database is asking for trouble.

-- Remove suspicious admin users

SELECT * FROM wp_users WHERE user_login NOT IN ('known_admin_1', 'known_admin_2');

DELETE FROM wp_users WHERE ID = [suspicious_id];

-- Check for injected JavaScript in posts

SELECT ID, post_title FROM wp_posts 

WHERE post_content LIKE '%<script%' 

OR post_content LIKE '%iframe%';

Hour 3: Hardening & Recovery (05:00 - 06:00)

The Rebuild
Fresh WordPress core, clean database, restored media files. Now comes the part most people skip: actually securing the thing.
File Permissions That Make Sense

# Directories: 755

find /var/www/html -type d -exec chmod 755 {} \;

# Files: 644

find /var/www/html -type f -exec chmod 644 {} \;

# wp-config.php: 440

chmod 440 /var/www/html/wp-config.php

chown www-data:www-data /var/www/html/wp-config.php
Disable File Editing
Added to wp-config.php:

define('DISALLOW_FILE_EDIT', true);

define('DISALLOW_FILE_MODS', true);

No more editing themes from the admin panel. If you need to update something, do it through SFTP like a proper developer.
Web Application Firewall
Configured ModSecurity with OWASP rules. Basic stuff:

apt-get install libapache2-mod-security2

cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

Changed SecRuleEngine DetectionOnly to SecRuleEngine On.

The Forgotten Hero: Fail2Ban
Set up Fail2Ban to block brute force attempts:

# /etc/fail2ban/jail.local

[wordpress]

enabled = true

filter = wordpress

logpath = /var/log/auth.log

maxretry = 3

bantime = 3600

Hour 4: Automation & Insurance (06:00 - 07:00)

Automated Backups That Actually Work
Wrote a bash script for daily backups to remote storage:

#!/bin/bash

TIMESTAMP=$(date +%Y%m%d_%H%M%S)

BACKUP_DIR="/backups"

# Database

mysqldump -u user -ppassword database > $BACKUP_DIR/db_$TIMESTAMP.sql

# Files

tar -czf $BACKUP_DIR/files_$TIMESTAMP.tar.gz /var/www/html

# Send to remote (S3, or whatever)

aws s3 cp $BACKUP_DIR/ s3://your-bucket/backups/ --recursive

# Keep only last 7 days locally

find $BACKUP_DIR -type f -mtime +7 -delete

Added it to crontab: 0 2 * * * /home/scripts/backup.sh

Monitoring Setup
Installed basic monitoring so next time we catch things early:

# Uptime monitoring

curl -X POST https://cronitor.io/api/monitors \

  -H "Content-Type: application/json" \

  -d '{"name": "client-site", "url": "https://example.com"}'

# File integrity monitoring

apt-get install aide

aide --init
SSL & Security Headers
Fresh SSL certificate with Let's Encrypt:

certbot --nginx -d example.com -d www.example.com

Added security headers to nginx:

add_header X-Frame-Options "SAMEORIGIN" always;

add_header X-Content-Type-Options "nosniff" always;

add_header X-XSS-Protection "1; mode=block" always;

add_header Referrer-Policy "strict-origin-when-cross-origin" always;

The Aftermath

By 7AM, site was back online. Clean, secured, monitored.

What the client saw: Their site back up, faster than before, with new security measures.

What they didn't see: The 4 hours of SSH sessions, database queries, and three cups of coffee.

Lessons From The Trenches

What Worked

Having a clear mental checklist for compromises
Not trusting anything on a compromised system
Taking backups before any action (even if you think you don't need them)
Hardening during recovery, not after

What I'd Do Different

Should have set up monitoring earlier (obviously)
Could have automated the cleanup scripts better
Next time: keep a USB drive with common tools ready

Prevention Is Cheaper Than Cure

After this incident, I set up these things for all client sites:

Weekly automated backups (tested restores monthly)
Security plugins with proper configuration
Update automation for core/plugins/themes
File integrity monitoring
Login attempt limiting

The Technical Stack Behind This Recovery

OS: Ubuntu 20.04 LTS
Web Server: Nginx 1.18
Database: MySQL 8.0
Backup Storage: AWS S3
Monitoring: Uptime Robot + custom bash scripts
Security: ModSecurity, Fail2Ban, Cloudflare WAF

Final Thoughts

Emergency recoveries are stressful. Your hands shake a bit when you're running rm -rf on a production server at 5AM. But this is what separates someone who just "knows WordPress" from someone who actually understands infrastructure.

The client was happy. The site survived. And I learned (again) that keeping systems updated and monitored is way easier than 4-hour emergency sessions.

Now I keep this checklist printed and stuck to my monitor. Because there will be a next time. There's always a next time.

Time taken: 4 hours
Coffee consumed: 3 cups
Client panic level: Reduced from 10/10 to 2/10
Would I do it again: Absolutely. But let's try to avoid it, yeah?

5 WordPress Performance Issues I Fix Every Week (And How You Can Too)

hello world_leo — Fri, 26 Sep 2025 13:41:00 +0000

As a DevOps engineer working with agencies in Indonesia, I see the same WordPress performance issues over and over again. After optimizing hundreds of WordPress sites, I've identified the 5 most common problems that slow down websites - and the practical solutions that actually work.

The Real Cost of Slow WordPress Sites

Before diving into solutions, let's be honest about what's at stake. A 1-second delay in page load time can reduce conversions by 7%. For an e-commerce site making $100,000 per month, that's $7,000 in lost revenue. For a service business, it's lost leads and frustrated potential clients.

I've seen clients lose significant business because their WordPress sites took 8+ seconds to load. The good news? Most performance issues are fixable with the right approach.

Issue #1: Database Bloat (Found in 80% of sites I audit)

The Problem: WordPress databases accumulate junk over time - spam comments, post revisions, transient data, and unused metadata. I recently audited a 2-year-old site where the database was 400MB, but only 50MB was actual content.

The Solution:

-- Check your database size first
SELECT 
    table_name AS "Table",
    ROUND(((data_length + index_length) / 1024 / 1024), 2) AS "Size (MB)"
FROM information_schema.TABLES 
WHERE table_schema = 'your_database_name'
ORDER BY (data_length + index_length) DESC;

Quick Wins:

Delete spam comments and post revisions
Clean up unused plugins and themes data
Remove expired transients
Use WP-Optimize plugin for regular maintenance

Real Result: One client's site went from 6.2s to 3.8s load time just from database cleanup.

Issue #2: Unoptimized Images (The Silent Performance Killer)

The Problem: I regularly see WordPress sites with 5MB+ images loading on mobile devices. A photography portfolio I worked on had 47 images totaling 180MB on their homepage alone.

The Solution:

Implement WebP format with fallbacks
Use responsive images (WordPress does this automatically if properly configured)
Compress images before upload
Set up proper image CDN

Quick Implementation:

// Add to functions.php for WebP support
function add_webp_support($mimes) {
    $mimes['webp'] = 'image/webp';
    return $mimes;
}
add_filter('upload_mimes', 'add_webp_support');

Real Result: E-commerce client reduced homepage size from 8.2MB to 1.4MB, improving load time by 65%.

Issue #3: Plugin Overload (The "Swiss Army Knife" Problem)

The Problem: Many sites use plugins that do way more than needed. I audited a simple business site running 47 plugins, including a full e-commerce suite just to display a contact form.

The Audit Process I Use:

List all active plugins
Test site performance with each plugin deactivated
Identify the worst performers
Find lighter alternatives or custom solutions

Common Culprits:

Page builders loading 2MB+ of CSS/JS
Social sharing plugins with 20+ network options
SEO plugins with overlapping functionality
Backup plugins running during peak hours

Real Result: Removing 12 unnecessary plugins improved a client's Time to First Byte from 2.1s to 0.8s.

Issue #4: Poor Caching Strategy (Or No Caching At All)

The Problem: 40% of sites I audit have no caching, and another 30% have poorly configured caching that's actually hurting performance.

My Caching Stack:

Server-level: Nginx FastCGI cache or Apache mod_cache
Application-level: WordPress object caching with Redis
Browser-level: Proper cache headers
CDN: CloudFlare or similar for static assets

Configuration That Works:

# Nginx FastCGI cache configuration
location ~ \.php$ {
    fastcgi_cache_valid 200 60m;
    fastcgi_cache_valid 404 10m;
    fastcgi_cache_bypass $skip_cache;
    fastcgi_no_cache $skip_cache;
    # ... other fastcgi settings
}

Real Result: Proper caching reduced server response time from 1.2s to 180ms for a high-traffic news site.

Issue #5: Hosting Mismatch (The $5/month Bottleneck)

The Problem: Running a complex WordPress site on shared hosting that costs $5/month is like trying to run a restaurant out of a food truck. It might work, but you'll hit limits quickly.

Red Flags I Look For:

Shared hosting for sites with 10,000+ monthly visitors
No SSD storage
PHP versions older than 7.4
No server-level caching options
Limited memory allocation (128MB or less)

Right-Sizing Hosting:

0-5K visitors/month: Quality shared hosting ($10-20/month)
5K-50K visitors/month: VPS with proper configuration ($20-50/month)
50K+ visitors/month: Managed WordPress hosting or custom VPS ($50+/month)

Real Result: Moving a client from $8/month shared hosting to $25/month VPS improved load time from 4.5s to 1.8s.

The Performance Optimization Process I Use

After fixing hundreds of WordPress sites, here's my systematic approach:

Phase 1: Audit (Day 1)

Baseline performance testing (GTmetrix, PageSpeed Insights, WebPageTest)
Database analysis and cleanup opportunities
Plugin performance profiling
Server configuration review

Phase 2: Quick Wins (Day 2)

Database optimization
Image compression and format conversion
Plugin audit and removal
Basic caching implementation

Phase 3: Advanced Optimization (Day 3)

Server-level caching configuration
CDN setup and optimization
Code-level optimizations
Performance monitoring setup

Phase 4: Monitoring (Ongoing)

Weekly performance checks
Monthly database maintenance
Quarterly plugin audits
Performance alerts for regression

Tools I Actually Use (Not Sponsored)

Free Tools:

GTmetrix for performance testing
Google PageSpeed Insights for Core Web Vitals
Query Monitor plugin for WordPress debugging
Chrome DevTools for detailed analysis

Paid Tools Worth It:

New Relic for server monitoring ($25/month)
CloudFlare Pro for advanced caching ($20/month)
WP Rocket for easy caching setup ($59/year)

What Results Should You Expect?

Based on my experience optimizing WordPress sites:

Database cleanup: 10-30% speed improvement
Image optimization: 20-50% speed improvement
Plugin optimization: 15-40% speed improvement
Proper caching: 30-70% speed improvement
Hosting upgrade: 25-60% speed improvement

Combined effect: Most sites see 40-70% overall improvement when all issues are addressed properly.

Common Mistakes to Avoid

Over-optimization: Don't chase perfect scores, chase good user experience
Plugin addiction: More caching plugins doesn't mean better performance
Ignoring mobile: 60%+ of traffic is mobile, optimize for it first
One-time fixes: Performance optimization needs ongoing maintenance
Cheap shortcuts: Free solutions often cost more in the long run

Your Next Steps

If your WordPress site is slow, start with these priorities:

Run a performance audit - Get baseline numbers first
Clean your database - Often the biggest quick win
Optimize images - Especially if you have a visual site
Audit plugins - Remove what you don't actually need
Set up proper caching - This can transform your site

Performance optimization isn't just about technical tweaks - it's about creating better user experiences that convert visitors into customers.