Repository architecture
Organize stacks, modules, environments, and dependencies around ownership and deployment boundaries.
Terraform consulting for infrastructure that needs to change safely.
Infrastructure as code should make changes easier to understand and review. Instead, many teams inherit repositories where a small change produces an enormous plan, state boundaries are unclear, and applying changes requires specialist knowledge. We improve Terraform architecture, modules, state management, and delivery workflows so infrastructure changes can happen without unnecessary risk or manual intervention.
The problem
Your infrastructure is in code. That doesn't automatically make it maintainable.
The repository describes history. It does not yet describe a change an engineer can review.
What a change plans
As found
- plan scope
Root module, one state
network
- vpc
- subnets
- nat
- dns
cluster
- eks
- node pool
- iam roles
service
- api, one-line change
- worker
- database
api: one-line change
Plan scope: the entire state
01
Infrastructure changes are difficult to review
Large root modules combine unrelated resources and produce plans that reviewers cannot confidently evaluate.
02
State boundaries are unclear
Critical systems share state and permissions even when they should be deployed and maintained independently.
03
Modules have become copy-paste templates
Reusable infrastructure lacks stable interfaces, versioning, or clear ownership.
04
Manual changes create drift
Resources are modified outside the codebase, making subsequent plans harder to trust.
What changes
Make infrastructure changes smaller, clearer, and repeatable.
Reviewable plans
Changes are isolated to appropriate stacks and infrastructure boundaries.
What a change plans
- plan scope
Root module, one state
network
- vpc
- subnets
- nat
- dns
cluster
- eks
- node pool
- iam roles
service
- api, one-line change
- worker
- database
api: one-line change
Plan scope: the entire state
network
own state
- vpc
- subnets
- nat
- dns
cluster
own state
- eks
- node pool
- iam roles
service
own state
- api, one-line change
- worker
- database
api: one-line change
Plan scope: the service stack
Reusable infrastructure components
Modules expose intentional interfaces and can evolve through controlled versions.
Predictable deployment workflows
Validation, planning, approval, and application follow a documented process.
Terraform engineering.
Module design
Create versioned, reusable components with clear inputs, outputs, and responsibilities.
State management
Design backends, locking, access permissions, and state boundaries.
CI/CD automation
Implement infrastructure validation, planning, approval, and controlled application.
Policy and testing
Add checks that address real configuration risks without turning every change into a compliance exercise.
Migration and refactoring
Move manually created infrastructure into code, split oversized stacks, and improve existing configurations incrementally.
Refactor around the changes your team needs to make.
How the work runs
01
Inspect the current code and state
Identify risky dependencies, manual processes, and changes engineers avoid.
02
Design manageable boundaries
Separate shared foundations from infrastructure owned by individual workloads or teams.
03
Migrate incrementally
Refactor a representative part of the infrastructure and verify the resulting plans and state.
04
Automate the workflow
Make infrastructure changes visible, reviewable, and repeatable through CI/CD.
Technologies
Used when they fit the system you already run. Not as a checklist.
Terraform · OpenTofu · Terragrunt · GitHub Actions · GitLab CI · OPA · Checkov
module "network" {
source = "../modules/network"
cidr = "10.4.0.0/16"
}From the notes
Common questions
Should we use Terraform or OpenTofu?
Both can support maintainable infrastructure as code. The choice depends on licensing, compatibility, ecosystem requirements, and your team’s constraints. Switching tools will not resolve poor module boundaries or state design.
Do we need to put every cloud resource into code?
No. Prioritize resources that are important, change frequently, or create meaningful operational risk. Importing everything before fixing the underlying workflow can create unnecessary work.
Can you improve an existing Terraform codebase?
Yes. Most engagements can begin with the repositories, modules, and state you already have. A complete rewrite is rarely the first step.
Will your team need Opcotech to apply changes afterward?
No. The goal is a documented workflow with clear ownership and permissions that your engineers can use independently.
Related
- Cloud infrastructure
Cloud environments need clear boundaries, identity, networking, and operational defaults. We design and improve AWS and GCP foundations that teams can extend without recreating everything for each environment.
- Platform engineering
Developers should not need to understand the entire infrastructure stack to ship a service. We create supported development and deployment workflows, reusable templates, and self-service capabilities that reduce dependence on a handful of infrastructure specialists.
- DevOps & CI/CD
Releasing software should not require undocumented procedures or fragile pipelines. We improve builds, tests, deployment automation, GitOps, and release workflows so changes move through a clear and repeatable process.
- Cloud cost optimization
Cloud spending needs context before it can be controlled. We identify waste, investigate costly architecture decisions, improve cost allocation, and help engineering teams manage infrastructure spending without relying on arbitrary savings targets.
Platform assessment
Know what needs fixing before committing to a rebuild.
Our Platform & DevOps Assessment examines the infrastructure, delivery process, operational risks, and cloud costs you already have. You receive prioritized findings and a practical 90-day roadmap, including what to fix first, what can wait, and what should be left alone.