Migrate from env zero to Terrakube

Migrate from env zero to Terrakube: what the move involves

If your env zero contract is up for renewal, its pricing has changed, or you need run data and state under your own control, the move is a state, workspace and integration migration. You keep Terraform or OpenTofu as the CLI, and you rebuild the run platform around it in Terrakube. Most of the work falls to a platform engineering team with access to the cloud accounts, the version control system and the env zero organization, often with help from an implementation partner on a fixed-scope plan. Effort and risk concentrate in two places: the state files, which must move without drift, and the approval and policy logic, which env zero may enforce through templates, approval policies and environment lifecycle rules that Terrakube does not copy automatically.

Terrakube is licensed under Apache 2.0 and its documentation describes it as a replacement for closed-source tools such as env zero, so the target is documented, not improvised. Its CLI-driven workflow supports the remote backend and the cloud block, so developers can keep running terraform or tofu commands with a changed backend or cloud configuration. Confirm with your own inventory which env zero features you actually rely on, such as environment-scoped variables, scheduled destroys, cost policies, or self-hosted agents, and map each one to a Terrakube workspace setting, an extension such as OPA checks, or a process you own. Items without a clear target belong on the risk register before any workspace is recreated.

Plan the cutover one environment at a time. For each environment, export the current state, keep a local backup, change the backend configuration, run init with the state migration option, and confirm that a plan shows no changes before anyone applies anything. Recreate variables, VCS connections and access groups in Terrakube, then mark the env zero environment inactive so it stops managing resources without destroying them. Ask any implementation partner to state in writing how it will handle state verification, rollback and the evidence you keep for each environment, and check the OpenTofu migration overview for its warning on terraform_remote_state consumers, which need extra care wherever one configuration reads another's outputs.

Which env zero capabilities map to Terrakube, and which need rework

This table maps the env zero capabilities most teams depend on to the Terrakube features documented in its README and CLI-driven workflow docs. Read each status as clean (documented equivalent), needs rework (possible, but you rebuild or rewrite it), or gap (not documented, so confirm it in your environment before you cut over).

Capability	env zero usage to replace	Terrakube fit	Status
Remote state	Hosted state per environment	Remote backend and cloud block both work. Migrate state with init -migrate-state after login.	Clean
Workspaces and variables	Environments with variables and inputs	Recreate workspaces and variables by hand or through the Terrakube API. Script it for many environments.	Needs rework
VCS connections	GitHub, GitLab, Bitbucket and Azure DevOps links	Supported for GitHub, GitLab EE and CE, Bitbucket and Azure DevOps. Recreate each connection in Terrakube.	Needs rework
RBAC and identity	Team roles and SSO	Dex connects to Azure AD, Cognito, GitHub and SAML. Permissions are assigned by group on workspaces, modules and VCS.	Needs rework
Remote runs from the CLI	Plans and applies started from the Terraform or OpenTofu CLI	The cloud block needs Terraform 1.1 or later. Earlier versions use the remote backend. Authenticate with terraform login.	Clean
Private module registry	Internal modules and provider sources	Terrakube provides a private registry for modules and providers. Republish each module and confirm version paths.	Needs rework
OPA and Infracost extensions	Policy checks and cost estimates on runs	Extensions add OPA policy checks and Infracost estimates. Rewrite policies and re-test output against env zero results.	Needs rework
Environment templates and approval policies	Reusable templates and approval gates per environment	Not documented as equivalent. Confirm how Terrakube handles templates and approvals in your target environment.	Gap
Cost governance	Environment budgets and spend controls	Infracost estimates are documented. Budget enforcement is not. Confirm what you need and how you will meet it.	Gap

How state leaves env zero and lands in Terrakube

The state handoff starts before any configuration changes. Confirm with env zero how you can retrieve the current state for each environment, which state versions it keeps and in what format, because the export path is the one step this page cannot document for your account. Terrakube supports the remote backend and the cloud block. Its CLI-driven workflow documentation says the cloud block needs Terraform v1.1 or later, while earlier versions can use the remote backend, which also supports migrating state. Older configurations therefore do not need a version upgrade just to move. On the workstation, run terraform login against the Terrakube API hostname so the CLI stores a token for that host before you change any backend settings.

