This starts before a single Application exists
Long before anyone onboards an Application, someone has to create the GCP project it will live in — enable the right APIs, wire up IAM, set networking, apply labels for cost tracking. That work usually happens once per team, done by whoever's available, referencing whatever the last project looked like. Six months and a dozen projects later, no two look quite the same.
This is a different layer from Application onboarding. It's the foundation an Application eventually gets deployed into — and if the foundation is inconsistent, every Application built on top of it inherits that inconsistency, even if the Application itself is onboarded perfectly.
What inconsistent provisioning actually costs
Provisioned by hand, project by project
One project has billing labels, another doesn't. IAM bindings vary depending on who set it up and what they remembered to lock down. Some projects have unused APIs still enabled. Naming conventions drift the moment a second person starts creating projects.
Provisioned from a standard
Every project — regardless of who requested it — gets the same baseline: required APIs enabled, IAM scoped the same way, labels applied automatically for cost allocation, and a naming pattern that's predictable instead of improvised.
None of the shortcuts look risky in the moment. They surface later — in a cost report that can't attribute spend because labels are missing, in a security review that finds an API nobody remembers enabling, or in a new engineer who has to ask three people how project naming actually works here.
Why "we have a Terraform module" doesn't fully close the gap
Most teams past a certain size already have a project-creation Terraform module. It genuinely helps — but someone still runs it, decides which variables apply to this project, and remembers which IAM roles this particular team actually needs. A module is reusable code. It isn't a decision-free process. The gap between "we have a module" and "every project is provisioned identically" is exactly where the drift creeps back in.
What Vertro standardizes at the project layer
Vertro ties GCP project creation to an App Code and Environment — the same organizational ownership metadata that later determines who owns what, without re-entering it per project. Provisioning applies required APIs, baseline IAM, network connectivity, and labeling automatically, generated into Git for review before anything is created — the same reviewable-by-design approach used for Application onboarding, applied one layer down at the infrastructure foundation.
The deeper mechanics of how requests, Git review, and execution work together are covered on how Vertro works and the platform overview — this page is about the specific layer that provisioning problem lives at, and why it's worth solving separately from Application onboarding rather than assuming it comes along for free.
Provisioning proof, not just policy
Every project gets predictable IAM, not whatever the provisioner remembered this time. Baseline role bindings are applied the same way across every project belonging to an App Code, scoped to what that team actually needs.
Cost allocation actually works, because labels aren't optional. Ownership, environment, and cost-center metadata are generated automatically at project creation, not added after finance asks why a project has no owner.
Powered by Terraform and Terragrunt, with changes reviewed through Git before execution.
Frequently asked questions
Isn't this what Terraform modules are for?
A module handles the resource definitions. It doesn't decide which variables apply to this project, or whether this team needs the same IAM as the last one — someone still makes that call by hand. Vertro turns that judgment call into a repeatable request instead of leaving it to whoever is provisioning today.
Can Vertro fix GCP projects we already have?
Vertro standardizes provisioning for new projects going forward. Reconciling existing projects — inconsistent IAM, missing labels, orphaned APIs — is a separate, scoped cleanup your team decides on its own timeline, not something Vertro assumes or automates retroactively.
Does this replace our GCP Organization and folder structure?
No. Vertro provisions within your existing Google Cloud Organization and folder hierarchy — Platform, Non-Production, and Production boundaries stay yours to define. Vertro standardizes what happens inside that structure, not the structure itself.
What if our environments don't map cleanly to dev, qa, staging, and prod?
Environment names are configuration, not a fixed list. Vertro separates the environment name from its governance class, so you can add environments that match your actual naming without redesigning the underlying model.
Does every Application get its own GCP project?
Not necessarily. The baseline model ties a project to an App Code plus Environment, and multiple Applications belonging to that App Code can share the same project — balancing isolation against project sprawl rather than defaulting to one project per Application.
How many GCP projects should we include in the first rollout?
Start with one or two App Codes going through provisioning end-to-end, including IAM, networking, and labeling. That's enough to confirm the standard holds before applying it across every team requesting a new project.