GCP Project Consolidation — HubOps / Deliveries

Andi Lamprecht ·2026-05-11· 9 min read· Draft

Executive Summary

The HubOps / Delivery platform is spread across five GCP projects because the migration from the original “Deliveries” projects to the newer “HubOps” projects was never completed. Today:

• Firestore + Firebase Auth remain in the legacy droneup-deliveries / droneup-deliveries-dev projects.
• Compute (GKE), PubSub, Secret Manager, CloudSQL, Redis run in droneup-hubops-dev / droneup-hubops-prod.
• mongodb-hubops-service is a standalone project with no active code references — a likely abandoned MongoDB Atlas peering project.
• Every HubOps microservice carries cross-project IAM bindings so it can reach the legacy Firestore, adding operational and cost overhead.

Recommendation: consolidate the five projects into two (droneup-hubops-dev and droneup-hubops-prod) through a phased migration. Delete mongodb-hubops-service immediately.

1. Current State

1.1 Project Inventory

1.2 Dependency Map

    graph TB
    subgraph compute["Primary Compute (HubOps)"]
        HP["droneup-hubops-prod<br/>GKE • PubSub • GSM<br/>CloudSQL • Redis"]
        HD["droneup-hubops-dev<br/>GKE • PubSub • GSM<br/>CloudSQL • Redis"]
    end
    subgraph legacy["Legacy Firestore / Firebase"]
        DP["droneup-deliveries<br/>Firestore • Cloud Functions<br/>GCS • PubSub • Firebase Auth"]
        DD["droneup-deliveries-dev<br/>Firestore • Cloud Functions<br/>GCS • PubSub"]
    end
    HP -- "Firestore reads<br/>(cross-project IAM)" --> DP
    HD -- "Firestore reads<br/>(cross-project IAM)" --> DD
    MH["mongodb-hubops-service<br/>NO ACTIVE USE"]
  

2. Project-by-Project Breakdown

3. Recommendations

Phase 0 — Quick Wins Immediate

Phase 1 — Consolidate Deliveries into HubOps Medium-term

The core problem: Firestore stayed in the old droneup-deliveries* projects while everything else moved to droneup-hubops*. The migration was never finished.

Exit criterion: both droneup-deliveries and droneup-deliveries-dev can be deleted with no active references.

Phase 2 — Target State (2 projects) Final

    graph TB
    subgraph target["Target: 2 GCP projects"]
        direction LR
        HP["droneup-hubops-prod<br/>GKE • Firestore • Firebase Auth<br/>PubSub • GSM • CloudSQL<br/>Redis • GCS"]
        HD["droneup-hubops-dev<br/>GKE • Firestore • Firebase Auth<br/>PubSub • GSM • CloudSQL<br/>Redis • GCS"]
    end
    subgraph deleted["Deleted"]
        DD["droneup-deliveries"]
        DE["droneup-deliveries-dev"]
        MH["mongodb-hubops-service"]
    end
    style deleted fill:#fee,stroke:#c33,stroke-dasharray:5
  

Estimated cost reduction from eliminating three GCP projects:

• Three sets of project-level charges (logging, monitoring)
• Cross-project network egress (Firestore reads from hubops → deliveries)
• Unused Cloud Functions billing
• Unused GCS storage for legacy backups
• IAM surface area — fewer service accounts to rotate and audit

4. Repositories Affected

Phase 0

None — GCP Console and Terraform operations only.

Phase 1 — config + Terraform changes

5. Risks and Mitigations

6. References

• droneup-hubops-infrastructure/legacy/ — verified legacy folder tree with droneup-deliveries + droneup-deliveries-dev subdirs
• pe-tfc-automation/legacy_tfc.tf — verified du-deliveries / du-deliveries-dev workspace definitions
• hubops-delivery-react-native/src/api/auth/auth.api.ts — verified hardcoded droneup-deliveries + cloudfunctions.net/deliveries-activeUser references
• hubops-mission-service Helm values — verified FIREBASE_PROJECT_ID settings per environment

7. Next Steps

1. Review with the HubOps platform team and name a migration owner.
2. Execute Phase 0 this sprint (deletion of mongodb-hubops-service, PubSub cleanup, DB_HOST reconciliation).
3. Open an ADR under content/docs/HubOps/ADR/ capturing the consolidation decision once target state is agreed.
4. Plan Phase 1 as a multi-sprint initiative — migration runbook, Frontegg completion, mobile app release schedule, analytics pipeline cutover.