Skip to main content

GCP Infrastructure

The BigHammer platform can be deployed on Google Cloud Platform (GCP) using various provisioning methods, including:

  • GCP Console
  • GCP CLI (gcloud)
  • Terraform
  • Infrastructure-as-Code (IaC) tools approved by the customer

Regardless of the provisioning method used, the following reference architecture, resource requirements, and configuration values should be used as the baseline for setting up the infrastructure required for the BigHammer platform.

The sections below provide the recommended GCP services, networking requirements, IAM configuration, storage, compute resources, and other foundational components necessary for a successful deployment.

note

The exact implementation may vary based on customer-specific security, networking, compliance, and operational requirements. The reference values below are the minimum recommended configuration for deploying and operating the BigHammer platform in GCP.

Deploy readiness

After foundation is provisioned, use Prerequisites for the Helm deploy checklist (add-ons, firewall, tools).

ServiceDescription
GKEPrivate GKE cluster
Cloud SQLCloud SQL PostgreSQL — bighammer_db_<env>, keycloak_db_<env>, users, SSL certs → passwords in Secret Manager (incl. bh-kcdbpwd)
Secret ManagerBootstrap secrets; otherwise use gcloud / Console to create reference secrets (DB passwords, client certs)
GCSGCS buckets — placeholder (core Helm chart does not require GCS; Composer needs buckets for DAGs and related jobs)
Cloud DNSCloud DNS zone + application A records
IAMCI/CD SA, GAR reader for GKE node SA
Workload IdentityCI/CD or GitHub Actions + GKE Workload Identity bindings
KMSKMS for Secret Manager encryption
Cloud ComposerCloud Composer (Airflow) environment
DataprocDataproc service accounts (VM-backed clusters)
Vertex AIChat LLMs (Claude, Gemini) for AI Agent — APIs, SA, Model Garden, tenant config

Project & networking (reference dev)

SettingReference value
Project IDCustomer-specific (example: place-holder)
Region / zoneCustomer-specific (example: us-east1 / us-east1-b)
NetworkCustomer-specific VPC (example: place-holder)
Host VPC projectDedicated or Shared VPC host project (example: place-holder)
SubnetCustomer-specific primary subnet (example: place-holder)
Pod / service secondary rangesCustomer-specific secondary ranges for pods and services

GKE

SettingReference value
Cluster name prefixStandard naming convention (+ random suffix)
Kubernetes versionBigHammer tested version: 1.34.6-gke.1307000 (There is no specific constraint for other GKE versions, It should work without any issues.)
Release channelSTABLE
Node service accountCustomer-specific; example: <your-gke-node-sa>@<project>.iam.gserviceaccount.com
Workload IdentityEnabled
GCE PD CSI DriverEnabled
GCS FUSE CSI driverEnabled [Optional]
Node IAM (additional)Add roles/artifactregistry.reader on node SA to pull images from Google Artifact Registry

Node pool — platform / AI Agent (required)

SettingReference value
Pool nameCustomer-specific; example: <your-node-pool>
Machine typee2-standard-2 (2 vCPU, 8 GB RAM). There is no specific constraint for machine type, It should work without any issues with other machine types as well.
Node locationsRegional — zones supported in the target region; example: us-east1-b, us-east1-c
Autoscalingmin 1, max 4 (Since workloads are HPA enabled, and GKE will auto scaling enabled these values can be decided based on requirements )
Boot disk50 GB pd-standard
Node imageCOS_CONTAINERD
Secure BootEnabled

Additional node pools (optional)

No Specific requirement for Bighammer.

Cloud SQL

SettingReference value
Instance nameCustomer-specific; example: <your-postgres-instance>
PostgreSQL version16 (POSTGRES_16) — tested
Machine tierdb-custom-2-3840 (2 vCPU, 3.75 GB RAM)
Storage20 GB (minimum; scale per workload)
ConnectivityPrivate IP on VPC (no authorized networks)
SSL modePer customer security policy (recommended: TRUSTED_CLIENT_CERTIFICATE_REQUIRED)

Databases

Provision on the Cloud SQL instance. Names must match Helm values (POSTGRES_DB, KC_DB_URL).

DatabasePurposeHelm / chart
bighammer_db_<env>Application data (APIs, workers, keycloakapi_db schema)POSTGRES_DB on app services
keycloak_db_<env>Keycloak server database (SSO runtime tables)KC_DB_URL.../keycloak_db_<env>?... on bhkeycloak
Two databases — do not confuse
ApplicationKeycloak server
Databasebighammer_db_<env>keycloak_db_<env>
Provisioned byTerraform + schemas via bighammer_db_setup.sqlTerraform only (not in SQL script)
Chart serviceAPIs, workers, bhkeycloakapibhkeycloak only
Env varsPOSTGRES_DB, dual-role usersKC_DB_URL, KC_DB_USERNAME, KC_DB_PASSWORD
DB userbh_dev_user / bh_app_userkeycloak_db_user
GSM passwordbh-dev-user-password, bh-app-user-passwordbh-kcdbpwd

bhkeycloakapi uses bighammer_db_<env> (schema keycloakapi_db), not keycloak_db_<env>.

