Start a project
Menu
ServicesAll servicesCybersecurityCloud EngineeringApplication ServicesEnterprise PlatformsData & AnalyticsAI & Machine LearningInternet of ThingsMobilize Talent
PlatformsAll platformsIdentity and accessPrivileged access and secretsERP, HCM and financeCRM, ITSM and automationHealthcareInsurance and bankingData and integrationCloud and AIIndustrial, utilities and mainframeSkills matrix
Case studiesAll case studiesIdentity and accessPrivileged accessSecurity operationsCloud and infrastructureApplicationsERP and HCMCRM, ITSM and automationIndustry platformsData and analyticsAI and agents
IndustriesAll industriesEnergy, oil & gasHealthcare payersBanking & financial servicesInsurancePublic sectorManufacturingLocations
InsightsField notesLearning tracks
CompanyAbout CohashPortfolioSkills matrixCareersTrust and securityContact
Start a project
infrastructure as code

Terraform code someone can change on a Friday afternoon without holding their breath.

We write and refactor Terraform for AWS, Azure, Google Cloud and SaaS providers. When state has grown messy we split it, sort out the workspaces and keep versions current. We'll set up HCP Terraform, or whichever runner you'd rather use.

Talk to a Terraform engineerWhat changed recently
platform dossierTerraformInfrastructure as code
Vendor
IBM (HashiCorp acquisition closed 27 Feb 2025)
Current release
Terraform 1.17.0 (21 Oct 2026)
1.16 patch line
1.16.7 (22 Oct 2026), built with Go 1.26.10
License
Business Source License since Aug 2023
release watch
  • Terraform 1.16.722 Oct 2026
  • Terraform 1.17.021 Oct 2026
connects with
in short·15-second read

Cohash builds and maintains Terraform for cloud and platform teams: reusable modules, state splits and repairs, pipelines with policy checks, and providers for AWS, Azure, Google Cloud, Snowflake and Databricks.

We plan upgrades to Terraform 1.17 and help teams weigh HCP Terraform, Terraform Enterprise and OpenTofu now that Terraform is an IBM product under the Business Source License.

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.
  • Pipelines still sign in to the cloud with long-lived keys kept as CI secrets. Anyone who can read those secrets can use the keys.
terms on this page driftdefinitionSlow change in what an agent can reach after go-live: new scopes, new tools, wider policies. Each change is small and none of them gets reviewed.explained in a field note →Business Source LicensedefinitionThe licence HashiCorp moved Terraform and Vault to. Internal use is free, but offering the software as a competing paid service isn't. Each version becomes MPL 2.0 after four years.explained in a field note →
Ask an engineer facts checked 2026-10-26
how it runs
  1. 01Code and state review
  2. 02State split and drift repair
  3. 03Pipelines, policy and credentials
  4. 04Upgrades in lower environments
  5. 05Platform decision and handover
you keep
  • Versioned modules in a registry, each with a usage example, so teams stop writing their own
  • State split plan using moved, removed and import blocks, applied so nothing has to be rebuilt
  • Pipeline templates: plan runs on every pull request, apply only runs on merge