Next, save a local backup of the exported state file and commit the current configuration to version control, so you have a known-good starting point if the handoff fails. Then replace the env zero backend block with a cloud block that names the Terrakube organization and workspace, or with a remote backend block if the configuration must stay on a Terraform version earlier than 1.1. Run terraform init -migrate-state (or tofu init -migrate-state for OpenTofu) and accept the prompt to copy state into Terrakube. Confirm whether your env zero environments use a plain remote backend or a wrapper that writes state elsewhere, because that determines which backend block you remove and what the backup should contain.

Verify before anyone applies. Run a plan against the migrated workspace and expect no changes. A plan that proposes creates, updates or destroys means state, variables or provider versions do not match the live resources, so stop and resolve the difference first. Do not run apply to clear it. Check that the state appears in the Terrakube workspace and that the state version history matches what you exported. Configurations that read other stacks through the terraform_remote_state data source need extra care, as the OpenTofu migration overview notes, so test those dependents separately. Record the clean plan output, since it is the evidence that the handoff succeeded before variables and VCS connections are recreated.

What to export and rebuild from env zero

Six items carry the working state of an env zero estate: state, variables, VCS connections, identity groups, modules and policies. Only state has a documented export path into Terrakube, so the other five must be inventoried in env zero and rebuilt by hand. Confirm each one before you decommission anything.

State files

State is the only item that moves as data. Run terraform login against the Terrakube API hostname, keep a local backup of each state, then change the backend block and run init with -migrate-state. Confirm that a plan shows no changes before you touch the next environment. Check which state encryption you need, since OpenTofu can encrypt state with key providers such as AWS KMS, GCP KMS and OpenBao.

Workspace variables and secrets

Terraform variables, environment variables and sensitive values live in env zero and usually cannot be copied out as plain text. Ask env zero which export formats it offers for variables and whether sensitive values can be retrieved at all. Plan to re-enter every variable in the matching Terrakube workspace, and pull secret values from your own secrets manager rather than from an export file.

VCS connections

Terrakube retrieves Terraform and OpenTofu code from GitHub (cloud and Enterprise), GitLab (EE and CE), Bitbucket and Azure DevOps. Each env zero connection must be authorized again in Terrakube and attached to the correct workspace. Check the branch, the working directory and the trigger settings for every environment, because env zero's settings do not transfer automatically.

Identity groups in Dex

Terrakube authenticates users through Dex, with providers such as Azure Active Directory, Amazon Cognito, GitHub and SAML. Permissions on workspaces, modules and VCS connections are assigned by group. Map each env zero team and role to a Terrakube group before inviting users, and confirm with your identity provider that group claims arrive in the form Dex expects.

Module registry content

Terrakube includes a private registry for Terraform modules and providers, but env zero's private modules do not move into it as a package. Republish each module from its source repository with the version tags you rely on, then update every module source address in your code. Test one dependent environment end to end before you retire the env zero copy.

Extension policies

env zero approval policies, templates and cost checks have no direct import into Terrakube. Terrakube extensions can add OPA policy checks and Infracost estimates to runs, so rebuild each approval and guardrail rule as an OPA policy or an extension step. Write down who approved what in env zero, and confirm the same approval gate exists in every Terrakube workspace before cutover.

Migration sequence from inventory to decommission

This sequence moves env zero environments to Terrakube one group at a time, keeping every cloud resource in place and verifying each state before the next change. Each step closes with a written output that shows the work is finished.

