Remote state and locking
State stored in a versioned remote backend with locking enabled, so two applies never race each other and a lost laptop does not mean a lost estate.
Infrastructure & Cloud
Infrastructure as Code
Your cloud estate written as code, reviewed in pull requests, rebuildable from an empty account.
The work
What this actually does
Most infrastructure problems are state problems. Two environments drift apart because someone made a console change nobody recorded, and the module that was supposed to describe both of them quietly stopped being true. We start by mapping what actually exists, import it where it can be imported, and get the state files somewhere your team can trust.
Module layout matters more than tool choice. We split the estate along the lines your team already reasons about — accounts, networks, shared services — then put policy checks on the pull request so a plan that opens port 22 to the world fails review instead of reaching production.
If any of these sound familiar
- Only one engineer understands the Terraform repository and where state lives
- A console change in March breaks the next apply in June
- Nobody reviews infrastructure changes the way they review application code
- Rebuilding a production account is a multi-week archaeology project
Scope
What's included
Every engagement on this page covers the following, sized to your setup rather than delivered as a fixed package. If something here is not relevant to you, it comes off the scope and off the price.
Composable module library
Modules cut along the boundaries your teams actually own, with documented inputs and outputs, so a new environment is a small configuration file rather than a fresh pile of copy-paste.
Drift detection
Scheduled plans compared against real infrastructure, so an out-of-band change is reported the day it happens instead of surfacing halfway through an unrelated deployment three months later.
Policy-checked pull requests
Open Policy Agent or Sentinel rules run against every plan: naming conventions, required tags, allowed regions and blocked public buckets, all enforced before a human approves the change.
Import and migration
We bring existing resources under management in reviewed batches, starting with the ones nobody dares touch, and document the manual steps that remain so they are visible rather than folklore.
Runbook and conventions
A short written standard covering naming, module versioning, plan review and state recovery, plus the commands your team needs during an incident.
What changes
What teams typically see
0Manual console changes
90%Estate under code management
1 PRGate for every change
Handover
What you keep
Everything produced during the engagement is yours: the repositories, the accounts, the documentation. There is no proprietary layer and nothing to unlicense if you take the work in-house.
- Managed code repositories with reviewed module and environment definitions
- Remote state backends configured with locking and access controls
- Policy suite enforced on every infrastructure pull request
- Drift detection schedule with alerting to your team's channel
- Import inventory listing every resource still outside the codebase
Tooling
Tools we use here
A starting point, not a requirement. We work in whatever you already run wherever it does the job.
Terraform
Pulumi
AWS
Microsoft Azure
Google Cloud
GitHub
HashiCorp Vault
How it runs
From first call to handover
The same four steps on every engagement. You see each one before it starts and can stop at any of them.
- 01
Discover what exists
We inventory every account, read-only, and compare it against whatever code and diagrams you already have. The gap between those two is the real starting point.
- 02
Design module boundaries
A short design session with your engineers decides how the estate gets split and who owns each module, because a layout nobody understands gets abandoned within a quarter.
- 03
Convert in reviewable batches
Resources move under management a batch at a time, each as its own pull request, so the estate stays healthy throughout and nothing depends on one enormous cutover weekend.
- 04
Hand over with guardrails
We walk your team through plan review, state recovery and adding a module, then stay available for the first few real changes they ship without us.
Questions
Asked before we start
Do we need to rewrite everything into Terraform?
No. Rewriting a working estate is rarely worth the risk. We import what is safe to import, leave the rest alone, and only convert a component when there is a clear reason such as frequent change or an upcoming rebuild.
What if we have already drifted badly from our code?
That is the normal state, not an exception. We reconcile drift in reviewed batches, deciding case by case whether the console change should be codified or reverted. Nothing is applied to production until you have reviewed that decision.
Terraform, OpenTofu or Pulumi?
Whichever your team will maintain. Terraform has the widest module ecosystem and hiring pool, OpenTofu matters if licence terms are a concern, and Pulumi suits teams who prefer general-purpose languages. We will recommend one, but the honest answer is that the layout matters more.
Can you work alongside our existing platform team?
Yes, and that is usually the better arrangement. Your engineers review every change and own the modules once they land. We would rather work ourselves out of a job than leave a codebase only we understand.
Infrastructure & Cloud
Often needed alongside this
Infrastructure & Cloud
Cloud Architecture & Migration
Well-architected landing zones and migrations that move workloads without moving your risk profile.
- AWS, Azure and Google Cloud landing zones
- Lift-and-shift, replatform and re-architect paths
- Network, IAM and multi-account structure design
Security & Compliance
Policy as Code
Guardrails expressed as code, enforced before deployment — not a wiki page nobody reads.
- Open Policy Agent and Kyverno policies
- Budget, tagging and region restrictions
- Pre-merge plan checks on every pull request
Delivery Automation
GitOps & Release Management
Git becomes the single source of truth for what runs where — with progressive rollouts and instant rollback.
- ArgoCD and Flux continuous delivery
- Blue/green, canary and feature-flag releases
- Environment promotion with approval workflows
Worth a conversation about Infrastructure as Code?
Bring the specific problem. We will tell you honestly whether this is the service that fixes it, and what it would take.