+ 3 more documents
who does it
Terraform platform engineerTerraform module developerHCP Terraform and Terraform Enterprise admin Terraform Associate (004) Terraform Infrastructure Engineer Professional (002)
platforms
proof
12 case studies on this
background
RENEW BLIND IBM's count only Cluster objectsbilled A namespace per team No exit tested RENEW WITH NUMBERS Your own counts Churn moved toGitOps One identity per app Fork test measured
field note · 19 minTerraform and Vault under IBM: what the bill depends on, and when OpenTofu or OpenBao makes sense
terraform · release timeline
  1. 27 Feb 2025 IBM completes HashiCorp acquisition Terraform, Vault and the rest of the HashiCorp portfolio became part of IBM. Security bulletins still go out as HCSEC posts on HashiCorp's own forum, so that's still the place to watch.
  2. 31 Mar 2026 HCP Terraform legacy Free plan retired The legacy Free plan reached end of life on 31 March 2026. Organizations still on it were moved to the enhanced Free tier automatically, so check which limits now apply to yours.
  3. 6 Jul 2026 HCSEC-2026-17: Terraform Enterprise A user who can publish a registry module from VCS could pull files from outside the repository into the module and download them, including configuration and secrets the ingestion process can read (CVE-2026-14468). It affects v202506-1, v202507-1 and 1.0.0 through 2.0.3, and 2.0.4 and 1.2.4 fix it. Until you upgrade, take module publishing rights away from untrusted users.
  4. 28 Jul 2026 HCSEC-2026-23: Terraform MCP Server Three CVEs hit terraform-mcp-server 0.2.1 up to and including 1.0.0 in streamable-HTTP mode. One lets an unauthenticated client get the server's bearer token sent to an endpoint the attacker controls. Upgrade to 1.1.0 or later. Servers that only ran in stdio mode weren't affected.
  5. 26 Aug 2026 Terraform 1.16 Import blocks now work inside modules, and terraform_data has a store block for ephemeral and sensitive values. Action triggers get on_failure modes too. Read the provisioner note before you upgrade, because bastion_host_key is now actually applied and a wrong key will start to matter.
  6. 14 Oct 2026 Terraform 1.16.6 Fixes an HTTP/2 resource exhaustion issue, CVE-2026-78669. HashiCorp says exploiting it would take a compromised provider or module registry, which sits outside Terraform core's security guarantees. Teams staying on 1.16 should go straight to 1.16.7, the latest 1.16 patch.
  7. 21 Oct 2026 Terraform 1.17.0 Provider requirements can now take variables and locals. Plans get a -minimal-refresh option that only refreshes resources with proposed changes, so drift elsewhere won't show up in that plan. Terraform Policy is now GA in the CLI, and -policies no longer needs an experimental build. It uses the same Go 1.26.10 toolchain as 1.16.7.
  8. 22 Oct 2026 Terraform 1.16.7 Built with Go 1.26.10, which no longer trusts certificates issued through a set of compromised eMudhra intermediate CAs (CVE-2026-111943). If a private registry or proxy you use chains up through one of them, Terraform's connections to it will start failing, so check the chain before you roll this out.
  9. today · Nov 09, 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.

  1. 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.
    • Pipelines still sign in to the cloud with long-lived keys kept as CI secrets. Anyone who can read those secrets can use the keys.
  2. 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
  3. 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
  4. chapter 04 · where you end up

    What changes

    • Each team owns a small state and gets its plans back quickly.
    • Because someone actually tested the code, the steering group knows what OpenTofu or a commercial agreement would mean for it.
    • Versioned modules in a registry, each with a usage example, so teams stop writing their own
    • State split plan using moved, removed and import blocks, applied so nothing has to be rebuilt
what we do

Our Terraform work

5 kinds of Terraform work, each run by engineers who have done it on live tenants.

  1. Modules with clear inputs and outputs, versioned in a registry, and existing copy-pasted code refactored with moved and import blocks instead of rebuilds.

  2. Oversized state files split, drift found and reconciled, and remote state locked down so only pipelines can write to it.

  3. 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.

  4. Terraform and provider upgrades tested in lower environments, with deprecation warnings fixed before they turn into errors.

  5. 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.

talk to an engineer about this →
capability 02 / 05in production

State and workspace clean-up

Oversized state files split, drift found and reconciled, and remote state locked down so only pipelines can write to it.

talk to an engineer about this →
capability 03 / 05in production

Pipelines and policy checks

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.

talk to an engineer about this →
capability 04 / 05in production

Version and provider upgrades

Terraform and provider upgrades tested in lower environments, with deprecation warnings fixed before they turn into errors.

talk to an engineer about this →
capability 05 / 05in production

Platform choice and migration

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.

talk to an engineer about this →
typical situations

Terraform situations we walk into

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
  1. 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.

  2. 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.

  3. Afterwhere you end up

    Each team owns a small state and gets its plans back quickly. An app repo can't touch the VPC by accident any more, and nobody applies without a reviewed plan.

case file 02

Legal flagged the BSL, and the platform team owes them an answer before steering meets

composite · not a client story
  1. Beforethe situation

    The company ships customers a developer platform that wraps Terraform, and legal flagged the Business Source License during a product review. Now the platform team has to lay out the options before the next steering meeting.

  2. 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.

  3. Afterwhere you end up

    Because someone actually tested the code, the steering group knows what OpenTofu or a commercial agreement would mean for it. Legal has the technical facts it asked for.

case studies

Terraform case studies

All case studies
modernization Cloud and infrastructure

Hand-built cloud to Terraform or OpenTofu

Bringing console-built AWS, Azure and Google Cloud resources under Terraform or OpenTofu with import blocks, clean state and pipelines, without rebuilding.

read the case study
implementation Cloud and infrastructure

Cloud landing zone and account vending

AWS Control Tower with Account Factory for Terraform, or Azure landing zones on Azure Verified Modules, built as code with guardrails, logging and vending.

read the case study
upgrade Data and analytics

Apache Airflow 2 to Airflow 3

