GCP Project Organization

The infrastructure follows Google’s Cloud Foundation Toolkit layered architecture, with a clear separation between bootstrap, shared, and application-layer projects.

This document indexes the important projects so developers can quickly find what they need. Note that project IDs include a 4-character hex suffix that is auto-generated at project creation time. Terraform resolves projects dynamically via labels at plan time, so these IDs are primarily for reference and lookup — you rarely need to hardcode them.

Organization Structure

thehelperbees.com
├── fldr-bootstrap
│   └── Seed, Bootstrap CI/CD projects
├── fldr-common
│   └── General CI/CD, Org-wide services, shared services
├── fldr-development
│   └── All dev environment projects
├── fldr-non-production
│   └── All staging/UAT projects
├── fldr-production
│   └── All production projects
├── system-gsuite
│   └── apps-script
│       └── ~105 auto-generated sys-* projects (not indexed)
└── thb-root-folder
    └── Legacy bootstrap projects

Project Naming Convention

Pattern: prj-{scope}-{environment}-{name}-{suffix}

Examples:

• prj-bu1-p-hb-infra-1da6 → Business Unit 1, Production, HB Infrastructure
• prj-c-secrets-a7cc → Common, Org-wide Secrets

Quick Reference: App Infrastructure Projects

This is the primary lookup table for developers making infrastructure changes.

All app infrastructure follows predictable patterns:

• Local path: infra/{infra-name}/business_unit_1/{environment}/
• Terraform command: ./zig/zig build plan -- {infra-name} {environment}

HB (default)

Infra name: hb-infra

Bees (Yellow)

Infra name: bees-infra

HomeAlign (HA)

Infra name: ha-infra

PD (Partner Dashboard & Resources)

Infra name: pd-infra

Common (Shared)

Infra name: common-infra

Supporting Projects

Vault (Secrets & Keys)

Vault is split into two projects per environment: one for encryption keys (KMS) and one for secrets storage.

BU1 Shared Services

These projects provide shared infrastructure consumed by all BU1 application projects.

Ansible (Configuration Management)

Foundation Projects

These projects are managed by the foundation repositories (gcp-org, gcp-environments, gcp-networks, gcp-projects), not by infrahive. Developers rarely interact with these directly but may see them referenced in configs or backend state.

Bootstrap & Seed

Org-Wide Shared Services

Per-Environment Shared Services

Legacy Projects

These projects sit at the organization root (not in folders), predate the Cloud Foundation Toolkit, and are generally not Terraform-managed. They are included here for reference when tracing data flows or access patterns.

How Projects Are Referenced in Terraform

Dynamic Resolution via Labels (Primary)

Most Terraform directories resolve the GCP project at plan time using label-based data sources. This is why developers rarely need to know the exact hex suffix of a project ID.

data "google_projects" "environment_projects" {
  filter = "parent.id:${folder_id} labels.application_name=${var.application_name} labels.environment=${var.environment} lifecycleState=ACTIVE"
}

Cross-Project References (.auto.tfvars)

When one project references another, IDs are hardcoded in .auto.tfvars files scoped to that environment. This is the primary place where full project IDs with hex suffixes appear.

# infra/pd-infra/production.auto.tfvars
hb_project_id            = "prj-bu1-p-hb-infra-1da6"
vault_keys_project_id    = "prj-bu1-p-vault-keys-cfcb"

Service Account Impersonation

Each infra project uses a dedicated service account from the seed project (prj-b-seed-c80c) for all Terraform operations. The build system handles impersonation automatically; this table is for reference when debugging IAM issues.

Related Repositories

Excluded From This Index

The following project categories exist in the organization but are intentionally excluded from this document:

• ~105 sys-* projects: Auto-generated by Google Workspace/Apps Script; live in the Apps Script folder (388964465723)
• gam-project-* (4 projects): GAM automation projects managed by IT
• Personal test projects (~10): Individual developer sandboxes at the org root
• billing-model-* (3 projects): Billing configuration projects managed externally