Every change,
seen before it’s made
We keep your infrastructure in Terraform code, with every change planned and read before it runs, and the state kept where only your pipeline can change it, so you see what a change will do before it does it.
Thanks, we’ll be in touch soon.
{{ heroStatus }}
You’re in good company
A few of the companies we’ve worked with.
When the plan holds changes nobody asked for
Terraform is HashiCorp’s tool for infrastructure as code: the networks, servers, databases and access a system runs on, described in configuration files that can be reviewed and versioned like any other code. Each thing those files describe is a resource, and providers, plugins released on their own schedules, let it work with each cloud and service.
It keeps a record of what it manages, called its state. Before each change, it checks what’s running, compares it with the code and with that record, and shows a plan of what it would create, change or destroy. Nothing changes until someone applies the plan, and it’s carried out.
A plan can hold changes nobody meant. A setting changed outside the code shows up as a change to put it back, and a resource renamed in the code shows up as one to destroy and one to create.
When plans keep surprising people, they tend to stop reading them closely, or stop running them, and the code and what’s running drift further apart. The real work is making every plan one a reviewer can read, and trust.
What we build
Each part of your infrastructure is written in Terraform code, planned in its pull request and read by a person before it’s applied.
New infrastructure, in code from the start
Networks, servers, databases and access written as code from the first day, with a plan in every pull request, so each environment can be built again from its code.
What was set up by hand, brought into code
Each part imported with an import block, one part at a time, and its code written until the plan shows no changes.
Modules your teams share
Shared modules, each a set of resources kept and used together, released with versions, and each team pinned to the version it uses until it chooses to move.
Every change planned and read
Plans run in CI on every pull request, read by a person and checked against your policies before anything is applied, and applied from the pipeline only.
State where only the pipeline can change it
State kept remote, locked while each change runs and reachable only by the pipeline, with secrets kept out of it where the providers allow.
Code tidied without replacing what runs
Renames and moves recorded in the code with moved blocks, and parts let go of with removed blocks, so the plan shows a move, not a replacement, as the section below shows.
Drift found and settled
Plans run on a schedule to show what changed outside the code, and each change then either written into the code or put back.
Versions kept current
Terraform and each provider pinned to a version and moved up on purpose, a step at a time, each step’s plan read on a copy first.
AI where it helps
Changes drafted by AI coding assistants, to your infrastructure code or the modules it uses, planned, tested and reviewed by a person before they’re applied.
- The cloud it all runs on, built on AWS:Software development
- On the Microsoft Azure cloud:Software development
- With Google Cloud services:Software development
- The clusters your services run on, set up in code:Engineering
- The pipelines and operations around your infrastructure:Cloud, DevOps & Security
- Internal platforms and the templates your teams share:Platform Engineering
- A security review of what you run:Application Security
- Engineers in your own team:Engineers for your team
Tidy the code, keep what runs
Terraform knows each resource by its address: where it sits in the code, and its name there. By default, it reads a changed address as an instruction to destroy what’s there and create something new at the new address.
So renaming a resource, or moving it into a module, plans a replacement. A moved block tells Terraform the old address and the new one are the same thing: the plan shows a move, and nothing is destroyed.
Taking a resource out of the code plans to destroy it. A removed block, with destroy set to false, tells Terraform to stop managing it and leave it running.
So we read every plan before it’s applied, and any replacement or destroy goes to a person first.
Choose an edit, add the line that says so, and read the plan under the file.
Seed orders at Wrenfield Nursery
The file
A database for seed orders
Named: {{ plName }}
In: {{ plWhere }}
{{ plLineText }}
{{ plPlan }}
{{ plSay }}
Pinned, then moved up on purpose
Within its current major version, Terraform comes with HashiCorp’s compatibility promises: code written for one release is meant to keep planning and applying in the later ones without changes, and the commands most automation relies on stay as they are.
Providers are separate plugins, released on their own schedules, and those promises don’t cover them: a provider’s new release can ask for changes to the parts of the code it reads. The dependency lock file records the provider versions a configuration uses, so every run uses the same ones until someone chooses to move up.
Names and tools change too. HashiCorp’s hosted service for runs and state is now HCP Terraform, and HashiCorp has deprecated CDK for Terraform and no longer maintains it.
So we pin every version and move up on purpose, a step at a time, each step tried on a copy first and its plan read before it goes live.
Start with the plan you’d run today
The review covers the Terraform and provider versions in use, and whether the lock file that records them is in the repository; where state lives, who can read and change it, whether it’s locked while a change runs, and whether it holds secrets; how changes are applied today, from laptops, from CI or from HCP Terraform; who reads each plan, and the policy checks it passes; what has changed outside the code since the last change; modules, where they come from and how they’re pinned; what was set up by hand and isn’t in the code yet; how environments are laid out, and what each one shares; tests, and what they check; and any tool its maker has retired, such as CDK for Terraform.
The first step is one of these, each tried on a copy first: state moved to a remote backend with locking, and changes applied only from CI; plans in every pull request, with a person reading each one; one shared module pinned to a version wherever a team uses it; a plan on a schedule that lists what changed outside the code, each change then settled one way or the other; or the next provider upgrade, its plan read before it goes live.
What you receive is a written review and a proposal for that first step.
Questions worth asking
We only have a few servers. Is infrastructure as code worth it?
Often, once more than one person changes them or there’s more than one environment. For a handful of parts that rarely change, a simpler way can be enough, and we’ll say so.
Can you work with code someone else wrote?
Yes. The review above comes first; then we change a part at a time, and read each plan before it’s applied.
What does the license change mean for us?
Since HashiCorp’s announcement of August 10, 2023, new Terraform releases are under the Business Source License 1.1. HashiCorp’s licensing FAQ says the license puts no restrictions on internal use, such as running Terraform in CI to provision your own infrastructure, and that helping a customer with their own use is permitted. What it rules out is hosting or embedding Terraform in an offering that competes with HashiCorp’s paid versions. This isn’t legal advice. If you offer Terraform to others as part of something you sell, ask your counsel.
A hosted service for our runs, or a pipeline of our own?
We work with either. HCP Terraform, HashiCorp’s hosted service, runs plans and keeps state for you; a pipeline of your own does the same with your own tools. We set up whichever fits how your team works.
How do you keep secrets out of state?
Where the providers support them, with ephemeral values and write-only arguments, which Terraform keeps out of state and plan files. For everything else, the state is kept in a backend that encrypts it at rest, and only the pipeline can reach it.
What happens if two people apply at once?
Where the backend supports locking, the state is locked for every operation that could write to it, and a second change doesn’t go ahead while the first holds the lock. HCP Terraform runs each workspace’s changes in order, and in a pipeline of our own we set the second to wait its turn.
Our infrastructure is written with a retired kit. What now?
If it’s CDK for Terraform: HashiCorp deprecated it on December 10, 2025, and it gets no further updates, though existing projects can still be used. It can write a project out as plain configuration files, and HashiCorp recommends moving to those. We write those out, tidy them, and check the plan shows no changes before the old project is retired.
What does it cost to work with you?
That depends on what you’d like changed first. Before any work starts, you get a written proposal with the scope, the price or rate, and how you pay.
Can AI assistants help with our infrastructure code?
Yes, as one tool among others here. Every change an assistant drafts is planned, tested and reviewed by a person before it’s applied.
Can we hire engineers for our own team?
Yes. Within 48 hours of your request, we introduce engineers who work with Terraform, in your time zone, and you meet them before choosing who joins.
Terraform and HCP Terraform are trademarks of HashiCorp. AWS is a trademark of Amazon.com, Inc. or its affiliates, Microsoft and Azure are trademarks of the Microsoft group of companies, and Google Cloud is a trademark of Google LLC. Webair is independent of HashiCorp, and isn’t sponsored by, endorsed by or affiliated with it.
Let’s build it better
Tell us how changes reach your infrastructure today and what your last plan showed, and we’ll suggest where to begin, in a short call.
Thanks, we’ll be in touch soon.
{{ ctaStatus }}