I’m prototyping a self-service sandbox that stamps out per-team GCP projects with Terraform plus org policies baked in. The goal is user-centric: teams can tune runtime knobs (region, CPU class, egress tiers) while the platform enforces budgets and network boundaries; right now PR-to-sandbox is about 12 minutes via GitHub Actions. For those doing similar, what config surface do you expose without turning the platform into a choose-your-own-adventure?
We cut re-runs by adding a Conftest/OPA step that validates tfvars (region, CPU class, egress tier) against an allowlist and budget thresholds before plan, so teams can choose but bad combos never hit apply; it kept our GitHub Actions loop close to your ‘12 minutes’. Small caveat: make rule messages very clear or folks will try to work around them.
I shaved our PR-to-sandbox from about 14 to about 7 minutes by caching Terraform providers/modules in GitHub Actions — set “TF_PLUGIN_CACHE_DIR” and use actions/cache, plus a runner image with gcloud and Terraform preinstalled. For your 12 minutes, that usually frees 3–5 min, but you’ll need to bust the cache when terraform.lock.hcl or provider versions change. Doc for the plugin cache: Create a Terraform CLI configuration file | Terraform | HashiCorp Developer.
But we ended up keeping a small pool of pre-seeded GCP projects with the “org policies baked in” and shared VPC attached, then our Terraform just applies team tfvars/IAM on claim — cut cycle time a lot and reduced flake, though keeping the pool warm (and cleaning budgets/labels) is a bit . If you go this route, Project Factory makes the seeding repeatable: GitHub - terraform-google-modules/terraform-google-project-factory: Creates an opinionated Google Cloud project by using Shared VPC, IAM, and Google Cloud APIs. Have you considered a project pool so teams still tune region/CPU/egress without waiting on full project creation?
I’ve found that giving teams access to predefined IAM roles really cuts down on back-and-forth when they’re setting up their projects. It speeds things up a lot, especially when you’re enforcing budgets and network boundaries. Have you considered tweaking your org policies to allow more flexibility based on project maturity? @r_woods23 might have some insights on balancing that freedom.