Reference Terraform creates both databases via additional_databases on the PostgreSQL module (for example bighammer_db_<env> and keycloak_db_<env> in <env>.auto.tfvars). Customer equivalents use the same naming pattern or override names consistently — see Renaming databases or users.

Database users

Users are created on the instance together with passwords stored in Secret Manager (reference: Terraform random_password → GSM). See Secret Manager Secrets for chart mapping.

UserPurposeSecret Manager password
postgresAdmin / bootstrap; not used by Helm at runtimedb-postgres-password
bh_dev_userMigrations / AlembicCREATE on schemas, DDL on tablesbh-dev-user-password
bh_app_userRuntime — DML only (BH_APP_USER in chart)bh-app-user-password
keycloak_db_userKeycloak server JDBC (KC_DB_USERNAME on bhkeycloak)bh-kcdbpwd

Terraform-managed (reference): Cloud SQL instance, databases (bighammer_db_<env>, keycloak_db_<env>), users above, client SSL certificates, and GSM secrets db-postgres-password, bh-dev-user-password, bh-app-user-password, bh-kcdbpwd, db-client-cert, db-client-private-key, db-server-ca-cert.

After Terraform (or equivalent provisioning):

  1. Application DB — run bighammer_db_setup.sql from the chart scripts/ folder as postgres to create schemas and grants inside bighammer_db_<env> (skip or comment CREATE DATABASE; use \connect bighammer_db_<env>). See Scripts Reference. Troubleshooting: Database Bootstrap Troubleshooting.
  2. Keycloak DB — database and user already exist; ensure keycloak_db_user has CONNECT and CREATE on keycloak_db_<env> and CREATE on schema public (Keycloak creates its own tables). Password is already in GSM as bh-kcdbpwd.
  3. One-time secrets — run bh_gsm_onetime_setup.sh for secrets not created by Terraform (admin password, RabbitMQ, license, etc.).

Cloud DNS

SettingReference value
Zone nameCustomer-specific; example: <your-dns-zone>
DomainCustomer-specific; example: <your-domain>
Zone typePer customer security policy — public or private hosted zone

Record examples: ui.<env>.<your-domain>, catalog.<env>.<your-domain>, kc.<env>.<your-domain> (A records → ingress / Gateway load balancer IP).

Secret Manager & KMS

SettingReference value
KMS key ringCustomer-specific; example: <your-kms-keyring> (or default Secret Manager encryption)
KMS crypto keyCustomer-specific; example: <your-kms-crypto-key> (or default Secret Manager encryption)

Secret names and chart mapping: Secret Manager Secrets.

GCS buckets (reference)

BucketPurpose
Customer-definedComposer DAG / plugin storage (required for Composer)
Customer-definedSpark / Dataproc event logs (optional analytics path)

Artifact Registry (reference)

SettingReference value
RepositoryDocker images — example: <bh-catalog-docker-repo>
RegionCustomer-specific; example: us-east1
Image path prefixus-docker.pkg.dev/{customer-project}/{artifact-registry-name}/

Cloud Composer (reference)

SettingReference value
EnvironmentCustomer-specific; example: <your-composer-environment>
ImageComposer image version from your release channel (example: composer-3-airflow-3.x)
SizePer workload (example: ENVIRONMENT_SIZE_SMALL)
Service accountCustomer-specific; example: <your-composer-sa>
GCS bucket (DAG sync)Customer-specific; example: <your-composer-dag-bucket>

Composer SA includes roles/dataproc.editor for submitting Spark jobs to Dataproc.

Dataproc (reference)

SettingReference value
Cluster keyCustomer-specific; example: <your-dataproc-cluster>
Service accountCustomer-specific; example: <your-dataproc-sa>
IAM roleroles/dataproc.worker

Vertex AI (LLM)

Optional - Required only when AI Agent tenants use Vertex-hosted chat models (anthropic_vertex or google_vertex providers).

APIs

APIPurpose
aiplatform.googleapis.comVertex AI model invocation (Claude partner models, Gemini)

Enable via Console, gcloud services enable, or your IaC (Terraform api_names).

Service account (Terraform-provisioned)

SettingDev examplePlaceholder
Account IDbh-nprd-vertexai-userbh-<env>-vertexai-user
Emailbh-<env>-vertexai-user@<project-id>.iam.gserviceaccount.comsame
Display nameVertex AI user for AI Agent (JSON key auth)same

IAM roles (project scope, assigned by Terraform):

RolePurpose
roles/aiplatform.userInvoke Vertex AI chat models
note

This SA is provisioning is required when tenant is using without Workload Identity bindings. Download a JSON key manually and configure tenant LLM with wif_enabled: false [ Setting can be seen in BHUI].

Model Garden

Before first inference, enable target models in Vertex AI → Model Garden for <project-id>:

Model familyExample model IDProvider key in AI Agent
Anthropic Claudeclaude-<version>anthropic_vertex
Google Geminigemini-<version>google_vertex
SettingNotes
Region / locatione.g. global, us-central1 — must match where the model is enabled
TermsPartner models (Claude) may require one-time acceptance in Model Garden
Workload Identity acknowledgment

