How a Terraform factory cut environment provisioning from weeks to hours

Most infrastructure teams don't have a Terraform problem. They have an abstraction problem. The modules work. The state is clean. But every new environment is still a manual, error-prone process of copying, renaming, and hoping. This is the story of fixing that - not by writing more Terraform, but by writing less.

The problem: copy-paste infrastructure

The team had four GCP environments - dev, test, staging, production. Each one was a separate Terraform directory, hand-written, loosely copied from the last one. The modules underneath were solid. But the layer that wired them together into a complete environment was pure HCL, duplicated four times with subtle variations.

This is the pattern most teams recognize: the modules are fine, but the environment layer drifts. Dev gets a feature flag that staging doesn't. Production has a firewall rule that test lost in a merge. Nobody knows which difference is intentional and which is accidental drift. And adding a fifth environment - which the team was about to do - meant copying the whole thing again and introducing a new set of drift.

The platform team was spending more time maintaining the differences between environments than building anything new. A new environment took weeks of multi-team coordination. Not because the work was hard, but because the surface area for error was huge.

The diagnosis: HCL is the wrong layer for environment config

The issue wasn't the Terraform modules - those were well-built, versioned, and tested. The issue was the layer above them. Platform engineers were writing HCL directly to compose modules into environments, and HCL is a poor configuration language for that job.

HCL is powerful enough to express infrastructure, but it's too powerful for configuring infrastructure that's already been expressed. When your modules handle the complexity, the environment layer should be simple: here's the name, here's the region, here's the CIDR, here's which features to enable. That's configuration, not code. And configuration should be YAML, not HCL.

The move: a YAML factory on top of the modules

We kept every Terraform module intact. What we built was a factory layer - a single Terraform entrypoint that reads YAML files and feeds them to the modules.

What we actually did

• Created a YAML schema for environments.Each environment became a single YAML file: name, region, network CIDR, subnet count, firewall rules, IAM service accounts, and feature toggles. Simple enough that a platform engineer who doesn't know Terraform can read and edit it.
• Built a factory module that reads the YAML.One Terraform module uses for_each over the YAML files to produce all environments from a single terraform apply. The factory calls the existing modules - VPC, firewall, IAM, project factory - passing each environment's config as variables.
• Standardized security policies with default-plus-override merging.WAF and security rules follow a pattern: a set of sane defaults that every environment inherits, plus an override block where environments can add specific rules. The factory merges them, so base security is never accidentally skipped.
• Automated firewall rules per environment.The factory iterates over a list of firewall rules in the YAML and creates them viafor_each - no more hand-writing a new firewall resource block per rule per environment.
• Wired it into CI/CD.A pull request that adds a new YAML file triggers a terraform plan in CI. The platform team reviews the plan, merges, and the environment provisions automatically. No one runs terraform apply manually.

The result: adding an environment = adding a file

The moment that proved the factory worked: the team needed to add a fifth environment for a new compliance regime. The platform lead created one YAML file, opened a PR, reviewed the generated plan, and merged. The environment was live in under two hours.

Zero HCL changes. Zero new module code. Zero copy-paste. Zero drift - because every environment is generated from the same modules, differenced only by its YAML config. If a module changes, all environments inherit the change. If an environment needs something unique, it lives in the YAML as an explicit, visible override.

The factory also made environments auditable. Security and compliance teams can read the YAML and understand exactly what's provisioned in each environment without reading Terraform. That alone saved days of review time during their next audit cycle.

Why this matters beyond the time savings

The time savings - weeks to hours - is the headline. But the deeper shift is in who can contribute. Before the factory, shipping an environment required deep Terraform expertise. After the factory, it requires the ability to edit a YAML file and read a plan.

That's the principle: HCL is for the few people who build the platform. YAML is for the many people who use it. When you treat Terraform as the engine and YAML as the user interface, you've built a platform - not just an infrastructure repository.

Most teams get this backwards. They treat Terraform as the user interface, and every environment change becomes a coding task. It shouldn't be. If scaling your infrastructure means writing more Terraform, you've built the wrong abstraction.

Engagement shape

• Duration: 3 weeks (design + implementation + handover).
• Scope: factory design, module refactoring, CI/CD integration, YAML schema, documentation, handover.
• Risk profile: low - existing modules preserved, factory added as a new layer on top.
• Outcome: environment provisioning from weeks to hours, zero drift, auditable configs, platform accessible to non-Terraform engineers.

Related reading

This case study connects to our broader FinOps and platform engineering work. The Terraform factory pattern is what enables Stage 4 of FinOps maturity (Prevention through automation) - where the infrastructure itself enforces cost-conscious defaults. Read the full framework: The FinOps Maturity Model: A Practical Guide to the 5 Stages.

And see how this same platform-thinking applied to cost: how we cut a GCP bill 60% by matching the platform to the workload.

Published: 2026-08-06 - Alveon