Terraform EU Alternative 2026: HashiCorp IBM Acquisition, CLOUD Act, and Self-Hosted IaC with OpenTofu

Post #3 in the sota.io EU Developer Tools Series

In June 2024, IBM completed its $6.4 billion acquisition of HashiCorp. For European developers and DevOps teams relying on Terraform Cloud (now HCP Terraform) to manage infrastructure state, that acquisition changed the legal landscape fundamentally. IBM Corporation is a New York–headquartered, NYSE-listed Delaware C-Corp — a US person fully subject to the CLOUD Act.

Every Terraform state file you store in HCP Terraform is now within the legal jurisdiction of US law enforcement. State files are not just configuration metadata: they contain resource IDs, IP addresses, database endpoints, and often API keys and secrets that were inadvertently left in plaintext. Under the CLOUD Act, IBM can be compelled to disclose that data to US authorities without notifying you or the affected data subjects.

For DevOps teams under GDPR — particularly those running EU-resident customer workloads — this creates a compliance gap that a Data Processing Agreement alone cannot close.

HashiCorp's Corporate History and the IBM CLOUD Act Problem

HashiCorp, Inc. was founded in 2012 and incorporated in Delaware. It went public on Nasdaq (HCP) in December 2021. In January 2024, IBM announced its intent to acquire HashiCorp for $35 per share in an all-cash transaction. The deal closed on 26 June 2024.

IBM Corporation (NYSE: IBM) is headquartered in Armonk, New York and incorporated in New York State. As a US-headquartered, US-listed company, IBM is a "US person" under the CLOUD Act — the Clarifying Lawful Overseas Use of Data Act of 2018.

Under the CLOUD Act, US authorities can compel IBM to produce data stored anywhere in the world — including data stored in HCP Terraform's EU-region infrastructure — without requiring a mutual legal assistance treaty (MLAT) request or notification to the data subject. GDPR Article 46 Standard Contractual Clauses do not override US federal law.

The result: uploading Terraform state to HCP Terraform after June 2024 is uploading it to an IBM system subject to US jurisdiction.

What Terraform State Files Actually Contain

Before assessing the GDPR risk, it helps to understand what Terraform state files actually store:

Resource metadata: every AWS, Azure, GCP, or Hetzner resource you manage — IDs, ARNs, IP addresses, DNS names, region, availability zone, account ID.

Outputs: anything in a output block is stored in state — including database connection strings, API endpoints, load balancer IPs, and TLS certificate ARNs.

Sensitive values: Terraform marks some values as sensitive (sensitive = true), but sensitive values are still stored in state — just not shown in CLI output. The full plaintext value is in the state file.

Dependency graph: the complete dependency tree of your infrastructure — who depends on what, in what order, in which account.

For a GDPR Data Protection Impact Assessment (DPIA), Terraform state files are a concentration risk: a single file can contain the data required to enumerate, access, and exfiltrate an entire customer's infrastructure.

Under GDPR Article 5(1)(f), you must apply appropriate technical and organisational measures to ensure the security of personal data. Storing infrastructure state in a US-jurisdictioned system is difficult to justify in a DPIA for EU workloads.

The BSL License Change and OpenTofu

In August 2023 — before the IBM acquisition — HashiCorp changed Terraform's license from the Mozilla Public License v2 (MPL 2.0) to the Business Source License v1.1 (BSL 1.1). The BSL restricts using Terraform to build products that compete directly with HashiCorp's commercial offerings.

The community response was swift: in September 2023, a group of infrastructure companies (Spacelift, env0, Gruntwork, and others) forked Terraform at the last MPL-licensed commit (v1.5.5) under the name OpenTofu, donated to the Linux Foundation.

OpenTofu is now at v1.8.x and is a drop-in replacement for Terraform. All existing Terraform modules, providers, and state files are compatible. The Linux Foundation holds the trademark; the project is governed under a Technical Steering Committee; the codebase is MIT-licensed.

For European teams, OpenTofu + a self-hosted state backend on EU infrastructure is the complete answer to both the CLOUD Act problem and the BSL licensing uncertainty.

HCP Terraform's Data Residency Reality

HCP Terraform (the managed platform) offers two deployment regions: US and EU. The EU deployment is hosted on AWS eu-central-1 (Frankfurt).

At first glance this looks like a GDPR solution. It is not sufficient for the following reasons:

US parent jurisdiction: AWS eu-central-1 is operated by Amazon Web Services EMEA SARL (Luxembourg), but HCP Terraform is operated by IBM (US parent). The fact that data is stored in a Frankfurt AWS data center does not remove it from IBM's CLOUD Act obligations.

