Terraform code your team can change on a Friday without holding its breath.
We write and refactor Terraform for AWS, Azure, Google Cloud and SaaS providers. We also sort out state and workspaces, set up HCP Terraform or another runner, and keep versions current.
Cohash designs and maintains Terraform for cloud and platform teams.
We build reusable modules, split and repair state, set up pipelines with policy checks, and manage providers for AWS, Azure, Google Cloud, Snowflake and Databricks. Terraform is now an IBM product under the Business Source License, so we also help teams weigh HCP Terraform, Terraform Enterprise and the open-source OpenTofu fork for their situation.
you probably need this if
One state file holds hundreds of resources. Every plan takes several minutes.
Engineers run terraform apply from laptops and drift turns up in every account.
Cloud credentials for pipelines are long-lived keys stored as CI secrets.
terms on this pageDriftdefinitionWhen a live configuration slowly wanders away from what you intended, often through emergency edits nobody tracked.explained in a field note →
27 Feb 2025IBM completes HashiCorp acquisition Terraform, Vault and the rest of the HashiCorp portfolio became part of IBM. source ↗
31 Mar 2026HCP Terraform legacy Free plan retired Reached end of life on 31 March 2026. Remaining organizations moved to the usage-based Free tier. source ↗
26 Aug 2026Terraform 1.16 Released 26 August 2026. Import blocks now work inside modules, terraform_data has a store block for ephemeral and sensitive values, and action triggers get on_failure modes. 1.16.6 is the latest patch as of 14 October 2026. source ↗
today · Oct 22, 2026
the story · terraform estate
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Terraform estate, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · terraform estate3 open
openOne state file holds hundreds of resources. Every plan takes several minutes.
recurringEngineers run terraform apply from laptops and drift turns up in every account.
blockedCloud credentials for pipelines are long-lived keys stored as CI secrets.
exposure
Module design and refactoringState and workspace clean-upPipelines and policy checksVersion and provider upgradesPlatform choice and migration
startrehearsehandover
Code and state review
State split and drift repair
Pipelines, policy and…
Upgrades in lower environments
Platform decision and handover
we are here
ready to hand over
Each team owns a small state, and plans come back fast.
Someone tested it, so the steering group knows what OpenTofu or a commercial agreement…
Module registry with versioned modules and usage examples
State split plan with moved, removed and import blocks. Applied without rebuilds.
chapter 01 · where it hurts
Why teams reach out
One state file holds hundreds of resources. Every plan takes several minutes.
Engineers run terraform apply from laptops and drift turns up in every account.
Cloud credentials for pipelines are long-lived keys stored as CI secrets.
chapter 02 · what we change
How we solve it
Module design and refactoring
State and workspace clean-up
Pipelines and policy checks
Version and provider upgrades
Platform choice and migration
chapter 03 · how it runs
Our approach
Code and state review
State split and drift repair
Pipelines, policy and credentials
Upgrades in lower environments
Platform decision and handover
chapter 04 · where you end up
What changes
Each team owns a small state, and plans come back fast.
Someone tested it, so the steering group knows what OpenTofu or a commercial agreement would mean for the code.
Module registry with versioned modules and usage examples
State split plan with moved, removed and import blocks. Applied without rebuilds.
what we do
Our Terraform work
5 kinds of Terraform work, each run by engineers who have done it on live tenants.
Modules with clear inputs and outputs, versioned in a registry, and existing copy-pasted code refactored with moved and import blocks instead of rebuilds.
Oversized state files split, drift found and reconciled, and remote state locked down so only pipelines can write to it.
Plan on pull request, apply on merge, with policy as code to block public buckets, missing tags or overly broad IAM before they reach a cloud account.
Terraform and provider upgrades tested in lower environments, with deprecation warnings fixed before they turn into errors.
A comparison of HCP Terraform, Terraform Enterprise, OpenTofu and other runners against your license review, budget and features in use, then a migration plan if you change.
capability 01 / 05in production
Module design and refactoring
Modules with clear inputs and outputs, versioned in a registry, and existing copy-pasted code refactored with moved and import blocks instead of rebuilds.
A comparison of HCP Terraform, Terraform Enterprise, OpenTofu and other runners against your license review, budget and features in use, then a migration plan if you change.
We pieced these together from Terraform situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
One state file holding an entire AWS account
composite · not a client story
Beforethe situation
A single Terraform state holds networking, IAM, databases and 40 application stacks for one AWS account. Plans take twenty minutes, a typo in one app can touch the VPC, and engineers run apply from laptops.
What we dothe work
We split state by layer and team with moved and removed blocks, plus import where needed, checking that each plan shows no destroys. Remote state is locked to pipeline roles, and plan on pull request with apply on merge replaces laptop applies.
Afterwhere you end up
Each team owns a small state, and plans come back fast. An app repo can't change the VPC by accident any more, and every apply has a reviewed plan behind it.
case file 02
Legal flagged the BSL, and the platform team owes an answer
composite · not a client story
Beforethe situation
Legal flagged the Business Source License during a product review, because the company ships customers a developer platform that wraps Terraform. The platform team has to explain the options before the next steering meeting.
What we dothe work
We list the Terraform features, providers and HCP Terraform integrations the platform depends on, test the code under OpenTofu in a branch, and write up what changes under each option. Legal gets the technical facts, and the license reading stays with them.
Afterwhere you end up
Someone tested it, so the steering group knows what OpenTofu or a commercial agreement would mean for the code. Legal gets the facts it asked for.
We don't start a step until the last one has produced something you can check.
step 01
Code and state review
We go through modules, root configurations and state layout, check provider versions and the pipeline setup, and rank what we find by risk.
step 02
State split and drift repair
We split large state files with moved and import blocks, so nothing gets rebuilt. Then drift is reconciled until plans show only intended changes.
step 03
Pipelines, policy and credentials
Plans run on pull requests, applies run on merge. In between there are policy checks, and the credentials are short-lived, from Vault or cloud workload identity.
step 04
Upgrades in lower environments
Terraform and provider upgrades go to dev and test first. We fix the deprecation warnings and compare plans before anything reaches production.
step 05
Platform decision and handover
If you're weighing HCP Terraform, Terraform Enterprise or OpenTofu, the useful comparison is against the features you actually use. We do that comparison, then leave module standards and runbooks with your team.
ai on terraform
Where AI fits on Terraform, and where it needs guardrails.
There's an official Terraform MCP server from HashiCorp. It feeds AI assistants current provider, module and Sentinel policy docs from the registry, and it can manage HCP Terraform and Terraform Enterprise workspaces and variables. Coding agents write better HCL with it, but plans and applies still need review and a pipeline.
AI agentasks for data or an action
Scoped identityonly the access it needs
MCP serverthe one door into the platform
Logged, approveda person signs off on writes
Terraformdoes the work
HashiCorp ships an official Terraform MCP server. It runs over stdio or streamable HTTP. Give it a team or user token limited to the workspaces it needs and keep secrets out of any variables it can read. Log its calls. Plan approval and apply belong to your pipeline.
Terraform MCP server for registry docs
Once the server is connected, the assistant looks up provider docs, module inputs and outputs and Sentinel policies before writing HCL, so the code matches current provider versions. In developers' editors we start it with the read-only registry tools only.
Workspace operations in HCP Terraform
That server lists organizations and workspaces too, and it can change variables, tags and variable sets. So it's a write path. We scope its first HCP Terraform team token to non-production workspaces only.
Import and refactor work
Since Terraform 1.16, import blocks can go inside modules. If someone built resources by hand, we have an AI assistant draft both the import blocks and the module code, and an engineer checks that the plan comes back with no changes.
Plan review
Large plans are hard to read. An agent can summarize one and point the reviewer at the deletes, the replacements and the IAM changes. People in the pipeline still approve and apply.
How Terraform changes travel from Git to your cloud and SaaS accounts
Changes to versioned modules and environment configs start in Git. HCP Terraform or another runner plans each pull request and checks it against policy, then applies on merge with short-lived credentials and locked remote state.
These are working documents, written against your configuration, so your team can run them without us.
code01
Module registry with versioned modules and usage examples
yours to keep
plan02
State split plan with moved, removed and import blocks. Applied without rebuilds.
yours to keep
plan03
Pipeline templates that plan on pull request and apply on merge
yours to keep
tests04
Policy-as-code rule set with test cases for each rule
yours to keep
document05
Provider upgrade log with deprecation fixes per environment
yours to keep
code06
Platform comparison of HCP Terraform, Terraform Enterprise and OpenTofu
yours to keep
talent and delivery · terraform
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Put these to anyone bidding on your Terraform work. The ones who've done it answer differently from the ones who've read about it.
Q1
How will you split our state without destroying and recreating resources?
moved, removed and import blocks let resources change address without a rebuild. Every plan in the split should show zero destroys, and someone should check before each apply.
Q2
Which Terraform-only features would we lose by moving to OpenTofu?
Most configurations move over with small changes. Newer Terraform features and HCP Terraform integrations don't, and the list of those in your code is what sets the cost of switching.
Q3
What will your policy checks block, and how do we test a policy?
Policy as code catches public buckets and broad IAM before apply. Untested policies break pipelines on false positives, and teams start bypassing them.
Q4
How will provider upgrades be tested before production?
Providers break more often than the core binary. Upgrading in lower environments and comparing plans catches changed defaults before they touch production.
Q5
Who can run apply against production, and from where?
An apply from a laptop leaves no review trail and needs broad credentials sitting on a personal machine. Pipeline-only applies with short-lived cloud credentials fix both.
01Can we still use Terraform for free under the BSL?
For most internal use, yes. In August 2023 HashiCorp moved Terraform to the Business Source License, which restricts offering it in a product that competes with HashiCorp. Whether that affects you depends on what you build and sell. Have your legal team read the license, and we'll explain the technical options.
02Should we switch to OpenTofu?
Worth a look if license terms or vendor dependence matter. OpenTofu is an open-source fork of Terraform, stewarded by the Linux Foundation. Most configurations move with small changes. The newer Terraform-only features and HCP Terraform integrations don't. We check your code and tooling before recommending either.
03How hard is it to upgrade Terraform versions?
Within 1.x it is usually low risk. Providers cause more trouble than the core binary. We upgrade in a lower environment, fix deprecation warnings, and compare plans before touching production.
04Do you also manage HashiCorp Vault?
Yes. We often set up Vault and its Terraform provider together, so secrets engines, auth methods and policies live in code.
05Can you take over Terraform code someone else wrote?
Yes. We review module structure, state layout, provider versions and pipelines, run plans to find drift, and agree a short list of fixes with you before adding new infrastructure.
services
Related services
Projects on Terraform usually end up touching one of these, so they're worth a look.