When enabling Workload Identity in Admin Console, you must confirm that the Vertex AI model and AI Agent run on the same cloud platform. On mismatched platforms, disable WIF and use a service account key.

Post-provision verification

gcloud iam service-accounts describe bh-<env>-vertexai-user@<project-id>.iam.gserviceaccount.com

gcloud iam service-accounts keys create ./bh-<env>-vertexai-user-key.json \
--iam-account=bh-<env>-vertexai-user@<project-id>.iam.gserviceaccount.com

Workload Identity service accounts

GCP service accountKubernetes service account(s)IAM role
external-secrets-operatorbh-control-plane/external-secrets-operatorsecretmanager.secretAccessor
<your-app-gsa>All app KSAs in bh-control-planesecretmanager.admin

Full bindings and chart config: Workload Identity.

Helm chart inputs (after provisioning)

Map provisioned resources into your environment values file (for example values-prod.yaml):

Helm pathSource
global.secretStore.projectIdGCP project ID
global.gcpProject / global.gcpRegionProject and region
global.image.repositoryGAR or customer registry path
POSTGRES_HOSTCloud SQL private IP
POSTGRES_USER / POSTGRES_DBbh_dev_user / bighammer_db_<env> (migrations — Alembic)
BH_APP_USERbh_app_user (runtime SQLAlchemy URI)
global.remoteSecrets.postgres.passwordGSM key for POSTGRES_PASSWORD → use bh-dev-user-password
global.remoteSecrets.app.userPasswordGSM key for BH_APP_USER_PASSWORDbh-app-user-password
global.bhkeycloak.env.KC_DB_USERNAMEkeycloak_db_user
global.bhkeycloak.env.KC_DB_URLJDBC URL with database keycloak_db_<env>
global.remoteSecrets.keycloak.dbPasswordbh-kcdbpwd (Terraform → GSM)
global.remoteSecrets.*Other Secret Manager secret names

Renaming databases or users

If Terraform (or manual provisioning) uses different database or user names than the reference defaults, update every consumer below. Chart templates do not hardcode database names — all runtime values come from your values-<env>.yaml overlay.

bighammer_db_<env> → custom application database name

#Helm values path (values-<env>.yaml)FieldServices affected
1global.bhauditapi.envPOSTGRES_DBbhauditapi
2global.bhauditworker.envPOSTGRES_DBbhauditworker
3global.bhcatalogapi.envPOSTGRES_DBbhcatalogapi
4global.bhcatalogworker.envPOSTGRES_DBbhcatalogworker
5global.bhaiagent.envPOSTGRES_DBbhaiagent
6global.bhaiagent.envSYNC_DB_URLbhaiagent (path segment after host/port)
7global.bhaiagentworker.envPOSTGRES_DBbhaiagentworker
8global.bhaiagentworker.envSYNC_DB_URLbhaiagentworker
9global.bhkeycloakapi.envPOSTGRES_DBbhkeycloakapi
10global.bhcelerybeat.envPOSTGRES_DBbhcelerybeat

Total in chart values: 10 fields across 8 services (8× POSTGRES_DB + 2× SYNC_DB_URL).

Also update outside the Helm values file (not chart templates):

LocationWhat to change
Terraform / Cloud SQLadditional_databases entry for the application DB
bighammer_db_setup.sql\connect, GRANT CONNECT ON DATABASE, and CREATE DATABASE (if used)
GSMNo secret name change for app users; passwords must still match bh_dev_user / bh_app_user in Cloud SQL

keycloak_db_<env> → custom Keycloak database name

#Helm values pathFieldService
1global.bhkeycloak.envKC_DB_URLbhkeycloak — database name is the path segment after host/port in the JDBC URL (.../keycloak_db_<env>?...)

Total in chart values: 1 field (KC_DB_URL). KC_DB_HOST / KC_DB_PORT are separate and do not embed the database name.

Also update outside Helm values:

LocationWhat to change
Terraform / Cloud SQLadditional_databases entry for Keycloak DB
GSM bh-kcdbpwdSecret name unchanged; value must match the Keycloak DB user password in Cloud SQL

bighammer_db_setup.sql does not touch the Keycloak database.

keycloak_db_user → custom Keycloak DB user name

#Helm values pathFieldService
1global.bhkeycloak.envKC_DB_USERNAMEbhkeycloak

Total in chart values: 1 field.

Also update outside Helm values:

LocationWhat to change
Terraform / Cloud SQLadditional_users entry for Keycloak JDBC user
GSM bh-kcdbpwdPassword for the new username
global.remoteSecrets.keycloak.dbPasswordOnly if you rename the GSM secret itself (default stays bh-kcdbpwd)

Quick reference — reference defaults

ObjectTerraform (reference)Chart env varGSM
Application DBbighammer_db_<env>POSTGRES_DB (8 services)
Keycloak DBkeycloak_db_<env>KC_DB_URL (bhkeycloak)
Keycloak userkeycloak_db_userKC_DB_USERNAMEbh-kcdbpwd

See also Scripts Reference — Keycloak database and Secret Manager — Keycloak.

Customer artifact mirror workflow: Release Manifest & Distribution.