Control plane in the US: HCP Terraform's control plane — the system that processes API calls, executes plan/apply operations, and manages authentication — runs in IBM's US infrastructure. Even if state is at rest in Frankfurt, plan execution traverses US-operated systems.

IBM's internal data transfers: as an IBM subsidiary, HashiCorp's EU operations are subject to IBM's internal data transfer mechanisms. IBM can access EU-stored data from US locations for support, operations, and compliance purposes.

Audit logging: HCP Terraform's audit log events are processed through IBM's global logging infrastructure, which includes US-operated systems.

A Transfer Impact Assessment (TIA) under GDPR Article 46 must assess whether the destination country's surveillance laws undermine the protection offered by SCCs. The US CLOUD Act is a well-documented surveillance mechanism that TIAs must explicitly address — and standard SCCs do not override it.

GDPR Legal Basis Comparison: HCP Terraform vs. Self-Hosted

Self-Hosted Terraform State: Your Options

The Terraform state backend protocol is an open HTTP API. You can replace HCP Terraform's state storage with any of the following, all operable on EU infrastructure:

Option 1: S3-Compatible Backend (Hetzner Object Storage)

Hetzner Object Storage is an S3-compatible service operated by Hetzner Online GmbH (Nuremberg, Germany — a German private company with no US parent). Use the S3 backend:

terraform {
  backend "s3" {
    endpoint                    = "https://fsn1.your-objectstorage.com"
    bucket                      = "terraform-state"
    key                         = "project/terraform.tfstate"
    region                      = "fsn1"
    skip_credentials_validation = true
    skip_requesting_account_id = true
    skip_metadata_api_check     = true
    force_path_style            = true
  }
}

Cost: €0.0054/GB-month for Hetzner Object Storage. Encryption at rest is available. State locking via DynamoDB can be replaced with a Hetzner-hosted Redis or PostgreSQL lock.

Option 2: PostgreSQL Backend

OpenTofu's pg backend stores state in a PostgreSQL database with native row-level locking:

terraform {
  backend "pg" {
    conn_str = "postgres://user:password@db.eu-host.example.com/tfstate"
  }
}

Deploy a managed PostgreSQL instance on Scaleway (Paris, France — Scaleway SAS, French company), Exoscale (Switzerland — no EU parent complications), or Hetzner Managed Databases.

Option 3: HTTP Backend with a Minimal State Server

For teams that want strict access control and audit logging, a lightweight state server (e.g., terrastate or tfstate-backend) can be self-hosted on a EU VPS:

terraform {
  backend "http" {
    address        = "https://tfstate.internal.example.com/state/myproject"
    lock_address   = "https://tfstate.internal.example.com/lock/myproject"
    unlock_address = "https://tfstate.internal.example.com/lock/myproject"
    lock_method    = "PUT"
    unlock_method  = "DELETE"
  }
}

Option 4: GitLab Managed Terraform State

GitLab BV (Netherlands) offers a managed Terraform HTTP state backend built into every project. If you already self-host GitLab or use GitLab.com EU-managed plans, this is zero additional infrastructure:

terraform {
  backend "http" {
    address        = "https://gitlab.example.com/api/v4/projects/12345/terraform/state/myenv"
    lock_address   = "https://gitlab.example.com/api/v4/projects/12345/terraform/state/myenv/lock"
    unlock_address = "https://gitlab.example.com/api/v4/projects/12345/terraform/state/myenv/lock"
    username       = "gitlab-token"
    password       = "glpat-xxxx"
    lock_method    = "POST"
    unlock_method  = "DELETE"
  }
}

GitLab BV is headquartered in the Netherlands. GitLab Inc. (the US parent) does operate globally, so for maximum sovereignty a self-hosted GitLab instance on EU infrastructure is preferred.

OpenTofu: Drop-In Migration from Terraform

Migrating from Terraform to OpenTofu requires one CLI swap and a state migration for teams using HCP Terraform:

Step 1: Install OpenTofu

# On Debian/Ubuntu:
curl --proto '=https' --tlsv1.2 -fsSL https://get.opentofu.org/install-opentofu.sh | sudo bash -s -- --install-method deb

# Verify:
tofu version

Step 2: Initialize with new backend

If you were using a local backend or a non-HCP-Terraform remote backend:

tofu init

All existing .tf files, modules, and providers work without modification. OpenTofu uses the same provider registry protocol as Terraform — you can continue using registry.terraform.io providers or switch to the OpenTofu registry.

Step 3: Migrate state from HCP Terraform

# Pull current state from HCP Terraform:
terraform state pull > terraform.tfstate

# Initialize OpenTofu with your new EU backend (e.g., Hetzner S3):
tofu init -reconfigure

# Push state to new backend:
tofu state push terraform.tfstate

# Verify:
tofu state list

Step 4: Update CI/CD pipelines