Upgrading self-managed Apache Airflow 2, now past end of life, to Airflow 3, and fixing removed features, auth and scheduling changes before DAGs move.

read the case study
migration Cloud and infrastructure

Data center exit to AWS or Azure

Leaving a colocation or owned data center for AWS or Azure in planned waves, with dependencies mapped, licences checked and every server given an owner.

read the case study
modernization Privileged access

Secrets in code, pipelines and config files to HashiCorp Vault

We track down passwords, API keys and tokens in repositories, CI variables and config files and move them into HashiCorp Vault, with short-lived credentials.

read the case study
migration Data and analytics

Unity Catalog vs Hive metastore on Databricks, and how to move

We move Databricks workspaces off the Hive metastore, DBFS mounts and table ACLs and onto Unity Catalog, ahead of new workspaces dropping legacy features.

read the case study
approach

How a Terraform engagement runs

We don't start a step until the last one has produced something you can check.

  1. step 01

    Code and state review

    We read the modules, root configurations and state layout first. Then we check provider versions and the pipeline setup, and rank everything we find by risk.

  2. step 02

    State split and drift repair

    Large state files get split with moved and import blocks, so nothing is rebuilt. After that we reconcile drift until a plan shows only the changes someone meant to make.

  3. 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.

  4. 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.

  5. 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.

architecture

Nothing reaches your cloud accounts until a plan and a policy check have run on the PR

Changes to versioned modules and environment configs start life in Git. HCP Terraform or another runner plans each pull request and checks it against policy. On merge it applies, using short-lived credentials and locked remote state.

Nothing reaches your cloud accounts until a plan and a policy check have run on the PR Changes to versioned modules and environment configs start life in Git. HCP Terraform or another runner plans each pull request and checks it against policy. On merge it applies, using short-lived credentials and locked remote state. 01 · CODE 02 · RUNS 03 · STATE AND SECRETS 04 · TARGET ACCOUNTS module source plan on pull request plan · apply read · lock · write short-lived creds apply apply apply apply Module registry versioned modules Git repository root configs perenvironment HCP Terraform plan · policy check· apply OpenTofu or CI runner alternative run path Remote state locked · encrypted HashiCorp Vault dynamic cloudcredentials Cloud accounts AWS · Azure · Google Cloud Snowflake roles · warehouses Databricks workspaces · UnityCatalog Okta groups · appassignments © Cohash · cohash.com
01 · CODE02 · RUNS03 · STATE AND SECRETS04 · TARGET ACCOUNTS Module registry: versioned modules Module registry versioned modules Git repository: root configs per environment Git repository root configs perenvironment HCP Terraform: plan · policy check · apply HCP Terraform plan · policycheck · apply OpenTofu or CI runner: alternative run path OpenTofu or CIrunner alternative runpath Remote state: locked · encrypted Remote state locked · encrypted HashiCorp Vault: dynamic cloud credentials HashiCorp Vault dynamic cloudcredentials Cloud accounts: AWS · Azure · Google Cloud Cloud accounts AWS · Azure ·Google Cloud Snowflake: roles · warehouses Snowflake roles · warehouses Databricks: workspaces · Unity Catalog Databricks workspaces · UnityCatalog Okta: groups · app assignments Okta groups · appassignments plan on pull request plan · apply read · lock · write short-lived creds apply apply apply apply © Cohash · cohash.com
use cases

Typical Terraform projects

The work teams usually bring us, and the platforms Terraform has to talk to while we do it.

  1. TER-01 A single state file holds hundreds of resources and every plan takes minutes common request
  2. TER-02 Engineers apply changes from laptops and drift is everywhere common request
  3. TER-03 Legal keeps asking about the BSL. Nobody can say yet whether OpenTofu would work for you. common request
  4. TER-04 You're several Terraform or provider versions behind and afraid to upgrade common request
  5. TER-05 Each team writes its own VPC or network module common request
Terraform · connected platforms
HashiCorp VaultSnowflakeDatabricksMicrosoft Entra IDOkta
you keep

What a Terraform engagement leaves behind

These are working documents, written against your configuration, so your team can run them without us.

  • code01

    Versioned modules in a registry, each with a usage example, so teams stop writing their own

    yours to keep
  • plan02

    State split plan using moved, removed and import blocks, applied so nothing has to be rebuilt

    yours to keep
  • plan03

    Pipeline templates: plan runs on every pull request, apply only runs on merge

    yours to keep
  • tests04

    Policy-as-code rules, each with test cases, so a bad rule fails in CI and not in a release

    yours to keep
  • document05

    A per-environment log of provider upgrades, so you can see which deprecation fixes went where

    yours to keep
  • code06

    A side-by-side of HCP Terraform, Terraform Enterprise and OpenTofu against the features you actually use

    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.