Inventory environments, state and integrations
Platform engineering lists every env zero environment with its repository, branch, Terraform or OpenTofu version, state backend, variables, templates, approval policies and VCS connection. The inventory also records which environments share data through the terraform_remote_state data source, because OpenTofu's migration guidance calls out that case for extra care. Done when the team has a file that maps each environment to a target Terrakube workspace and a named owner. Ask env zero to confirm which settings can be exported, since the export format is not covered here.
Stand up Terrakube in a test cluster
Platform engineering installs Terrakube in a non-production environment using the Helm chart or Docker Compose, following the installation options in its README. Configure a supported database such as PostgreSQL, connect the identity provider through Dex, and map groups to workspace, module and VCS permissions. Done when a test user can log in, a sample workspace runs a plan against a repository from GitHub, GitLab, Bitbucket or Azure DevOps, and group permissions match the inventory.
Pilot one low-risk environment
Choose an environment with a small blast radius, such as a development sandbox, and recreate its workspace, variables and VCS connection in Terrakube. Keep a local backup of the state file, then run terraform login or tofu login against the Terrakube API hostname and switch the configuration to the Terrakube backend. Follow Terrakube's CLI-driven workflow documentation for the cloud block or remote backend, and confirm the CLI version is supported. Done when the pilot environment plans with no changes and the result is recorded in the migration log.
Run both platforms in parallel
Keep the pilot environment active in env zero and run no-change plans from both platforms against the same state and commit. Compare plan output, provider versions and variable values so differences surface before any apply. Only one platform may apply to a given state at a time, so record which side owns applies for each environment. Replace env zero templates and approval policies with Terrakube equivalents, OPA checks through its extensions, or manual review, and log each gap with its decision. Done when each migrated environment shows a clean plan on both sides and the gap register lists every template and policy with its replacement or owner.
Cut over environments in batches
Move the remaining environments in groups, ordered by dependency and starting with the least critical. For each group, pause changes in env zero, confirm no run is in progress, migrate state, switch VCS triggers and runners to Terrakube, and update CI/CD pipelines and any remote state consumers. Run a no-change plan on each environment after its switch. Done when every environment in the batch has a successful no-change plan on Terrakube, approvers have accepted the new workflow, and the batch is entered in the migration record.
Mark env zero environments inactive
After Terrakube holds the state for an environment, mark the matching env zero environment inactive so it stops triggering runs. Do not run a destroy. Before changing anything, confirm with env zero documentation or its support team what inactive means for state, variables, deployment history and any scheduled jobs. Check that the cloud resources still exist and that a plan on Terrakube shows no changes. Done when each retired environment has no queued runs, its resources are in place, and its state exists only in Terrakube, with the evidence saved in the migration record.

How the migration changes by team size and starting point

A small team that uses env zero mainly as a remote state backend and a place to run applies from the command line has the shortest path. The work centers on the state and the CLI, with few templates or approval rules to rebuild. Start by confirming which OpenTofu or Terraform version each root module uses, because Terrakube's cloud block requires Terraform v1.1 or later, and earlier versions use the remote backend instead.

State first: Export state from each env zero environment, keep a local backup, then point the configuration at Terrakube and run init with -migrate-state.
Authentication: Run terraform login against the Terrakube API hostname so the CLI can start remote runs.
Variables: Recreate only the variables the configuration actually reads, and mark secrets as sensitive in Terrakube.
Verification: Confirm a no-change plan in each workspace before anyone runs an apply.
Retirement: Mark the env zero environment inactive only after the Terrakube plan matches, so resources stay in place.

Before you start, ask whether the team's root modules use terraform_remote_state, since those dependencies need coordinated cutover.

What drives cost and duration in this migration

This table lists the factors that change how much work moving from env zero to Terrakube takes, and who pays for each part. Read it as a checklist for scoping: the rows marked as one-time shape the project, while the recurring rows shape what your team carries after cutover.

Driver	Why it changes cost or effort	How to keep it down or what to ask for
Number of environments and state versions	Each environment needs its own state move, backend change, plan check and inactive marking, so effort grows with the count.	Ask the vendor to inventory environments and state sizes before quoting. Group identical environments into one repeatable procedure.
Templates and approval policies	env zero templates and approval rules must be rebuilt as Terrakube workspace settings, extensions or pipeline steps, which is design work rather than copying.	Count templates and approval paths early. Ask whether OPA policy checks will be rewritten or reused.
VCS and identity complexity	Each VCS connection and identity group must be recreated and permissions reassigned by group in Terrakube, which Dex supports for several identity providers.	List repositories, branches, SSO groups and role mappings. Confirm which identity provider Dex will use in your environment.
terraform_remote_state dependencies	Configurations that read other stacks' state need coordinated cutover, since the OpenTofu migration guidance flags this case for extra care.	Map every producer and consumer of remote state. Ask for a dependency order and a rollback plan per stack.
Runner design	Choosing between env zero's hosted execution and self-hosted runners against Terrakube executors affects networking, credentials and sizing work.	Decide where runs execute and which cloud credentials they need. Ask the vendor to document the executor design and access model.
Encryption and state handling	Deciding whether to enable OpenTofu client-side state encryption with a key provider adds key management and testing work.	Confirm the key provider and who owns the keys. Ask for a test that restores state from an encrypted backend.
Testing and documentation (one-time)	Parallel no-change plans, sample changes and runbooks are needed before cutover and are paid once.	Ask for the test matrix, acceptance criteria and the documents delivered at handover.
Hosting, database and upgrades (recurring)	Terrakube runs on your Kubernetes or Docker infrastructure with a relational database supported by Liquibase, and each Terrakube or OpenTofu release needs review and testing.	Ask who patches the platform, how upgrades are tested and what support window applies. Clarify whether support is a separate retainer.
In-house skills	Teams unfamiliar with Helm, Dex, Liquibase or OpenTofu need more time, and skill gaps often extend the schedule more than the tooling does.	Assess team skills before scoping. Ask whether training or pairing is included in the fixed scope.