Replace terraform binary with tofu in your CI configuration. The CLI interface is identical.

CI/CD: Replacing Terraform Cloud Agents

HCP Terraform's remote execution model (Terraform Cloud Agents) runs plan/apply operations in IBM's infrastructure. For EU sovereignty, replace this with:

Atlantis — open-source Terraform PR automation. Self-host on any EU VM. Atlantis listens for GitHub/GitLab webhook events and runs tofu plan/tofu apply on your own infrastructure. No state leaves your environment.

# atlantis.yaml
version: 3
projects:
  - name: production
    dir: environments/production
    workspace: default
    terraform_version: v1.8.0
    autoplan:
      enabled: true
      when_modified: ["*.tf", "*.tfvars"]

GitLab CI/CD with self-hosted runners — if you already use GitLab on EU infrastructure, the built-in Terraform/OpenTofu CI templates work with local runners. The state is stored in GitLab's managed backend (described above).

Woodpecker CI + OpenTofu — for teams already using Woodpecker CI (a Drone fork, AGPL licensed, no US parent), the OpenTofu CLI steps work identically to Terraform.

EU-Native IaC Alternatives Beyond Terraform

For teams evaluating a broader IaC strategy:

Pulumi — Pulumi Corporation is a Seattle, WA company (US jurisdiction). However, Pulumi is fully open-source (Apache 2.0) and supports self-hosted state backends (S3, Azure Blob, GCP Storage). The Pulumi SaaS platform has the same CLOUD Act issues as HCP Terraform, but the OSS Pulumi CLI + EU state backend avoids them.

Crossplane — a CNCF project (Cloud Native Computing Foundation, a Linux Foundation project). Kubernetes-native IaC: your Kubernetes cluster becomes the control plane. State is stored in Kubernetes etcd. Self-host on EU infrastructure for full sovereignty.

Ansible — Red Hat (IBM) — same IBM CLOUD Act concern as Terraform if using Ansible Automation Platform. Ansible Core (open-source, GPL) with self-hosted AWX (open-source Ansible Tower) avoids the SaaS CLOUD Act problem.

Checkov / KICS — EU-compatible IaC security scanning. Checkov (Prisma Cloud / Palo Alto, US) and KICS (Checkmarx, Israel) have US/non-EU parents. For EU-sovereign IaC scanning: Trivy (Aqua Security, but open-source, can run fully offline) or tfsec (now integrated into Trivy).

The sota.io Perspective

At sota.io, we deploy EU-resident infrastructure exclusively on Hetzner (Germany). Our own infrastructure-as-code uses OpenTofu with state stored in Hetzner Object Storage. We run Atlantis on a dedicated EU VM for PR-based plan/apply workflows.

Our customers deploy their applications on Hetzner EU infrastructure. When they manage their own IaC alongside sota.io-provisioned resources, we recommend OpenTofu + a self-hosted S3-compatible backend — the same setup we use internally.

The IBM acquisition of HashiCorp in June 2024 was the final proof that the managed Terraform Cloud model is incompatible with EU sovereignty requirements. The good news is that OpenTofu is a mature, Linux Foundation–backed, MIT-licensed replacement with an active community and full backward compatibility.

Quick Compliance Checklist

Before your next Terraform state push, verify:

• Is your state backend operated by a non-US entity? (Hetzner ✅, Scaleway ✅, HCP Terraform ❌)
• Is the CLI you're using open-source with no US SaaS dependency? (OpenTofu ✅, Terraform OSS ⚠️ BSL)
• Does your CI/CD execution environment stay within EU jurisdiction? (Atlantis self-hosted ✅, HCP Terraform Agents ❌)
• Have you performed a TIA for any state backend operated by a US parent? (Required for HCP Terraform under GDPR Art. 46)
• Are sensitive outputs encrypted at rest in your state backend? (Use sensitive = true + encrypted bucket)
• Does your state backend access log ship to an EU-operated SIEM? (Required for GDPR Art. 32 audit trail)

Conclusion

The IBM acquisition of HashiCorp means that HCP Terraform — the managed Terraform Cloud platform — is now operated by a US CLOUD Act person. For European teams managing GDPR-regulated infrastructure, this requires either a Transfer Impact Assessment with compensating controls or a migration to a self-hosted, EU-operated state backend.

OpenTofu is the technically mature, license-clean answer: MIT license, Linux Foundation governance, drop-in Terraform compatibility, and no dependency on IBM or any US-headquartered company for state storage or CI/CD execution.

The migration takes less than a day for most teams. The GDPR and CLOUD Act risk reduction is permanent.

This post is part of the sota.io EU Developer Tools Series — infrastructure and tooling evaluated through the lens of GDPR, CLOUD Act, and European data sovereignty.