Onsite

Engineers at your sites in the US

Nearshore

Overlapping hours with US teams

Offshore

Overnight progress on your backlog

All time zones

Coverage handed over across time zones

24-hour coverage · US Central time
OnsiteUS business hours
Nearshoreoverlapping US hours
Offshoreovernight progress
Combinedhandover, not hand-off
certifications our engineers hold
  • Terraform Associate (004)HashiCorp
  • Terraform Infrastructure Engineer Professional (002)HashiCorp
roles we staff
  • Terraform platform engineer
  • Terraform module developer
  • HCP Terraform and Terraform Enterprise admin
  • Cloud infrastructure engineer (AWS, Azure, GCP)
  • Policy as code engineer (Sentinel, OPA)
  • Infrastructure as code migration engineer
due diligence · terraform

Questions to ask any partner, including us.

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.

  1. Q1

    How do you split our state without Terraform destroying and recreating anything?

    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.

  2. 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.

  3. Q3

    What will your policy checks block, and how would we test one before it's switched on?

    Policy as code catches public buckets and broad IAM before apply. Untested policies break pipelines on false positives, and teams start bypassing them.

  4. Q4

    Where do provider upgrades get tested before they go anywhere near production?

    Providers break more often than the core binary. Upgrading in lower environments and comparing plans catches changed defaults before they touch production.

  5. 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. HashiCorp moved Terraform to the Business Source License in August 2023, and it restricts offering Terraform in a product that competes with HashiCorp. Whether that touches you depends on what you build and sell. Your legal team should read the license itself, and we'll walk them through the technical options.

02Should we switch to OpenTofu?

Maybe, if license terms or dependence on one vendor worry you. OpenTofu is an open-source fork of Terraform under Linux Foundation stewardship, and most configurations move over with small changes. Newer Terraform-only features and HCP Terraform integrations don't come along. We look at your code and tooling before we recommend either.

03We're on 1.16. What changed in Terraform 1.17, and is it worth upgrading yet?

1.17.0 came out on 21 October 2026. Provider requirements can take variables and locals, plans get a -minimal-refresh option, and Terraform Policy runs from the CLI without an experimental build. Test it in a lower environment first. Don't let a minimal-refresh plan be the last check before production, because it only refreshes the resources you're changing and drift on the rest goes unseen.

04How hard is it to upgrade Terraform versions?

Within 1.x it's usually low risk, and providers cause more trouble than the core binary. For 1.17.0 and 1.16.7, check that nothing Terraform talks to presents a certificate from the eMudhra intermediates that Go 1.26.10 no longer trusts. We upgrade in a lower environment, fix deprecation warnings, and compare plans before touching production.

05Do the recent HashiCorp security bulletins for Terraform Enterprise and the Terraform MCP Server affect us?

If you run either one yourself, check your version. HCSEC-2026-17 covers Terraform Enterprise v202506-1, v202507-1 and 1.0.0 through 2.0.3, where a user who can publish registry modules could read files the ingestion process can see. 2.0.4 and 1.2.4 fix it. HCSEC-2026-23 covers terraform-mcp-server 0.2.1 through 1.0.0 in streamable-HTTP mode, and 1.1.0 fixes it.

06Do you also manage HashiCorp Vault?

Yes. We often set up Vault and its Terraform provider in the same piece of work, so secrets engines, auth methods and policies end up living in code with everything else.

07Our Terraform was written by someone else. Can you take it over?

Yes. We start by reading the module structure, state layout, provider versions and pipelines, and we run plans to see where the drift is. Then we agree a short list of fixes with you before anyone adds new infrastructure.

services

Related services

Projects on Terraform usually end up touching one of these, so they're worth a look.

you are hereTerraform
fact-checked Checked against vendor and official documentation last checked 2026-10-26 content fingerprint 78c61393
  1. 01Book a 30-minute working sessionsenior engineer
  2. 02Talk to an engineer about your setupreply within 24 hours
  3. 03See how similar projects wentcase studies
Reviewed by the Cohash team Terraform is a trademark of its owner, used here to identify the platform. how we handle facts and data →
next step

Tell us what you're running. We'll tell you what we'd do first.

A 30-minute working session with a senior engineer. No slides.

Book a working session See the case studies
useful to bring
  • The platform and the version you're on
  • Where you need to get to, and by when
  • What's custom: rules, plugins, integrations
  • Any audit finding or deadline driving it