From Application request to governed delivery path
Vertro turns Application onboarding, Google Cloud infrastructure provisioning, secure CI/CD, GitOps delivery, and GKE governance into one repeatable platform workflow.
What Vertro standardizes
Most Application onboarding repeats the same work: create infrastructure, configure access, establish runtime identity, create repositories and namespaces, wire CI/CD, apply security controls, and connect the deployment path.
Vertro turns that repeated work into a reusable platform workflow that developers can request and platform teams can govern.
Velocity
Applications move from request to a working delivery foundation through a predefined workflow instead of one-off setup.
Trust
Identity, IAM, DevSecOps checks, approvals, and platform policies are built into the standard path.
Control
Platform teams manage infrastructure, configuration, delivery boundaries, and governance through version-controlled workflows.
Repeatability
Every Application receives the same governed foundation unless a documented exception is approved.
Platform bottlenecks Vertro addresses
Application delivery becomes difficult to scale when every team depends on manual platform work. Vertro focuses on the recurring bottlenecks that emerge as Google Cloud and GKE adoption grows.
Slow Application onboarding
Teams wait for infrastructure, IAM, repositories, namespaces, CI/CD, security controls, and Environment configuration before they can deploy.
Repeated platform work
Platform engineers repeatedly assemble the same infrastructure, identity, repository, and delivery foundations for every Application.
Inconsistent delivery paths
Teams create different repository structures, IAM patterns, pipelines, deployment workflows, Environment rules, and operating assumptions.
Security added too late
Identity, secret handling, scanning, approvals, image controls, and policies are often introduced after the delivery path already exists.
High developer cognitive load
Developers must understand infrastructure, Kubernetes, IAM, CI/CD, and deployment details before they can focus on Application functionality.
Growing platform debt
Manual onboarding creates configuration drift, duplicated automation, undocumented exceptions, and delivery patterns that become harder to maintain.
Business outcomes
Vertro turns repeated platform engineering work into a reusable operating model. The outcome is faster Application delivery with stronger security, consistency, and governance.
| Outcome | What changes | Business value |
|---|---|---|
| Faster time to delivery | Application onboarding follows a guided and predefined workflow instead of a chain of manual setup tasks. | Teams move from request to a working Application foundation faster. |
| Lower platform overhead | Common infrastructure, identity, repository, Kubernetes, and delivery artifacts are generated and applied through controlled workflows. | Platform teams spend less time resolving repetitive tickets and more time improving shared capabilities. |
| Security built into the path | Workload Identity Federation, IAM, scanning, branch protection, approvals, artifact controls, and policies are applied through standardized patterns. | Security controls are introduced before Applications reach protected Environments rather than added later. |
| Improved developer experience | Developers submit Application requirements through a guided workflow and receive a ready-to-use delivery foundation. | Teams focus more on Application code and less on assembling infrastructure and delivery tooling. |
| Reduced delivery drift | Golden Paths, Git review, Terraform, Config Sync, Argo CD, Helm, and policy controls keep delivery patterns aligned. | Application Environments become easier to operate, secure, audit, and scale. |
Day 0: Application onboarding
Day 0 establishes the initial foundation for a new Application. A developer or team submits an Application request through the Vertro Portal, and Vertro converts that intent into reviewable platform configuration.
Request
The Portal captures the Application name, owner, Workload Type, target Environment, exposure model, infrastructure requirements, APIs, IAM permissions, compute settings, and dependencies.
Validate and generate
The Orchestrator validates the request and generates the required infrastructure inputs, platform configuration, namespace definitions, identity requirements, repository scaffolding, and Application configuration.
Open platform pull requests
Vertro opens reviewable pull requests for Google Cloud infrastructure and GKE platform configuration so platform teams can see and approve the proposed changes before execution.
Provision and configure
After approval and merge, the Executor runs controlled GitHub Actions workflows to provision cloud resources, configure identity, create repositories, establish namespaces, and prepare the Application delivery path.
Day 1: secure Application delivery
Day 1 begins after the Application foundation exists. Developers work from a Golden Path repository and use standardized workflows to build, validate, promote, and deploy changes.
| Workflow area | What happens | Why it matters |
|---|---|---|
| Golden Path repository | Application code structure, container configuration, Helm chart, CI/CD workflows, and Environment configuration are scaffolded from an approved template. | Teams begin from a working and governed baseline instead of assembling delivery components from scratch. |
| CI and DevSecOps | GitHub Actions builds and tests the Application and can perform secret, code, dependency, infrastructure, and container image scanning. | Security and quality checks become part of the standard workflow rather than team-specific additions. |
| Artifact promotion | Evaluated container images can be promoted across Environments using immutable image digests and controlled approval workflows. | Teams deploy the same evaluated artifact instead of rebuilding different images for each Environment. |
| GitOps delivery | Argo CD reconciles approved Application state into governed GKE namespaces using Helm-based delivery patterns. | Deployment state remains versioned, traceable, repeatable, and recoverable. |
| Ephemeral Environments | Where included, feature-branch workflows can create short-lived developer testing Environments and remove them when no longer required. | Developers can validate changes earlier without creating permanent Environment sprawl. |
Day 2: governance and platform control
Day 2 covers the controls that keep the platform consistent after onboarding. Vertro separates Application delivery from platform governance so developers can move quickly without owning or bypassing the platform’s operational boundaries.
Configuration reconciliation
Config Sync continuously reconciles platform-owned Kubernetes configuration and policies from the platform configuration repository.
Namespace and resource controls
Namespaces, labels, ownership metadata, quotas, limits, RBAC, and other baseline controls are applied consistently.
Policy enforcement
Policy Controller and admission policies can prevent workloads that violate defined security, metadata, resource, or deployment requirements.
Runtime identity controls
Application Kubernetes service accounts receive scoped Google Cloud IAM permissions through GKE Workload Identity Federation without an intermediary Google service account.
Delivery and artifact controls
Promotion workflows, image scanning, immutable digests, approvals, and Binary Authorization can govern what reaches protected Environments.
Auditability
Application requests, generated configuration, pull requests, approvals, workflow logs, security results, artifact records, and deployment history provide traceability.
Application onboarding blueprint
See how one guided request becomes two coordinated delivery paths: the Google Cloud foundation and the Application onboarding path. The blueprint also shows the Git review, private ARC runner, Workload Identity Federation, Terraform, Config Sync, Argo CD, and Helm responsibilities behind the workflow.
Vertro Application Onboarding Blueprint
From one Application request to customer-owned GCP infrastructure and governed GKE delivery.
┌──────────────────────────────────────────────────────────────────────────────┐
│ VERTRO PORTAL │
├──────────────────────────────────────────────────────────────────────────────┤
│ App Team submits a guided request │
│ │
│ • Application name • Application type / runtime │
│ • Environments • Predefined compute profile │
│ • Required Google Cloud services │
└─────────────────────────────────────┬────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ VERTRO ORCHESTRATOR │
├─────────────────────────────────────┤
│ • Validate the request │
│ • Apply approved defaults │
│ • Generate desired state │
│ • Create repositories and PRs │
└──────────────────┬──────────────────┘
│
▼
┌─────────────────────────────────────┐
│ GIT REVIEW AND APPROVAL │
├─────────────────────────────────────┤
│ Generated changes are reviewed and │
│ merged before execution begins │
└──────────────────┬──────────────────┘
│
▼
┌─────────────────────────────────────┐
│ SECURE EXECUTION LAYER │
├─────────────────────────────────────┤
│ GitHub Actions │
│ ↓ │
│ Private ARC runners on Platform GKE │
│ ↓ │
│ Workload Identity Federation │
└──────────────────┬──────────────────┘
│
┌────────────────────┴────────────────────┐
│ │
▼ ▼
PATH 1: GCP FOUNDATION PATH 2: APPLICATION ONBOARDING
┌───────────────────────────────────┐ ┌───────────────────────────────────┐
│ Terraform / Terragrunt provisions │ │ Repositories created from │
│ │ │ approved templates │
│ • GCP projects │ │ │
│ • Enabled APIs │ │ • Application repository │
│ • IAM and service accounts │ │ • Infrastructure/config repo │
│ • Cloud SQL instance │ │ • CI/CD workflows │
│ • Secret Manager │ │ • Helm chart and values │
│ • Cloud Storage │ │ • Argo CD Application config │
│ • Private connectivity │ └──────────────────┬────────────────┘
│ • Labels and ownership metadata │ │
└──────────────────┬────────────────┘ ▼
│ ┌───────────────────────────────────┐
│ │ Config Sync reconciles │
│ │ platform-owned GKE configuration │
│ │ │
│ │ • Namespace │
│ │ • Resource quotas and limits │
│ │ • Kubernetes service account │
│ │ • Network policies │
│ │ • Policies and guardrails │
│ └──────────────────┬────────────────┘
│ │
│ ▼
│ ┌───────────────────────────────────┐
│ │ CI/CD builds and validates │
│ │ │
│ │ • Build and test │
│ │ • Security checks │
│ │ • Container image │
│ │ • Artifact Registry │
│ └──────────────────┬────────────────┘
│ │
│ ▼
│ ┌───────────────────────────────────┐
│ │ Argo CD + Helm deploy │
│ │ the Application to GKE │
│ └──────────────────┬────────────────┘
│ │
└────────────────────┬──────────────────┘
│
▼
┌─────────────────────────────────────┐
│ RESULT │
├─────────────────────────────────────┤
│ Customer-owned cloud foundation, │
│ governed GKE configuration, CI/CD, │
│ identity and GitOps delivery path │
└─────────────────────────────────────┘Architecture overview
The diagram below shows how Vertro connects the Portal, Orchestrator, GitHub workflows, Google Cloud infrastructure, GKE platform controls, and GitOps delivery into one governed Application onboarding path.
Frequently asked questions
What is Vertro?
Vertro is a GCP-native Internal Developer Platform accelerator that standardizes Application onboarding, Google Cloud infrastructure provisioning, secure CI/CD, GitOps delivery, and platform governance for teams running on GKE.
What problem does Vertro solve?
Vertro reduces manual platform tickets, repeated infrastructure and IAM work, inconsistent delivery paths, security drift, and the time required to build an Internal Developer Platform from scratch.
Does Vertro provision Google Cloud projects and resources?
Yes. Vertro can provision isolated Application projects and supporting resources such as APIs, IAM, Artifact Registry, Cloud SQL, Secret Manager, Cloud Storage, and other Application infrastructure based on the approved onboarding request.
Does Vertro require developers to learn Terraform or Kubernetes?
No. Developers submit Application requirements through the Vertro Portal. Platform-owned Terraform, Kubernetes configuration, and delivery workflows handle the implementation behind the request.
Can Vertro work with existing GKE clusters?
Yes. Vertro can be implemented with new or existing GKE foundations, depending on the organization’s networking, governance, security, and operating model.
Does Vertro support GitOps?
Yes. Vertro separates platform configuration from Application delivery. Config Sync reconciles platform-owned configuration and policies, while Argo CD and Helm manage Application delivery into governed GKE namespaces.
Where does provisioning run?
Provisioning runs through controlled GitHub Actions workflows. These workflows can execute on private ARC runners hosted in the Platform GKE environment.
How does Vertro handle identity for Applications and CI/CD?
Runtime Applications use GKE Workload Identity Federation so Kubernetes service accounts receive scoped Google Cloud IAM permissions without long-lived service account keys. GitHub Actions uses a separate external Workload Identity Federation trust for CI/CD access.
Does Vertro include DevSecOps controls?
Vertro can include secret scanning, SAST, dependency and software composition analysis, infrastructure-as-code scanning, container image scanning, SBOM generation, immutable image promotion, approvals, and Binary Authorization.
Does Vertro support ephemeral Environments?
Yes, where included in the implementation scope. Feature-branch workflows can create short-lived developer testing Environments and remove them automatically when they are no longer needed.
Is Vertro a generic developer portal?
No. The Portal is only the request interface. Vertro is an opinionated Google Cloud and GKE platform implementation that includes provisioning, identity, CI/CD, GitOps, security controls, policy enforcement, and governance workflows.
Who is Vertro for?
Vertro is designed for SaaS, mid-market, platform engineering, and enterprise teams using or adopting Google Cloud and GKE that want faster Application onboarding and secure delivery without building a large internal platform program from scratch.