Nahid
HomeAboutSkillsProjectsExperienceBlogContact

2025-10-02

Deploying Full-Stack Prototypes on GCP: What Actually Breaks

CloudDeploymentGCPFirebaseCloud RunEngineering

Shipping a prototype is one thing. Deploying it with authentication, real-time updates, data persistence, and user workflows is where the software stops being code and starts being infrastructure. Over the past two years I deployed multiple prototypes on Google Cloud Run, Firebase, and Firestore — including Assurenest AI (AI assurance), Trireme Factor Lens (quant dashboards), HuskyChain (Telegram/Web3 game backend), and the CV Optimizer (mobile app + parsing pipeline).

The interesting part wasn’t building them — it was making them run in the real world.

Cloud Run Isn’t a Server — It’s a Contract

Cloud Run looks like a server, but it behaves like a contract. It spins up, shuts down, reconfigures, and scales based on its own economics.

Typical surprises:

  • cold starts when idle (especially Python + heavy deps)
  • concurrency mismatches (dashboards want streaming; Cloud Run wants batching)
  • request timeouts on long simulations
  • memory spikes for parsing PDFs and factor data
  • region-specific feature availability

The mental shift: you don’t deploy code, you deploy trade-offs.

Region Constraints Are Real

One of the more amusing issues I hit was that domain mapping didn’t support Europe-West2 at a time I needed it. I deployed the container successfully, but couldn’t bind the domain, SSL, or routing. The fix was redeploying to a different region.

Lesson: the cloud is not global — it’s a map of political + regulatory + pricing compromises.

Auth: Firebase vs Cloud Run

Firebase Auth assumes client-first identity.
Cloud Run assumes server-first identity.

When Assurenest AI needed RBAC and dashboards, I had to reconcile:

  • ID tokens (short-lived)
  • refresh tokens (client-bound)
  • session cookies (server-bound)
  • Firestore rules (policy-bound)

The final stack became:


Firebase Client Auth → ID Token → Firebase Admin Verify → HttpOnly Cookie → RBAC Check → API Access → Firestore

This is more compliance-friendly and works with dashboards.

Lesson: auth is not a feature — it’s systems design under constraints.

SSE vs WebSockets

Real-time UX is addictive. Assurenest AI and Factor Lens benefited from streaming updates for dashboards, status messages, and pipeline outputs. But streaming on Cloud Run is opinionated.

WebSockets require sticky connections and state; Cloud Run does not guarantee either. I switched to SSE:

  • simpler to implement
  • works with stateless containers
  • behaves predictably with scaling
  • better for dashboards and extensions

Lesson: pick protocols based on infra, not taste.

Firestore Schema Drift

NoSQL lets you prototype fast, but you pay for that speed later. When Assurenest AI’s assurance modules evolved (hallucination → bias → PII → quality → sentiment), the documents mutated.

Firestore has:

  • no migrations
  • no versioning
  • no constraints
  • no strict typing

Every prototype eventually becomes a schema crime scene.

I started versioning module payloads inside objects:


checks: {
hallucination_v1: { ... },
pii_v2: { ... }
}

Primitive, but future-proof.

Container Bloat & Build Times

Factor Lens used Pandas + NumPy + simulation code in Python. CV Optimizer used PDF/DOCX tooling. Both inflate images.

Container bloat breaks prototypes by:

  • increasing build times
  • slowing CI/CD
  • bloating deployments
  • burning Cloud Run startup budgets

The fix:

  • split pipelines
  • separate parsing services
  • slim base images
  • use cached layers
  • isolate Python from Node dashboards

Lesson: bloat is not aesthetic — it’s a scaling cost.

Service Accounts & Secrets

Service accounts are harmless until you need them across:

  • local development
  • cloud deployment
  • browser extensions
  • serverless functions

Service account JSON does not belong in client apps, ever.
Assurenest AI needed Admin SDK for token verification + RBAC, so env vars became the canonical interface.

Rule of thumb: if it touches identity or writes, it belongs on the server.

Pricing Surprises

Firestore pricing looks cheap until dashboards render in loops. Every redraw becomes a read. Every pipeline write becomes multiple writes.

Factor Lens simulations were cheap in compute but expensive in read/write throughput. Assurenest logs were cheap storage but expensive on iteration.

Lesson: state is the bill.

Prototype → Compliance Tension

AI assurance is inherently compliance-adjacent. Compliance is allergic to ambiguity. Prototypes are ambiguity factories.

To ship Assurenest AI I had to make peace with the contradiction:

  • prototypes explore
  • compliance restricts
  • audits demand answers
  • LLMs produce uncertainty

Lesson: compliance is not a feature — it’s a boundary condition.

Failure Mode: Multi-Project Infra

Running several prototypes under one GCP/Firebase umbrella revealed invisible coupling:

  • IAM roles collide
  • Firestore rules collide
  • Cloud Run services collide
  • billing collides
  • secrets collide

Isolation is underrated.
Single-project clouds are luxurious.
Multi-project clouds are honest.

Closing Thoughts

Deploying prototypes forces a shift from “can I build this?” to “can I operate this?”. That’s the real bar for software. Infrastructure doesn’t care about ideas or ambition — it cares about memory, concurrency, protocols, authentication, billing, and time.

If coding is for building systems, deployment is for understanding them.