Product overview

How Vertro works

Vertro is a GCP-native internal developer platform that standardizes how new applications are requested, provisioned, deployed, and governed on Google Cloud and GKE.

Primary platformGoogle Cloud + GKE

Execution modelGitHub Actions on ARC runners

Delivery modelTerraform, Config Sync, Helm, ArgoCD

What Vertro standardizes

Most application onboarding work repeats the same pattern: create a project, configure access, create a namespace, wire identity, create repositories, configure pipelines, and connect the deployment path. Vertro turns that repeatable work into a governed platform workflow.

Core principle: developers should be able to request a service without waiting on manual platform tickets, while platform teams keep control of infrastructure, access, and deployment standards.

Velocity

New services follow a predefined path instead of one-off setup.

Trust

Identity, IAM, security controls, and approvals are part of the workflow.

Control

Platform standards are managed through Git, Terraform, Config Sync, and policy.

Repeatability

Every app receives the same governed foundation unless exceptions are approved.

Pain points Vertro addresses

Internal developer platforms are usually created because application delivery becomes too dependent on manual platform work. Vertro focuses on the recurring bottlenecks that appear when GKE usage grows across teams.

Slow service onboarding

New applications wait on platform tickets, access setup, namespace creation, CI/CD wiring, and environment configuration before teams can ship.

Repeated platform work

Platform engineers repeat the same provisioning, identity, and deployment setup for every new service instead of improving the platform.

Inconsistent delivery paths

Different teams create different repo layouts, deployment workflows, IAM patterns, environment rules, and operational assumptions.

Security added too late

Identity, IAM, secret handling, and approval controls often get addressed after the application path already exists.

Developer cognitive load

Developers have to understand too many infrastructure and deployment details before they can focus on the application itself.

Platform debt

As more applications are onboarded manually, the organization accumulates drift, exceptions, and hard-to-maintain delivery patterns.

Business outcomes

Vertro is designed to turn platform engineering work into a repeatable operating model. The goal is not only automation; the goal is faster delivery with stronger governance.

Outcome	What changes	Business value
Faster time to market	Application onboarding follows a predefined path instead of manual setup.	New services can move from request to deployable foundation much faster.
Lower platform overhead	Common infrastructure, identity, and delivery tasks are generated and executed through controlled workflows.	Platform teams spend less time on repetitive tickets and more time improving standards.
Consistent security posture	Workload Identity, IAM, branch protection, and delivery guardrails are part of the onboarding path.	Security is built in before applications reach production.
Improved developer experience	Developers request what they need through a guided workflow and receive a ready delivery path.	Teams focus more on code and less on infrastructure assembly.
Reduced delivery drift	Platform-controlled templates, Git review, Terraform, Config Sync, Helm, and ArgoCD keep patterns consistent.	Environments become easier to operate, audit, and scale.

Day 0: application onboarding

Day 0 is the initial setup path for a new application. A developer or team submits the application request through the Vertro portal. The request captures the information needed to generate platform artifacts.

Step 1

Request

The portal captures application name, team ownership, environment, runtime, exposure, IAM roles, APIs, compute defaults, and dependencies.

Step 2

Generate

The orchestrator generates Terraform variables, Kubernetes manifests, service account configuration, and an application config YAML record.

Step 3

Open PRs

Vertro opens platform pull requests. Platform teams can review what will be provisioned before execution begins.

Step 4

Provision

After merge, the executor runs the provisioning workflow and creates the required cloud, Kubernetes, repository, and delivery resources.

Day 1: delivery path

Day 1 begins after the application foundation exists. Developers work in the generated application repository and use the delivery workflows included in the template.

Workflow area	What happens	Why it matters
Application repo	Source code, Dockerfile, Helm chart, and environment values are scaffolded from a template.	Teams start from a working baseline instead of assembling delivery from scratch.
CI/CD	GitHub Actions builds, scans, and promotes application changes through standard workflows.	Delivery becomes consistent across teams and services.
GitOps	ArgoCD applies application delivery state into governed GKE namespaces.	Runtime changes remain traceable and repeatable.
Ephemeral environments	Feature branch workflows can create short-lived environments and clean them up when no longer needed.	Teams can test changes earlier without permanent environment sprawl.

Day 2: governance and control

Day 2 covers the operational controls that keep the platform consistent after onboarding. Vertro separates application delivery from platform governance so developers can move quickly without bypassing standards.

Config Sync

Cluster-level platform configuration is continuously reconciled from the platform config repository.

Namespace controls

Namespaces, resource quotas, limit ranges, and platform labels are applied consistently.

Identity controls

Kubernetes service accounts are wired to Google service accounts through Workload Identity.

Audit trail

Requests, PRs, generated files, workflow logs, and deployment records provide traceability.

Architecture model

Vertro is intentionally split into clear responsibilities. The portal collects the request, the orchestrator generates artifacts, and the executor performs provisioning after platform approval.

Developer request
      ↓
Vertro Portal
      ↓
Platform Orchestrator
      ↓
Platform PRs
      ↓
Executor on ARC runners
      ↓
Terraform + Kubernetes + Repo setup
      ↓
GKE delivery path

Execution boundary

The orchestrator does not run Terraform, Helm, or kubectl directly. Execution happens through controlled GitHub Actions workflows on ARC runners inside the platform environment.

Frequently asked questions

What is Vertro?

Vertro is a GCP-native internal developer platform that standardizes application onboarding, infrastructure provisioning, CI/CD, and governance for teams running on Google Cloud and GKE.

What problem does Vertro solve?

Vertro reduces manual platform tickets, inconsistent application setup, repeated IAM work, delivery drift, and the cost of building an internal platform from scratch.

Does Vertro create GCP projects?

Yes. Vertro can create isolated application GCP projects and wire billing, APIs, service accounts, IAM, and Workload Identity.

Does Vertro require developers to learn Terraform?

No. Developers submit application requirements. Platform-owned Terraform handles provisioning behind the workflow.

Can Vertro work with existing GKE clusters?

Yes. Vertro can be configured for new or existing GKE clusters, depending on the client environment and governance model.

Does Vertro support GitOps?

Yes. Vertro separates platform configuration and application delivery through Git-based workflows, Config Sync, Helm, and ArgoCD.

Where does provisioning run?

Provisioning runs through GitHub Actions on ARC runners hosted in the shared platform GKE environment.

Does Vertro support Workload Identity?

Yes. Vertro uses Workload Identity to connect Kubernetes service accounts to Google service accounts without long-lived service account keys.

Does Vertro support ephemeral environments?

Yes. The delivery model can include feature-branch environments that are created for testing and cleaned up automatically when no longer needed.

Is Vertro a generic developer portal?

No. Vertro is an opinionated GCP and GKE platform implementation. The portal is one interface, but the value is the underlying provisioning, delivery, and governance workflow.

Who is Vertro for?

Vertro is designed for SaaS, platform engineering, and enterprise engineering teams that want faster GKE onboarding without building a full internal developer platform from scratch.