18. GCP as the Platform Vendor; Firebase as the Application Layer

Status

Accepted — 2026-04-24 (supersedes ADR 0005)

Context

ADR 0005 designated Firebase as the sole infrastructure vendor. This framing served the project well — it prevented multi-vendor sprawl and consolidated billing, auth, and observability into a single GCP project. However, the framing conflated two things: GCP as the platform vendor and Firebase as the product layer within GCP.

Firebase is a GCP product. Every Firebase service runs on GCP infrastructure. The Firestore instance is a GCP Datastore-mode resource. Cloud Functions v2 are Cloud Run services. Firebase Hosting is backed by Cloud CDN and Cloud Storage. The project already acknowledged this in ADR 0012 by adopting Terraform to manage the GCP substrate beneath Firebase.

Two capabilities now needed have no Firebase equivalent:

  1. CI/CD orchestration. The project uses GitHub Actions with a long-lived Firebase Service Account key stored as a GitHub Secret. Google Cloud Build offers native GCP integration, IAM-based authentication (no stored keys), and includedFiles path filtering for monorepo-aware triggers. Firebase has no CI/CD product.

  2. Managed search and RAG. The “Ask Ernest” chatbot (ADR 0015) uses a custom embedding pipeline with Firestore vector search. Vertex AI Search (Discovery Engine) provides managed document ingestion, chunking, indexing, and grounded answer generation as a turnkey service. Firebase has no search or RAG product.

Rejecting these services solely because they carry a “GCP” label rather than a “Firebase” label would be an artificial constraint. The spirit of ADR 0005 — single vendor, single billing surface, single auth model — is fully preserved when adopting GCP platform services within the same project.

Decision

GCP is the sole infrastructure vendor. Firebase remains the application layer within GCP.

Firebase owns the application surface:

  • Hosting — static assets, preview channels
  • Cloud Functions — all backend compute (callable, scheduled, triggered)
  • Firestore — sole runtime datastore
  • Auth — identity, custom claims, anonymous auth
  • App Check — reCAPTCHA Enterprise, abuse prevention
  • Remote Config — feature flags and runtime tunables
  • Storage — user and system assets
  • Secret Manager — API keys and credentials (accessed via defineSecret())

GCP platform services are adopted where Firebase has no equivalent:

  • Cloud Build — CI/CD pipeline with native IAM authentication, replacing GitHub Actions + stored service account keys
  • Vertex AI Search (Discovery Engine) — managed document search and grounded answer generation for the Ernest AI chatbot, replacing the custom Firestore vector search pipeline
  • Cloud Scheduler — cron-triggered builds and function invocations (already in use for LinkedIn autoposter and Ernest sync)
  • BigQuery — log analytics via logging sinks (already in use for Ernest and LinkedIn function logs)
  • Artifact Registry — Cloud Functions build artifacts (already in use, managed by Cloud Build)

The boundary from ADR 0012 still holds: Terraform manages the GCP substrate (APIs, service accounts, IAM, Cloud Build triggers, Discovery Engine resources). Firebase CLI manages the application (hosting deploys, function code, Firestore rules, Remote Config).

Third-party services (Resend, Sentry, LinkedIn API, Gemini API) continue to be called from Cloud Functions, not from the client.

Consequences

  • The single-vendor benefits of ADR 0005 are preserved: one GCP project, one billing surface, one IAM model, one Terraform state file.
  • Cloud Build eliminates the long-lived service account key stored in GitHub Secrets — a security improvement. Authentication uses the Cloud Build service account with IAM roles, not exported credentials.
  • Vertex AI Search replaces the custom embedding pipeline (chunking, hashing, vector indexing, findNearest() queries), reducing maintenance surface and leveraging managed infrastructure.
  • The project gains access to GCP services that Firebase cannot provide, without introducing a second vendor or a second billing surface.
  • ADR 0005’s constraint — “Feature choices are constrained to what Firebase offers” — is relaxed to: feature choices are constrained to what GCP offers, with Firebase as the preferred product layer.
  • The mental model shifts from “Firebase only” to “GCP project, Firebase-first.” This is a minor cognitive overhead for a solo maintainer but reflects the reality that the project already uses GCP services (Secret Manager, Cloud Scheduler, BigQuery, Artifact Registry) through Firebase’s GCP integration.

See also: ADR 0005 — Firebase as Sole Infrastructure Vendor (superseded), ADR 0012 — Terraform for GCP Resource Management, ADR 0015 — Ernest AI RAG Chatbot.