Automating Firebase Deployments: Multi-Account Routing and Discord Notifications

Situation

When one machine or one backend service deploys to multiple Firebase projects/environments, the biggest risk is targeting the wrong project.

The documented pattern in RADXA AI Suite is to treat deployment as a configuration-driven workflow instead of a set of manual CLI steps.

The Configuration: accounts.json

Instead of relying on whoever last ran firebase login, deployments are described via an explicit account profile file:

• account id + email
• Firebase project_id and friendly project_name
• environment routing (production, staging, development)
• per-environment hosting targets
• optional Discord webhook settings per account

This makes “where does this deploy go?” answerable by reading a single file.

API-Driven Account Switching

The guide also documents an API endpoint that selects which account/profile to deploy with, so automation can switch contexts deliberately rather than implicitly.

Discord Webhook Notifications

Deploy status becomes team-visible by emitting Discord webhook messages:

• notify on start/success/failure
• include logs (with a configurable max line count)
• allow distinct channels per project/account

The result is a deployment flow where:

1. the target environment is chosen from config
2. the Firebase CLI runs with the intended context
3. the outcome is broadcast to Discord with enough log context for quick triage

Architecture Diagram

This diagram supports Automating Firebase Deployments: Multi-Account Routing and Discord Notifications and highlights where controls, validation, and ownership boundaries sit in the workflow.

Post-Specific Engineering Lens

For this post, the primary objective is: Improve release confidence with visible automation outcomes.

Implementation decisions for this case

• Chose a staged approach centered on firebase to avoid high-blast-radius rollouts.
• Used devops checkpoints to make regressions observable before full rollout.
• Treated automation documentation as part of delivery, not a post-task artifact.

Practical command path

These are representative execution checkpoints relevant to this post:

npm run build
firebase deploy --only hosting
curl -I https://<site>/health

Validation Matrix

Validation goal	What to baseline	What confirms success
Functional stability	latency, error budget burn, and cost profile	SLO dashboard remains within target after rollout
Operational safety	rollback ownership + change window	autoscaling and quotas stay inside guardrails
Production readiness	monitoring visibility and handoff notes	security policy checks pass in CI and runtime

Failure Modes and Mitigations

Failure mode	Why it appears in this type of work	Mitigation used in this post pattern
Pipeline secret drift	Deploy path fails unexpectedly	Pin secret names and validate before deploy step
Notification-only success	Chat alert says success while endpoint is broken	Gate notifications on real health checks
Environment mismatch	Prod/staging behavior diverges	Use explicit environment matrix in pipeline config

Recruiter-Readable Impact Summary

• Scope: improve reliability while keeping cloud spend predictable.
• Execution quality: guarded by staged checks and explicit rollback triggers.
• Outcome signal: repeatable implementation that can be handed over without hidden steps.