The code was never the bottleneck
A developer usually knows exactly what they need — the runtime, the owning team, the target Environment, sometimes even working code already. What they don't have is a repository, cloud infrastructure, IAM, a Kubernetes namespace, runtime identity, CI/CD, and the security scanning that has to sit in front of all of it. Each of those belongs to a different team, a different ticket queue, a different approval chain.
So the developer submits a request, waits, answers a follow-up question, opens another ticket, and waits again — while the code they already wrote sits untouched.
"Self-service" that's really just assembly work in disguise
Plenty of platforms call themselves self-service because developers can reach the Terraform modules, the Helm charts, the internal docs. But access to the building blocks isn't the same as a supported path — a developer still has to figure out which module applies, how Workload Identity should be configured, which repository template is actually current, and who signs off on a production change.
That's not self-service. That's asking developers to become platform engineers on top of their actual job. It doesn't scale any better than the ticket queue it replaced.
What governed self-service looks like instead
The goal isn't unrestricted infrastructure access — it's making the approved path the fastest one. A developer provides Application intent; Vertro applies the standards the platform team already defined. Nobody's inventing a new namespace convention per request, and nobody's waiting on a human to remember what the standard even is.
From request to running Application
- 1. Request the Application One structured request — Application name, owning team, Workload Type, runtime, target Environment, approved dependencies — instead of five separate tickets across five teams.
- 2. Generate the foundation Vertro prepares repositories, infrastructure configuration, identity, and namespace — generated into Git for review before anything is created, so the developer gets a consistent starting point instead of copying an old Application and guessing which parts still apply.
- 3. Connect secure delivery The Application is wired into the organization's standard build, test, scan, and deploy pipeline — nobody designs a new CI/CD model, and nobody skips the scanning step to save time.
- 4. Deploy through the approved path Delivery to GKE happens through standard packaging and GitOps. The developer works through familiar Git and pull-request workflows; the platform handles the rest.
- 5. Stay inside the guardrails Self-service doesn't end at first deployment — configuration, identity, and policy keep applying afterward, the same way they did on day one.
What a developer actually walks away with
A completed onboarding gives the Application team a real starting point, not a checklist to finish themselves: an application repository generated from an approved Golden Path, an infrastructure repository for Application-specific changes, a standard CI/CD workflow already matching the org's build and security standards, a GKE namespace with the right labels and quotas, runtime identity with no long-lived credentials to manage, and a GitOps path already wired for deployment. Ownership — Application, team, Environment, platform — is defined as part of the request, not figured out later.
Make the secure path the easiest one
Security breaks down when it depends on every developer remembering every control — configuring identity correctly, avoiding stored credentials, scanning before publishing, keeping software inventories current. Vertro puts those controls into the path itself, so a developer building the Application through the supported workflow gets them by default, not as a checklist they have to complete separately.
Powered by Gitleaks, Semgrep, SonarQube, Checkov, Trivy, Artifact Analysis, SBOM generation, Artifact Registry, and Binary Authorization.
Cloud access without a single stored credential
Applications running on GKE reach approved Google Cloud resources through GKE Workload Identity Federation, with least-privilege access scoped per Application and Environment. CI/CD authenticates the same way — GitHub Actions to Google Cloud through external Workload Identity Federation via GitHub OIDC — so nobody's creating, distributing, or rotating a long-lived service account key. More on how Vertro's identity model works.
Fewer tickets. Better platform work.
When onboarding is manual, platform engineers spend their day on the same handful of tasks, over and over — a namespace here, an IAM binding there, the same review conversation for the fifth time this month. Individually the tasks are fine. The interruptions compound.
Once the capability exists once, platform engineers stop repeating it and start improving it — better Golden Paths, new supported Workload Types, stronger security defaults, fewer exceptions to chase down.
Reviewable and auditable, not invisible
Self-service shouldn't mean infrastructure changes nobody can see happening. Vertro generates platform and infrastructure changes into Git, so teams get the pull-request workflow they already trust — review, approval, ownership, rollback context — with a visible chain from the original request all the way to the resulting deployment.
Implemented inside your own environment, not a third-party control plane
Vertro runs inside your own Google Cloud and GitHub environment — your team keeps the repositories, Terraform code, GKE clusters, IAM, and GitOps configuration it produces. See what stays in your environment.
Frequently asked questions
What does developer self-service mean?
Application teams can request and consume approved platform capabilities without relying on platform engineers to perform every setup task manually. Self-service remains governed by approved templates, infrastructure modules, identity patterns, security controls, policies, and review workflows.
Does developer self-service give developers direct access to everything?
No. Platform and security teams define the supported capabilities, controls, and approval requirements. Developers use those capabilities through a simplified workflow, not through unrestricted cloud or cluster access.
Do developers need to understand Terraform or Kubernetes?
No. Developers may still benefit from understanding the delivery environment, but they don't need deep Terraform, IAM, or Kubernetes expertise before they can begin building an Application.
Does Vertro replace the platform team?
No. Vertro gives the platform team a reusable way to deliver its standards. Platform engineers remain responsible for the architecture, modules, policies, Workload Types, security defaults, and supported delivery model.
Can teams customize the generated Application foundation?
Yes, within boundaries the organization sets. Golden Paths provide the supported default, and controlled changes or exceptions go through Git review and platform governance.
Is the developer portal the complete platform?
No. The Portal is the request interface. The platform itself coordinates repositories, infrastructure, IAM, CI/CD, artifacts, GitOps, security controls, and governance behind it.
Who owns the generated repositories and workflows?
You do. Vertro is implemented inside your own Google Cloud and GitHub environment, and the resulting repositories, infrastructure code, workflows, and platform configuration stay customer-controlled.