Why EU teams look for a self-hosted HCP Terraform alternative for data residency
For many EU organizations the question starts with where Terraform state, plans and run logs sit. Those files often hold resource identifiers, IP ranges, database endpoints and sometimes secrets, and in a hosted service the organization may not be able to say with certainty where they are stored, who can access them or which jurisdiction governs the provider. HashiCorp's HCP Europe offering addresses part of this, but it is a separate arrangement: EU organizations use portal.cloud.eu.hashicorp or app.eu.terraform.io, must create a new HCP account and organization, cannot connect or migrate existing HCP Terraform organizations, and are billed separately. HCP Europe also omits teams, managing access through HCP groups and roles instead, and leaves out flex billing, the ServiceNow and Kubernetes operator integrations, the tf-migrate CLI and HCP service principals. Teams that depend on those features should treat HCP Europe as a different product to evaluate, not a drop-in move.
That gap is why a self-hosted stack deployed in an EU region or a data center the organization controls is worth evaluating. The stack pairs OpenTofu, which is MPL-2.0 licensed, with Terrakube, which is Apache 2.0 licensed and supports the remote backend and cloud block, so the organization decides where runs, state and the registry live. The transfer question under GDPR Chapter V still applies to any processor that can access personal data from outside the EEA, including support access and cloud storage outside the EEA, so the decision depends on the organization's own transfer assessment. Ask the vendor to confirm in writing where each data category is stored and who can access it, and check how any remaining hosted component is governed.
Before choosing, map which Terraform data would be personal data under your own analysis, such as tags naming individuals or outputs containing contact details, and list which workspaces hold them. Confirm with your legal and data protection teams whether your current arrangement involves a transfer, and whether EU-only deployment changes that conclusion. Then check which of your integrations, such as ServiceNow, Kubernetes operators or service principals, you actually use, since those are the features HCP Europe leaves out.
What EU data residency requires from an IaC platform
An IaC platform holds state files, variables and plans that can contain personal data and secrets, so where it runs and who can reach it matters as much as its features. The cards below set out the legal questions an EU organization has to answer before choosing between HCP Europe and a self-hosted OpenTofu and Terrakube stack. The organization, not the vendor or DeployOpen, must decide its own legal basis for each transfer.
Remote access counts as a transfer
Under GDPR Article 44, every transfer of personal data to a third country must meet the conditions in Chapter V. EDPB Guidelines 05/2021 state that remote access from a third country, even only displaying data on a screen for support, is a transfer, and so is storage in a cloud outside the EEA. Ask any hosted provider where support staff sit, which subprocessors can see state, and where backups are kept. Infringements of these articles carry fines of up to EUR 20 million or 4% of worldwide annual turnover.
Data Privacy Framework status is pending
The Court of Justice invalidated the EU-US Privacy Shield in Case C-311/18 (Schrems II) while keeping standard contractual clauses valid. Commission Implementing Decision (EU) 2023/1795 covers only US organizations on the Data Privacy Framework List, and an appeal against the General Court's September 2025 judgment is pending as Case C-703/25 P. Check whether a provider relies on that decision, whether it also uses standard contractual clauses, and what happens to transfers if the decision is set aside.
Third-country access and CLOUD Act exposure
18 U.S.C. 2713 requires US electronic communication and remote computing service providers to preserve or disclose data in their control, wherever it is stored. GDPR Article 48 says a foreign court or agency order to disclose personal data is enforceable in the EU only if it rests on an international agreement such as a mutual legal assistance treaty. EDPB Recommendations 01/2020 state that where the destination's authority powers go beyond what is necessary, no effective technical supplementary measure is envisioned. Ask providers how they handle such requests and whether they can commit to notifying you.
Keys and state encryption options
OpenTofu can encrypt state and plan files on the client before they reach any backend, using key providers such as AWS KMS, GCP KMS, OpenBao and Azure Vault. Where keys are held in a region or service you control, a provider holding ciphertext has less to disclose. This does not remove the need for a legal basis for the platform itself, and it does not cover variables and logs in a run platform. Confirm which key provider your key custody model supports and who can administer it.
Data Act Article 32 and switching rights
EU Data Act Article 32 requires data processing service providers to take measures against third-country governmental access to non-personal data held in the Union. The Data Act has applied since 12 September 2025 and gives customers the right to switch to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transition. Switching charges are banned from 12 January 2027. Write these rights into the contract and map your exit steps before you need them.
Where HCP Europe meets the need and where it falls short
HCP Europe answers one part of the residency question: an organization that must keep its HCP Terraform control plane in the EU can use it, but only as a separate service. HashiCorp's documentation says EU organizations use portal.cloud.eu.hashicorp or app.eu.terraform.io, must create a new HCP account and organization, cannot be connected to or migrated from existing HCP Terraform organizations, and are billed separately. In practice, this means every workspace, variable, team and VCS connection is rebuilt in the new organization, and the existing global organization stays in place until you cut over. Ask HashiCorp to confirm in writing which regions store run data, state and logs, and whether any of it is processed outside the EU.
The feature gaps matter as much as the location. According to HashiCorp's documentation, HCP Europe organizations do not support teams, so access is managed through HCP groups and roles instead, which requires a new permission model. They also do not offer flex or pay-as-you-go billing, the ServiceNow and Kubernetes operator integrations, the tf-migrate CLI or HCP service principals. Check each of these against your current pipelines, ITSM tooling and automation accounts before you commit, because a missing service principal can break unattended runs on day one.
Hosting location does not by itself answer whether your organization is exposed to third-country access. Under the GDPR, the question is whether a transfer occurs and whether the provider, its parent or its sub-processors can be compelled by a non-EU authority to disclose data, which depends on the provider's legal structure and support access, not only on the data center. Ask HashiCorp, now an IBM company, for its written position on sub-processors, support access from outside the EEA and how it responds to foreign government requests. Record the answers in your transfer impact assessment, and if you need a self-hosted option, see the Terrakube deployment considerations in the sibling pages.
Which open-source options meet EU residency and what each costs you
This table compares OpenTofu with Terrakube and OpenTofu with Atlantis on the controls an EU residency review usually asks about, plus the cost components each path leaves with you. Read the rows as questions to put to each option in your own environment, and treat the gap rows as items to confirm before you commit.
| Requirement or component | OpenTofu plus Terrakube | OpenTofu plus Atlantis |
|---|---|---|
| Where runs and state live | Runs, state and registry data stay in the database and storage you deploy in an EU region or data center you control | Plans run in your CI or Atlantis host, and state sits in an S3, GCS or other backend you choose in the EU |
| Remote backend and cloud block | Yes | Not applicable; state is configured per workspace in backend blocks |
| Private module and provider registry | Yes | No |
| Web UI for workspaces and run history | Yes | Limited to pull request comments and logs |
| SSO and group-based permissions | Dex connects to identity providers such as Azure AD, Cognito, GitHub and SAML, with permissions assigned by group | Depends on your VCS and CI access controls; confirm how approvals and locks are enforced |
| Database for platform data | Any Liquibase-supported database, such as PostgreSQL, MySQL, Oracle or SQL Server | No platform database; state backend is the main data store to secure |
| Install method | Helm chart or Docker Compose; confirm the chart version and sizing for your cluster | Self-managed service on your servers or containers; confirm the deployment pattern your team supports |
| State and plan encryption control | Use OpenTofu state and plan encryption with AWS KMS, GCP KMS or OpenBao keys, and confirm key custody meets your policy | Same OpenTofu encryption options apply, configured in each workspace's backend and provider setup |
| Gap to confirm before committing | Confirm the extensions and VCS connectors you need (GitHub, GitLab, Bitbucket or Azure DevOps) and their EU hosting path | Atlantis cannot use local state, so you must run and back up a remote state backend; plan which region holds it |
Choosing an EU hosting model you control
You run Terrakube and the OpenTofu runners in a cloud account your organization holds, with every resource pinned to an EU region you select. The provider still operates the physical facilities, so the contract and the configuration decide who can reach the data. A region setting alone does not cover backups, logs or support sessions, so each of those needs its own check.
- Keys: Use a customer-managed key in the provider's key service, or OpenTofu state encryption with a supported KMS key provider, so your organization owns the key lifecycle. Confirm the key material stays in the EU region.
- Backups and logs: Point backup and log destinations at EU-located storage and review cross-region replication settings.
- Access: Limit console and API access to named identities in your organization, and restrict or disable the provider's own support access where the contract allows.
- Third-country access: Ask the provider in writing how it responds to foreign government orders and whether it commits to challenging them. Under 18 U.S.C. 2713, a US provider's preservation and disclosure duties can reach data outside the United States.
- Support locations: Obtain the sub-processor list and the countries from which support staff work.
Before signing, check that remote access from outside the EEA is contractually excluded, since EDPB Guidelines 05/2021 treat even on-screen display of data from a third country as a transfer.
You own or lease hardware in an EU facility run by a colocation or private data center operator, and your own staff run the Terrakube and OpenTofu stack. Keys, backups, logs and access sit with your team, which removes dependence on a hyperscaler's support model. The facility operator still controls physical access, and remote hands and hardware maintenance become support channels that need rules.
- Keys: Hold keys in an on-premises hardware security module or a self-run OpenBao instance, and keep unseal material under your control.
- Backups: Store copies in a second EU facility under a separate contract, encrypted before they leave your racks.
- Logs: Forward logs to a SIEM you operate inside the EU, with retention managed in your own storage.
- Physical and remote access: Require escorted visits, logged sessions and approval before any vendor touches a management network. Screen sharing from a third country for support is a transfer under the EDPB guidance.
- Operator contract: Require the facility operator and hardware vendors to disclose government access requests and to provide no support from outside the EEA unless you approve it.
Ask the operator to name every location from which staff can reach the racks, the management network or the hypervisor console.
The Terrakube control plane, OpenTofu binaries, provider mirrors and module sources run on a network with no route to the internet or to external support. Software moves in through a controlled transfer process. This narrows third-country access sharply, but it moves work to your team: patching, mirroring providers and modules, and evidencing the boundary.
- Keys: Generate and store keys inside the enclosure, with dual control for key ceremonies and a documented rotation schedule.
- Backups: Keep backups on media that stay inside the enclosure, and run restore tests on a schedule your team sets.
- Mirrors: Host provider and module mirrors internally, since runners cannot reach public registries. List the sources each runner needs before cutover.
- Updates: Verify checksums and signatures for OpenTofu and Terrakube artifacts before import, and confirm which artifacts the projects publish for offline use.
- Vendor sessions: Bar remote vendor access unless an approved escort and recorded session are in place, because any such session brings data exposure outside the enclosure.
Confirm with your security team how the air gap is tested and whether an offline transfer procedure is written into the operating runbook.
How to deploy OpenTofu and Terrakube inside an EU boundary
This sequence moves HCP Terraform state, runs and access into an EU hosting location you control, with each step closed by a check your team can repeat.
Map data flows and classify each one
Your platform lead and privacy contact list every place Terraform data moves: state files, saved plan files, run logs, variable values, module sources and the VCS tokens Terrakube uses to fetch code. For each flow, record where it is stored today, which systems read it and whether it contains personal data or secrets. Confirm with your data protection officer which flows would be transfers if any copy leaves the EEA, including support access from outside it. The step is done when a signed data flow register exists and every flow has a named storage location.
Choose the EU hosting location and key management
Select the cloud account, region or data center where Terrakube, its database and the state backend will run, and confirm that backups, logs and monitoring stay in the same boundary. Decide who holds the encryption keys. If you use a cloud KMS, confirm with the provider where key material is generated and who can request it. Ask the vendor or your provider to document the legal exposure of any third-country parent company, because EDPB guidance treats some third-country legal reach as a risk even when data stays in the EU. The step is done when hosting, backup and key decisions are written down and approved.
Install Terrakube with Helm or Docker Compose
Your platform team deploys Terrakube into the chosen environment using the Helm chart for Kubernetes or Docker Compose for a single host, following the installation notes in the Terrakube README. Test the release first on a disposable cluster with minikube, which the same README documents, so that configuration mistakes surface before production. Pin the chart or image version and record the Terrakube release you deployed. The step is done when the API and UI respond inside the EU network and a test organization and workspace can be created.
Connect the identity provider through Dex
Configure Dex with your identity provider, such as Azure Active Directory, Amazon Cognito, GitHub or a SAML source, so that users sign in with corporate accounts. Map identity provider groups to Terrakube groups and assign permissions on workspaces, modules and VCS connections by group rather than by individual user. Remove any local or shared administrator accounts created during testing. The step is done when a user from each target group can sign in, sees only the workspaces their group owns, and a user outside the groups is denied.
Configure the database and backups in the EU
Provision a relational database that Liquibase supports, such as PostgreSQL, and point Terrakube at it. Confirm with your database administrator that encryption at rest, network restrictions and automated backups are enabled, and that backup copies and restore points stay inside the same EU boundary. Run a restore test into a separate instance and confirm that workspaces, runs and permissions come back. The step is done when a restore has been tested and the result is recorded with the date and the person who ran it.
Enable OpenTofu state and plan encryption
Install OpenTofu at the version your team has validated, then configure state and plan encryption with a key provider that your EU key management decision approved, such as AWS KMS, GCP KMS or OpenBao, following the OpenTofu encryption documentation. Store the key configuration in your secrets process rather than in committed code. Confirm that the remote backend stores only ciphertext by reading a state object directly from storage. The step is done when an encrypted test state can be written, read back by the CLI, and shows no readable resource attributes in storage.
Migrate state through the state versions API
For each HCP Terraform workspace, download the current state through the state versions API, using the JSON state download URL for states created by Terraform 1.3 or later, and store the file in the EU state backend. Before you move anything, review the OpenTofu migration guide: configurations that use the terraform_remote_state data source need additional care, because consumers that read the old organization's outputs will break when the source changes. Plan the cut-over for shared states together and update every reader at the same time. The step is done when each migrated state matches the source serial and resource count, and the list of downstream readers is closed.
Switch the cloud block or remote backend
Update each configuration to use the cloud block, which needs Terraform v1.1 or later, or the remote backend for earlier versions, pointing at the Terrakube API hostname. Run terraform login or the OpenTofu equivalent against that hostname, then re-create workspace variables, VCS links and team permissions in Terrakube, since these do not move with state. Set the CLI to OpenTofu where your plan calls for it. The step is done when each configuration initializes against Terrakube without changing the state it reads.
Verify with a small change and a rollback check
Make a small, reversible change in a non-production workspace, such as adding a tag to one resource, and run it through a plan and apply in Terrakube. Confirm that the plan shows only that change, that the state update is encrypted in storage, and that logs contain no secrets. Then test the rollback path that OpenTofu's migration overview describes as safe and reversible, and confirm that HCP Terraform state is retained until the team signs off. The step is done when the change applies cleanly, the rollback has been exercised and the sign-off is recorded.
Questions EU buyers ask before a self-hosted migration
What drives the total cost of a self-hosted OpenTofu and Terrakube setup?
The cost is made up of several components, and most of them recur. The main ones are the cloud or data center infrastructure that runs Terrakube and its workers, a relational database (Terrakube supports PostgreSQL, MySQL, Oracle and SQL Server through Liquibase), key management for state encryption, platform staff who operate and patch the stack, and the one-time setup and upgrade work. Infrastructure and staff usually cost the most over time. Ask for each component to be priced separately in a quote so you can see which items scale with the number of workspaces, runs and users. Compare that against your current HCP Terraform or Terraform Enterprise invoice, which is driven by managed resources or a custom contract.
How long does an EU migration from HCP Terraform take?
The duration depends on the number of workspaces, how much state must be moved, how many variables and VCS connections need to be recreated, and how many configurations share data through the terraform_remote_state data source. OpenTofu's migration guide describes four steps (back up state and code, install OpenTofu, initialize and verify, then test with a small change) and calls the process safe and reversible, but it warns that remote state sharing needs extra care. Your identity provider setup, data residency review and change approval process will also set the pace. Ask for a timeline in the written scope, with the workspace count and dependencies listed as assumptions.
What does our organization have to provide for the work?
Several inputs must come from your side before work starts:
- Cloud accounts or data center access in the EU region you choose, with rights to create compute, storage and database services
- An identity provider administrator who can register Terrakube with Dex through providers such as Azure Active Directory, Amazon Cognito, GitHub or SAML
- A VCS administrator for GitHub, GitLab, Bitbucket or Azure DevOps, who can grant read access and register webhooks
- Named data owners who decide which state files contain personal data, how long run logs are kept and who may access workspaces
Without these decisions, the design and the data residency review cannot be completed.
Can our internal platform team run this migration without outside help?
Yes, a capable team can do it alone, but it needs skills in Terraform or OpenTofu state handling, container or Kubernetes operations, database administration, identity federation and VCS integration. The harder parts are usually not the install itself but the ongoing operation: upgrades to Terrakube and OpenTofu releases, backups, access reviews and incident response. Before deciding, check whether the team has capacity for that operating load after cutover. A short internal pilot with one non-production workspace is a useful test of the skills required.
Does a fixed-scope engagement or a retainer suit our migration?
Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. That fits a defined migration: the workspaces in scope, the target environment in your EU region, the identity and VCS integrations, the documentation and the handover. Ongoing support, upgrades and continuous testing are available as retainers, which may suit teams that want someone to maintain Terrakube and track OpenTofu releases after cutover. DeployOpen does not publish a price list, so ask for a quote based on a written scope.
What do Data Act switching rights mean for our exit plan?
The EU Data Act, applicable since 12 September 2025, gives customers of data processing services the right to switch to another provider or to on-premises ICT infrastructure, with a maximum two-month notice period and a 30-day transition under Articles 25 and 29. Switching charges are banned from 12 January 2027 under Article 50. For your exit plan, confirm the notice and transition terms in your current HCP Terraform contract, keep state and configuration exports current, and confirm with counsel how these rights apply to your specific services. Running OpenTofu with Terrakube in your own EU infrastructure also removes the dependency on a single vendor's export path.
Evidence auditors and regulators ask for under this constraint
An EU data residency decision is only as strong as the records behind it. The cards below list the documents and logs that connect where Terraform state and plans live, who can reach them, and how the team could leave. DeployOpen prepares this evidence, but independent auditors and regulators decide whether it is sufficient.
Transfer impact assessment and records of processing
Record where state files, plan files, variables and VCS tokens are stored and processed, and which entity is the controller or processor for each. Under Article 44 of the GDPR, any transfer to a third country, including remote access for support, must meet Chapter V conditions. Check whether any administrator, vendor engineer or backup location sits outside the EEA, and document the assessment for each one.
Data location and access logs
Keep a current map of which regions host the Terrakube database, object storage for state, runner nodes and log sinks. Pair it with access logs covering who logged in, which workspace was run and which state version was downloaded. Ask the platform team to confirm that log retention matches the period your compliance owner set.
Key ownership documentation
Document who holds the keys that encrypt state and plan files and where those keys live. OpenTofu's state encryption supports key providers such as AWS KMS, GCP KMS and OpenBao, so the choice of provider determines which jurisdiction controls decryption. Record key rotation steps, break-glass holders and whether any key provider is operated by a non-EU entity subject to foreign law.
Supplier contracts and sub-processor lists
Collect data processing agreements with every cloud host, managed database provider, KMS operator and implementation partner that can touch the environment. Confirm whether each supplier can be compelled by third-country law to disclose data in its control, which the EDPB treats as a risk to assess before engagement. Keep the current sub-processor list and the notice process for changes.
State encryption configuration
Export the OpenTofu encryption block and the provider settings used in each workspace, then store them under version control with review. Confirm that encryption applies to both state and plan files in every remote backend. Test decryption from a clean runner so the evidence shows the setup works, not only that it was written.
Backup and exit test records
Retain restore test results for Terrakube's database and state storage, showing that a backup can be rebuilt inside the EU. Record an exit test that pulls state out of the platform and runs a plan on another backend. The Data Act gives customers switching rights for data processing services, so keeping this record shows the exit path is real.
What changes for your team after the move
The main change is who owns the platform. On HCP Terraform, HashiCorp runs the service, its upgrades and its availability. Once you run Terrakube in an EU region or data center you control, your team owns upgrades, backups, database maintenance, access reviews and the decision to follow each Terrakube release. Check the Terrakube GitHub releases page on a fixed schedule. The 2.33.2 release is a reference point only, so confirm which version is current when you plan, and test each upgrade in a non-production environment before rolling it out to production workspaces.
The same discipline applies to the IaC CLI. Pin the OpenTofu version in every repository, in CI images and in the Terrakube runner configuration, so that a plan that works today produces the same result next month. The latest reference point is v1.13.1 from the OpenTofu GitHub releases page, but confirm the version your teams standardize on and record the upgrade test that approved it. Treat each OpenTofu minor release as a change to test against your modules, providers and state, not as a drop-in update.
Plan for feature parity risk. OpenTofu aims to keep feature parity with Terraform, but the OpenTofu FAQ states that the community decides which features it adopts. Compatibility with future Terraform releases is therefore not guaranteed. Ask your platform team to track Terraform features your modules depend on, and budget for compatibility testing whenever a new Terraform version introduces syntax or behavior your configurations might need. Document this as a known operating risk in your change management process.
How DeployOpen deploys this stack under an EU residency requirement
DeployOpen plans, implements, hardens and documents self-hosted OpenTofu and Terrakube inside your own cloud accounts, data centers or air-gapped networks, so the region and operators are yours to choose. We scope the work in writing first, then build and hand over a platform your team can run without depending on a hosted control plane.
How we scope
- We confirm which EU region or data center will host state, plans, logs and Terrakube's database.
- We map which workspaces, teams, VCS connections and identity providers must move, and which ones stay out of scope.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We install Terrakube with its Helm chart or Docker Compose in your environment and connect it to your identity provider through Dex.
- We configure OpenTofu state encryption with a key provider you control, and document where keys and state are stored.
- We test a representative workspace end to end, including remote runs, the cloud block and policy extensions, before wider rollout.
How we hand over
- You receive architecture, access and data-flow documentation, plus runbooks for backup, restore and upgrades.
- We prepare evidence for your data protection and compliance reviews, while independent auditors and certification bodies make the assessments.
- Your team takes over administration with a walkthrough of permissions, group mappings and the migration checklist.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Support can cover Terrakube and OpenTofu version upgrades, which we test in a staging environment before production.
- Ask any provider to confirm in writing where support staff access data from, since remote access from outside the EU can count as a transfer.
