What you receive

You receive a working web application, front end and back end, deployed into your dev, staging and prod projects on top of the GCP Enterprise Baseline, together with the three Git repositories that define it, customized for your organization, and the documentation to run and change it. After handover your engineers own all of it.

How delivery works

The blueprint is sold with the Baseline in Full Deployment with Blueprints, or on its own as a Blueprint Deployment for customers who already run the GCP Enterprise Baseline. In both cases the BuiltForProd team deploys it, and the first deployment of each stage is performed once by that team. See blueprints for how the blueprints fit together and purchasing and licensing for the terms.

The repositories

Repository	You receive
acme-gcp-blueprint-webapp-infra	Ten OpenTofu modules, eleven Terragrunt units, one stack template, a stack file per stage, five guard scripts, and the plan, apply and drift-detection workflows
acme-gcp-blueprint-webapp-gitops	The blueprint-app Helm chart with its ten templates, base values, hand-maintained values per stage, and the image file per stage that the deploy pull requests write
acme-gcp-blueprint-webapp-code	The Flask API and its tests, the React app, the API and front end Dockerfiles, the front end deploy script, five GitHub Actions workflows and the shared action that opens deploy pull requests against the GitOps repository

acme in the names is your namespace. Your domain, your GitHub organization and the project IDs of the Baseline are set in the code before deployment. Every value a deployment must set carries a TODO: marker, and every switch you may change later carries an @optional: marker with its list price where it has one, so git grep "@optional: " in any of the three repositories lists the choices. Each repository carries the PolyForm Internal Use License 1.0.0 in LICENSE.md.

The running application

In each of dev, staging and prod:

• A regional GKE Standard cluster, acme-usw1-<stage>-gke, with private nodes, a DNS-based control-plane endpoint, Dataplane V2, a system node pool reserved for platform components and node auto-provisioning for the application, plus the add-ons the infrastructure repository installs: External Secrets, two external-dns releases, cert-manager and ArgoCD.
• The API running as a Kubernetes Deployment, reachable over HTTPS at blueprint-api.<stage>.company.com through a GKE Gateway with Cloud Armor.
• The single-page app at blueprint-app.<stage>.company.com, served by the Cloud Run service acme-usw1-<stage>-frontend behind a global external Application Load Balancer with Cloud CDN and Cloud Armor.
• A Firestore database with MongoDB compatibility and a Memorystore for Valkey instance, both with IAM authentication, and their connection values in the stage project's Secret Manager.
• Google-managed certificates for both public hosts, and an internal certificate authority in the cluster for internal hosts.
• ArgoCD at argocd.<stage>.internal.company.com on an internal load balancer, reachable only from inside the Shared VPC or through kubectl port-forward.

The sample application is an items API: list, create, read and delete items in Firestore, with reads cached in Valkey for 60 and 300 seconds, and a React dashboard and items page that call it.

The delivery pipeline

• Pull requests to the code repository run Ruff, pytest, shellcheck, the front end build, both container builds and a Trivy scan of both images. This workflow never signs in to Google Cloud.
• A merge to main builds the API image once and opens a deploy pull request for dev that merges itself. A change under frontend/ builds the front end image and deploys it to the dev Cloud Run service.
• A GitHub Release tags both images with the version, opens the staging deploy pull request, which merges itself, and deploys the front end to staging and, after approval, to prod.
• A manual workflow promotes a release to prod through a pull request that a person merges; ArgoCD in prod then waits for a manual sync.
• Pull requests to the infrastructure repository plan all three stages; a merge applies them, with prod waiting for a reviewer. A daily run reports drift as an issue.

The documentation

This documentation set: the architecture, the Kubernetes platform, the GitOps model, the application, the pipelines, the data stores, networking and TLS, security, observability, every unit and module, and the guides for day-2 work such as releasing, rolling back and scaling a stage. The sizing of each stage is on sizing per stage.

What stays with the Baseline

The organization, the projects, the Shared VPC, the DNS zones, the CI identities, the guardrails, the security services and Artifact Registry come from the GCP Enterprise Baseline. The blueprint reads what it needs from Parameter Manager in each stage project and does not change the Baseline. The architecture overview shows how the two connect, and repositories describes what each repository holds.