Questions buyers ask before moving from env zero to Terrakube

How long does a migration from env zero to Terrakube take?

The timeline depends on how many environments you have, how many depend on each other, and how much of the env zero setup is code versus console configuration. No duration is fixed by the tools themselves. The main drivers are the number of workspaces and state files to move, whether environments share data through the terraform_remote_state data source (which OpenTofu's migration guide says needs extra care), how many VCS connections and variable sets must be recreated, and how many templates and approval policies need a Terrakube equivalent. Ask any provider for a timeline built from a written inventory of your environments, and treat a timeline that does not start from that inventory with caution.

Can our own team migrate from env zero to Terrakube without outside help?

Yes, a capable platform team can do it, provided it has someone who owns the Terraform or OpenTofu codebase, someone who runs the Terrakube installation, and time to test. The state move itself is documented: authenticate, optionally back up state locally, change the backend configuration, and run init with migrate-state. The harder work is inventory, rebuilding access controls by group, and replacing env zero templates and approval flows. Outside help is most useful where the estate is large, regulated evidence is required, or there is no internal capacity for a parallel run. DeployOpen plans, implements and documents this kind of migration as a fixed-scope engagement, with scope and deliverables agreed in writing before work starts.

What skills and staff time does a move from env zero require?

Expect to need four skill areas. Infrastructure engineers must understand backend configuration, state, and how plans map to resources. Platform engineers must install and operate Terrakube with a supported database, as its documentation describes using any database Liquibase supports, and manage its runners and authentication. Security or identity staff must map groups from your identity provider to workspace, module and VCS permissions. Application and environment owners must confirm variables and secrets, since those do not move automatically. Staff time is mostly spent on inventory, verification plans and the parallel run, not on typing commands. Ask your team to estimate effort per environment class, and ask any provider to show the same breakdown.

Can we get env zero pricing stated in this guide?

No, this guide does not state env zero prices, and any figure you see elsewhere may not match your contract. env zero pricing depends on your plan and usage, so request the current quote from env zero directly and ask how it counts environments, successful applies and any minimum commitments. On the Terrakube side, the software is free under Apache 2.0, so your cost is the hosting, database, runners, storage, and the people who operate them. Ask for a written breakdown of which costs are one-time (installation, migration, testing) and which recur (hosting, support, upgrades). Compare the two quotes on the same usage assumptions, not on list price.

Should we move to OpenTofu or keep Terraform when leaving env zero?

Terrakube runs both Terraform and OpenTofu, so the choice is about licensing and compatibility, not about whether the platform works. OpenTofu is licensed under MPL 2.0, is under Linux Foundation stewardship, and describes itself as a drop-in replacement for Terraform. Terraform has been under the Business Source License since version 1.6.0. The OpenTofu FAQ aims for feature parity but does not guarantee compatibility with future Terraform releases, so check which features your configurations use and pin versions during the move. OpenTofu's own migration guide describes the move as designed to be safe and reversible, and recommends backing up state and code first.

How do we avoid destroying resources during the env zero cutover?

The safe approach is to move state, not infrastructure. Before changing any backend, take a backup of each state, then point the configuration at Terrakube and run init with migrate-state. Verify that a plan shows no changes before any apply runs from Terrakube. Only then mark env zero environments inactive. Inactivating an environment in env zero should not destroy the cloud resources it manages, but confirm this with env zero's documentation and test it on a non-production environment first, and avoid any destroy action in either system during the window. Keep the old backend available until the new one has been verified across a full change cycle.

What happens to env zero templates, approvals and cost policies in Terrakube?

These do not transfer automatically, so each one needs a deliberate replacement. Terrakube has no direct equivalent of env zero environment templates, so teams usually standardize module and workspace conventions in code and in Terrakube's workspace settings. Approval flows and policy checks need a design: Terrakube extensions can add OPA policy checks and Infracost cost estimates to runs, and its API supports custom integrations. Confirm each capability against the current Terrakube documentation before you rely on it, and document each replacement control so auditors can trace it. Map every env zero approval rule to a named control before cutover.

Do we need to rebuild VCS connections and runners after moving?

Yes. Terrakube connects to GitHub (cloud and Enterprise), GitLab (EE and CE), Bitbucket and Azure DevOps to retrieve code, so each VCS connection must be recreated and scoped to the correct groups. Runners also change: env zero runs on its own infrastructure or your self-hosted runners, while Terrakube uses its own executors, so confirm network access, cloud credentials and secret handling for each target account. Plan this as a separate workstream with its own tests, because a misconfigured connection can break every workspace that depends on it.

What usually goes wrong and how to prevent it

Most failed moves from env zero share a few causes: incomplete state, destroyed resources, broken consumers and lost controls. Each card below names one risk, explains why it matters when moving to Terrakube, and gives a check to run before you cut over.

Stale or partial state

A state pulled before the last apply, or from one of several workspaces, can make Terrakube plan to recreate resources. Before cutover, compare the state serial and lineage of the exported file with the last env zero run. Then run a plan with no code changes against the new backend and confirm it shows no changes before anyone applies from Terrakube.

Resources destroyed with environments

Deleting an env zero environment can run a destroy against its resources. Mark each environment inactive in env zero and disable any destroy or delete actions until the Terrakube plan has been verified. Keep the old state backup until resources are confirmed under Terrakube control, so nothing depends on the environment record still existing.

Broken terraform_remote_state consumers

Configurations that read another stack's outputs through the terraform_remote_state data source point at the old backend. Inventory every consumer before cutover and repoint each data source to the new backend in the same change window. OpenTofu's migration guide flags this case as needing extra care, so test consumers after the switch, not only the producing stack.

Approval logic not carried over

env zero approval steps, policy checks and cost gates do not move automatically. List each approval rule your teams rely on, then rebuild it as Terrakube workspace permissions, OPA policy checks or Infracost extensions. Ask for a written test that a run requiring approval cannot apply without it, and keep the policy results with each run.

Identity groups mismatched

Permissions in env zero map to users and groups in its own model. Terrakube assigns access on workspaces, modules and VCS connections by group through Dex. Map each env zero role to a Terrakube group before onboarding users, and confirm that the identity provider's group claims reach Terrakube under the names you expect.

Provider and module drift after the CLI switch

Moving from env zero's Terraform or OpenTofu runner to Terrakube can change the CLI version, provider versions or module sources. Pin the OpenTofu version and provider lock files in code, and compare the lock file diff before the first run. Confirm that the Terrakube executor image matches the version you tested, since OpenTofu releases change over time.

How DeployOpen scopes and runs this migration

DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a move from env zero to Terrakube, we start with a written scope that maps each env zero environment to a Terrakube workspace and a state migration path, then build and verify it in your environment before any production environment is touched.

How we scope

Inventory every env zero environment, its state location, variables, templates and VCS connections before agreeing the plan.
Agree in writing which environments move first, which stay on env zero, and which are retired after verification.
Confirm where Terrakube will run, which database it will use, and how users will authenticate through your identity provider.
Ask for the scope to name the OpenTofu or Terraform version each workspace will use, so the boundary is clear before work starts.

How we build

Stand up Terrakube with a Helm chart or Docker Compose in your cloud account, data center or air-gapped network.
Recreate workspaces, variables, VCS connections and group permissions, then migrate state with a documented backup and a no-change plan check.
Port approval and policy logic to Terrakube extensions such as OPA checks, and test each one against known-good and known-bad changes.
Verify runner behavior, credentials and cost estimates in a non-production workspace before any production state moves.

How we hand over

Deliver runbooks for state migration, rollback, workspace onboarding and environment retirement, written for your own engineers.
Document each env zero environment's disposition, marking it inactive without destroying the resources it manages.
Walk your platform and security teams through the Terrakube configuration, access model and backup procedure.
Provide evidence of the controls and checks performed, which your own auditors or certification bodies may then assess.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, scoped in writing after the migration.
Plan Terrakube and OpenTofu upgrades as a separate fixed-scope piece of work, tested in a staging workspace first.
Ask any provider for a written quote tied to the scope, including who operates the database, backups and executors after handover.

Migrate from env zero to Terrakube