The foundation layer, before any Application exists
Before a developer writes a line of code for a new Application, someone has already made a series of platform decisions: which GCP project it lives in, what APIs are enabled, how IAM is scoped, which network it connects to, which GKE cluster it deploys onto, and how DNS resolves to it. Those decisions get made once, by whoever's available, and then quietly become precedent for the next team that asks.
This is the layer underneath Application onboarding — the cloud and Kubernetes foundation, not the Application itself. Get it right once, as a repeatable capability, and every Application built on top of it inherits that consistency for free.
What Vertro standardizes at the project and network layer
Vertro provisions Google Cloud projects tied to an App Code and Environment, applying required APIs, baseline IAM, and cost-tracking labels the same way every time — generated into Git for review before anything is created. Networking follows one of a small set of approved patterns your platform team selects once — Shared VPC, hub-and-spoke, or a standalone platform network — rather than becoming a developer-facing choice made ad hoc per project.
The deeper mechanics of how a request becomes a reviewed, generated change are covered on how Vertro works; the specific problem of provisioning drift and when to fix it is covered in standardizing GCP provisioning. This page is about what the platform actually includes at this layer.
The GKE foundation: three clusters, not one, not per-team
Vertro's baseline architecture separates the platform's own execution workloads from customer Application workloads, and separates production from everything else: a Platform Cluster for automation, a Non-Production Cluster for dev, qa, and staging, and a Production Cluster with its own trust boundary. A single shared cluster puts your CI/CD automation and your production traffic behind the same failure domain; a cluster per team or per Application multiplies operational cost without a proportional isolation benefit. For Vertro's baseline implementation, three clusters provide a practical balance between production isolation and operational overhead.
Automated, not just documented
Every GCP project gets the same baseline, regardless of who requests it. Required APIs, IAM scoping, and cost-allocation labels are generated automatically at provisioning time — not added later when someone notices they're missing.
Kubernetes tenancy isolation is layered, not left to a single control. Namespace boundaries, identity, quotas, and network policy combine to isolate each Application Environment on shared clusters, rather than relying on any one mechanism alone.
Internal routing follows a predictable pattern instead of one load balancer per Application. A shared Gateway per Application Cluster handles internal exposure by default; external, public-facing exposure is treated as its own higher-risk, explicitly approved pattern.
Powered by Terraform, Terragrunt, GKE (private nodes, Shielded Nodes, Dataplane V2), Gateway API, and Cloud DNS.
Identity without long-lived cloud keys
Applications running on GKE access approved Google Cloud resources through GKE Workload Identity Federation. CI/CD authenticates separately through external Workload Identity Federation using GitHub OIDC. Both paths avoid stored Google Cloud service account keys and apply scoped access through the organization's approved IAM model. Full identity architecture is covered on Security and Guardrails.
What stays yours
Vertro provisions this foundation inside your own Google Cloud Organization — your team keeps the GKE clusters, the Terraform state, the IAM, and the networking it produces, and operates all of it directly. See what stays in your environment.
Frequently asked questions
Does Vertro manage our GKE clusters for us?
Vertro provisions and configures the baseline GKE architecture — Platform, Non-Production, and Production clusters — as part of implementation. Your team retains operational ownership of the clusters, the same way you own everything else Vertro produces inside your environment.
Does Vertro support multi-region GKE deployments?
The baseline architecture assumes a single-region GKE foundation per Environment class. Multi-region patterns are evaluated during implementation scoping based on the customer's availability requirements, not assumed as a default.
Does Vertro support Shared VPC or hub-and-spoke networking?
Vertro supports a limited set of approved network patterns, including Shared VPC, hub-and-spoke, and standalone platform network topologies. Network topology itself remains a customer architecture decision, not a developer-facing choice in the Portal.
Why three GKE clusters instead of one shared cluster?
A single shared cluster puts platform automation and every Application's production workloads behind the same failure and trust boundary. Separate Platform, Non-Production, and Production clusters isolate production risk without the cost of a cluster per team or per Application.
Does automating GCP provisioning remove our platform team's control over infrastructure?
No. Platform and security teams define the approved network patterns, IAM baselines, and resource modules. Vertro applies those decisions consistently through automation — it doesn't make the decisions on the platform team's behalf.
Does Vertro require GKE, or does it work with Cloud Run too?
Vertro's current customer Application delivery model is focused on GKE. Cloud Run is not part of the standard customer Application Golden Path today and would require separate scoping.