Should you choose env zero or a self-hosted env0 alternative with Terrakube?
env zero fits teams that want a managed environment lifecycle and vendor-run operations, while Terrakube fits teams that want the run and state platform inside their own cloud accounts and have the staff to operate it. If a renewal, a pricing change or a data residency requirement has put env zero under review, the choice turns on three questions rather than on feature lists alone. The first is volume: how many environments, workspaces and runs you expect each month, because env zero's billing is tied to environments and successful applies, and that model changes how the bill grows as you scale. Ask env zero for current pricing in writing against your real run pattern, since no env zero figures are supplied for this comparison.
The second question is which env zero workflow features your teams depend on. Map each one, such as environment lifecycle management, templates, approval policies, cost governance or its runner model, to a Terrakube equivalent or to a gap you would have to fill yourself. Terrakube supports the remote backend and the cloud block, works with OpenTofu or Terraform, and adds OPA and Infracost through extensions, but some env zero workflows will need custom work. Confirm current feature availability directly with each vendor and in your own test environment. The third question is operating capacity. Terrakube means someone owns installation with its Helm chart or Docker Compose option, the database, upgrades, backups, identity configuration through Dex and runner capacity. Name that owner before you commit, and ask whether the cost of that staffing is lower than the renewal delta you are trying to avoid.
Which option fits which situation?
This table matches common buyer situations to the better fit between env zero and self-hosted Terrakube, with the condition that decides each one. Where a row depends on a specific env zero feature, confirm that feature with env zero before you decide, since this page does not assume its current capabilities.
| Situation | Better fit | Condition that makes it so |
|---|---|---|
| A platform team running a few shared modules for one organization | Terrakube | One team owns the workspaces, the module registry and the approval path, so a self-run platform with a private registry covers the need without per-environment billing to manage. |
| Many self-service environments across several business units | Confirm with env zero | Compare how each platform's model maps to your environment count, template reuse and per-environment costs, and ask env zero how its environment lifecycle handles this scale. |
| A strict data residency mandate | Terrakube | State, plan logs and run data stay in infrastructure you choose. Confirm the residency terms of any SaaS option with its vendor and map where each stored item lives. |
| An air-gapped or disconnected network | Terrakube | A self-hosted platform installs inside the isolated network. Confirm with env zero whether its offering can run without outbound connections before assuming it cannot. |
| An existing GitHub, GitLab, Bitbucket or Azure DevOps pull request workflow | Either, depending on plan approval needs | Terrakube reads code from these VCS providers. If your main need is plan and apply on pull requests, also review Atlantis as a lighter option for that workflow. |
| A team that already runs Kubernetes | Terrakube | Terrakube documents installation with a Helm chart, so it fits a cluster you already operate. Your team then owns upgrades, database backups and cluster capacity. |
| A team that needs OpenTofu state encryption at rest | Terrakube with OpenTofu | OpenTofu supports client-side state encryption with key providers such as AWS KMS, GCP KMS and OpenBao. Confirm the encryption options your env zero plan provides. |
| A team that wants to limit operations staff time | Confirm with env zero | Self-hosting moves patching, upgrades and availability to your team. Ask env zero what it operates for you and compare that against the staff time you can commit. |
How remote runs and runners differ in practice
Teams that start plans and applies from their own terminal or scripts can keep that habit after moving off env zero. Terrakube supports both the remote backend and the cloud block, so a run can be started from the Terraform or OpenTofu CLI and executed on the Terrakube side. The choice of mechanism depends mainly on the IaC CLI version the team already pins.
- Cloud block version floor: The cloud block requires Terraform v1.1 or later, according to Terrakube's CLI-driven workflow documentation.
- Remote backend for older versions: Configurations on earlier versions can use the remote backend, which also supports migrating state.
- Authentication: Users run
terraform loginagainst the Terrakube API hostname, so credentials are issued per user rather than shared through pipeline variables. - Workflow parity: Existing plan and apply commands stay the same, which limits retraining for engineers who already work from the CLI.
- Private module registry: Terrakube also provides a private registry for modules and providers, which the CLI can consume.
Check which OpenTofu or Terraform version each configuration pins before cutover, and confirm how env zero's CLI-based flow maps to the Terrakube login and backend settings in your environment.
Pull request and merge driven workflows are where most of the operating model differences show up. Terrakube integrates with several code hosts to retrieve Terraform and OpenTofu code, so the team can keep its existing repository and review process. Confirm which code host edition and version your organization runs, because the supported list is specific about editions.
- GitHub: Both GitHub cloud and GitHub Enterprise are supported.
- GitLab: GitLab EE and GitLab CE are supported.
- Bitbucket and Azure DevOps: Both are listed as supported code hosts.
- Connection ownership: VCS connections are managed inside Terrakube and access to them is assigned by group, so the platform team controls who can attach a repository to a workspace.
- Trigger behavior: Confirm which events start a run, how plan output is reported back to the review, and how apply approvals are gated, because these settings differ between env zero and Terrakube.
Recreate VCS connections in a test workspace first, and compare the plan output and approval steps with your current env zero environments before moving production stacks.
The execution layer decides where plans and applies actually run, who keeps that machine healthy and where cloud credentials are held. env zero offers self-hosted runners as an option, and Terrakube runs work on executors that the platform deploys and manages. The two are not interchangeable, so compare them on operating responsibility rather than on feature names. Confirm the details of env zero's runner model against its current documentation, since runner setup and licensing can change.
- Who operates it: With a self-hosted env zero runner, the customer operates the runner host. With Terrakube, the executors are part of your own Helm or Docker Compose deployment, so your team runs them.
- Where credentials sit: Cloud credentials for applies must reach the execution environment. Decide whether they live in the executor, in a secrets manager or in a workload identity, and document that choice.
- What to size: Plan concurrency, state size and the number of workspaces determine capacity. Measure these from your own environment rather than assuming a standard size.
- What to patch: Executor images, the Terrakube components, the database and the OpenTofu or Terraform binaries each need a patch and upgrade routine.
- Network placement: Executors need reach to cloud APIs, state storage and code hosts, which may require egress rules in restricted networks.
Ask env zero for the current runner requirements in writing, and map each item above to a named owner in your organization before choosing the execution model.
Feature by feature: env zero against Terrakube
This table compares env zero with Terrakube based on Terrakube documentation at the time of writing. Where an env zero cell depends on details not confirmed here, it says to confirm with env zero before deciding. The main takeaway is that Terrakube covers the core run, state, access and policy needs on your own servers, while env zero-specific features such as templates and environment lifecycle need a direct check against your workflows.
| Capability | env zero | Terrakube |
|---|---|---|
| Workspaces, environments and templates | Environment-based platform with templates. Confirm template and environment lifecycle details with env zero. | Workspaces organize runs, variables and permissions. Confirm how Terrakube maps to your environment naming and reuse needs. |
| Remote runs from the CLI | Supports Terraform and OpenTofu workflows. Confirm CLI run behavior for your version with env zero. | Supports the cloud block (Terraform v1.1 or later) and the remote backend, with terraform login. |
| VCS integration | Confirm supported providers and connection model with env zero. | Connects to GitHub (cloud and Enterprise), GitLab (EE and CE), Bitbucket and Azure DevOps. |
| Self-hosted runners or executors | Confirm runner options and where runners execute with env zero. | Runs are handled by Terrakube executors inside your own infrastructure. Confirm sizing with your deployment. |
| Policy checks and cost estimates | Confirm built-in policy and cost features and their plan tiers with env zero. | Extensions add OPA policy checks and Infracost cost estimates to runs. Confirm extension setup for your runs. |
| Identity and group permissions | Confirm SSO and role model with env zero. | Dex integrates with Azure Active Directory, Amazon Cognito, GitHub and SAML. Permissions are assigned by group. |
| Private module and provider registry | Confirm registry features and hosting with env zero. | Provides a private registry for Terraform modules and providers. |
| Database and installation options | Hosted by env zero. Confirm data residency and hosting options with env zero. | Relational databases supported by Liquibase, including PostgreSQL, MySQL, Oracle and SQL Server. Install with Helm or Docker Compose. |
| License | Commercial subscription. Confirm terms and pricing model with env zero. | Apache 2.0. Free software, with hosting, database and operations costs borne by your organization. |
Where OPA, Infracost and group-based identity fit
Terrakube covers three concerns that often decide a migration: policy checks before apply, cost visibility before merge, and access that follows your identity provider. Each card below describes what the component does, when it matters, and what to confirm against env zero's own features before you compare the two.
OPA policy checks as an extension
Terrakube extensions can run Open Policy Agent checks against a run, so a plan can be evaluated against your rules before it is applied. This matters most when plans need a review gate, for example when production changes must satisfy tagging, region or instance-size rules before an approver can release the apply. Write the policies in Rego, store them under version control, and test them against sample plan output. Ask env zero which policy controls it offers out of the box, how it evaluates policies on plans, and whether those controls map to your existing rules without re-authoring them.
Infracost estimates as an extension
Terrakube can run Infracost as an extension, adding a cost estimate to each run so the expected monthly spend of a change is visible before it merges. This is useful when platform teams want reviewers to see the cost impact of a pull request, not just the resource diff. Estimates depend on the pricing data and resource coverage of the Infracost version you run, so verify that your main resource types are priced. Compare this with env zero's own cost features and confirm whether they show estimates on the same runs, and how they handle cost data when you are not billed on it.
Identity through Dex
Terrakube authenticates users through Dex, which connects to identity providers such as Azure Active Directory, Amazon Cognito, GitHub and SAML. This matters when sign-in must follow your corporate identity provider, including MFA and offboarding, instead of separate platform accounts. Plan the Dex connector configuration with your identity team, test sign-in for each provider you use, and confirm how user removal propagates to active sessions and API tokens. Ask env zero which SSO protocols it supports on your plan, whether SCIM provisioning is included, and how it logs access, so you can compare the two models on equal terms.
Group-based permissions on resources
Terrakube assigns permissions on workspaces, modules and VCS connections by group, so access is granted to teams rather than individual users. This matters when who may plan, apply or change a VCS connection must follow the groups in your identity provider as people move between teams. Design the group model before migration: map each team to the workspaces it operates, separate who can approve applies from who can edit variables, and review group membership on a fixed schedule. Confirm with env zero how its team and environment permissions are scoped, and whether it can restrict module and VCS changes at the same granularity.
Custom pricing against running it yourself
The core trade is who carries the operating work and who sets the bill. env zero is a commercial platform, and its pricing is not published as a fixed list in the supplied facts: it combines a free tier with custom terms tied to successful applies or environments. Before comparing, ask env zero for the written terms that apply to your environment count, your expected apply frequency, the number of users and any support tier, and confirm whether the free tier limits fit your current workload. Those terms set the recurring cost, and they are the number you will be negotiating against.
Terrakube's software is free under Apache 2.0, so the cost does not disappear. It moves to the infrastructure that hosts the API, UI and executors, the relational database that Liquibase supports (PostgreSQL is the usual choice), storage for state and logs, and the people who install it through the Helm chart or Docker Compose, upgrade it, back it up and handle incidents. The cost of those people is the largest and least visible line. Ask whether your team already runs Kubernetes, managed databases, identity and backup for other workloads, because the marginal cost of Terrakube is much lower in that case than on a greenfield cluster.
env zero is usually the better fit when the team wants vendor-run upgrades and support, and does not want to staff platform operations. Terrakube is usually the better fit when per-environment billing is hard to forecast because environment counts grow with feature branches, when data control over state and run logs is a requirement, or when the organization already operates the surrounding infrastructure. If you choose Terrakube, budget for an implementation partner to size executors, the database and identity integration, and a written support model, and treat that effort as one-time with recurring operations on top.
Which costs recur and what drives each one
Moving from env zero to Terrakube swaps one recurring bill for several smaller ones that you control and some that you must staff. The cards below separate the components, who gets paid for each, and what pushes each cost up or down, so you can compare a quote against your own run volume and environment count.
Software license
Terrakube and its tooling are licensed under Apache 2.0, so the software itself carries no license fee. OpenTofu is under the Mozilla Public License 2.0, which also has no per-seat charge. Check that the license terms of every extension, provider and module you plan to use match your own policy, since those carry their own licenses. Confirm this against each project's repository before you commit, because the license is the one cost that is typically zero from day one.
Hosting for services and database
This is a recurring cloud or data center cost paid to your infrastructure provider or internal platform team. Terrakube runs as a set of services with a relational database that Liquibase supports, such as PostgreSQL, and it installs with a Helm chart or Docker Compose. Cost rises with the number of workspaces, the size of stored state and logs, and whether you run separate non-production and production instances. Ask the vendor or your provider to size the database backups and the replicas that high availability requires.
Executor capacity for runs
Each plan and apply consumes compute on the executors that Terrakube schedules, and that compute is paid for by your infrastructure team, often as a cluster you already run. Executor cost is driven by run volume, the number of teams that trigger runs at the same time, and how long your heaviest plans take. Runs that call out to policy checks or cost estimates add time. Size capacity for peak concurrency, not the average, and ask who owns the cluster and its autoscaling.
Engineering time for install and migration
This is one-time effort paid to your internal team or to DeployOpen under a written scope. It covers installation, identity provider setup, mapping env zero environments to Terrakube workspaces, moving state using the documented migration path, and rebuilding VCS connections and policy checks. Effort scales with the number of environments, the number of remote_state dependencies, and how many templates and approval flows you must recreate. Ask for the inventory of environments and dependencies that the estimate is based on.
Ongoing operations and on-call
This is a recurring internal cost for upgrades, patching, backups, restore tests and on-call coverage for the platform. Terrakube releases move quickly, so each upgrade needs a test run against your workspaces before production. The load grows with the number of teams using self-service, the number of environments, and your availability targets. Ask whether a retainer covers upgrades, continuous testing and out-of-hours response, and who signs for restore testing.
env zero subscription or usage charges
On the other side, env zero bills a commercial subscription with pricing that depends on the platform plan and usage, and you should compare that against the model in the vendor's current quote rather than assume it is fixed. The charge recurs and tends to rise with environments and deployment activity. Ask env zero to state in writing which unit they bill, what is included, what counts as a billable event, and what happens at renewal.
Where state, credentials and identity data sit after the switch
The first control question after a switch is where state, run logs and credentials physically live. With Terrakube, the platform, its database, the state it stores, run logs and the credentials its executors use all run in your accounts or data centers. That makes data residency and access logging your responsibility to design and evidence. Decide which region and network zone hold the Terrakube database, who holds administrative access to it, and where executor credentials come from. Those decisions define your residency story, and an auditor will ask you to show them rather than describe them.
With env zero, the question is answered by the vendor, so confirm the details in writing before you plan around them. Ask env zero where its platform, state and run logs are hosted, which regions are available to your organization, whether those regions can be pinned for your environments, how long logs are retained, and who at env zero can access customer state. The answers determine whether your current setup already meets your residency requirements and which evidence you can request from the vendor for your own assessments. Record the answers next to your data classification so that the comparison with a self-hosted deployment is based on facts rather than assumptions.
OpenTofu can change the trust model for state no matter which platform stores it. Its state and plan encryption encrypts these files client-side before they leave the runner, using key providers such as AWS KMS, GCP KMS, OpenBao and Azure Vault, with PBKDF2 for passphrase-based keys. The platform then holds ciphertext, and key access is controlled in your key management system. Test this before you rely on it: confirm that your chosen key provider works with your runners, that key rotation and recovery are documented, and that losing a key does not mean losing state. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue audit reports and certifications, and this work does not replace them.
What a move from env zero to Terrakube involves
The sequence moves environments, state and automation out of env zero in an order that keeps live infrastructure running throughout, and ends with a Terrakube setup your team operates and an env zero account with no active environments.
Inventory environments, templates and policies
Your platform team lists every env zero environment, the template or module each one uses, its variables and variable sets, its VCS connection and branch, and every approval policy or OPA check attached to it. Include which environments run on self-hosted runners and which teams own them. The step is done when you have a written inventory that another engineer could use to rebuild each environment without access to env zero. Ask env zero's support team to confirm how your plan exposes these settings, since export options depend on your contract and product version.
Stand up Terrakube in a non-production network
Install Terrakube using the Helm chart or Docker Compose, as its README documents, in a network that cannot reach production state. Connect it to a supported relational database such as PostgreSQL, configure a VCS connection to a test repository, and set up identity through Dex with groups that map to your teams. Testing with minikube is also documented if your cluster standard calls for it. The step is done when a test workspace runs a plan and apply end to end and a group member can see only the workspaces they are granted.
Migrate state out of the env zero backend
For each environment, follow the documented path: authenticate with terraform login, keep a local backup of the current state, replace the backend block in the configuration, and run init with the migrate-state option so state moves to Terrakube. Start with one low-risk environment. Check whether any configuration reads another stack's outputs through terraform_remote_state. OpenTofu's migration guidance says these setups need extra care, so map every consumer before you change its source stack. The step is done when the state is present in the Terrakube workspace and the backup is stored under your existing retention rules.
Recreate workspaces, variables and VCS connections
Create a Terrakube workspace for each environment with the same working directory, branch, variables and sensitive values. Sensitive values come from your secrets store or the env zero export, not from memory. Attach the VCS connection for GitHub, GitLab, Bitbucket or Azure DevOps and assign group permissions on each workspace, module and connection. The step is done when a plan in each workspace shows the same resource addresses and variable inputs that env zero showed for that environment.
Replace templates and approval policies with extensions
Rebuild each env zero template as reusable Terrakube module or workspace configuration, and rebuild each approval rule as a Terrakube control. Policy checks can run through the OPA extension and cost estimates through the Infracost extension, and custom checks can use the Terrakube API. Where an env zero feature has no equivalent, record the gap, decide who owns the control in the meantime, and confirm the approach with your security and compliance team. The step is done when every rule in your inventory has a named Terrakube mechanism or a documented owner for a manual control.
Switch runners to Terrakube executors
Point each migrated workspace at Terrakube executors instead of env zero's self-hosted runners, and confirm that the executors have the network access, cloud credentials and tool versions the configuration needs. Use OpenTofu or Terraform versions that match the constraints in each configuration. Run a small, reversible test change in each workspace first, as OpenTofu's migration guidance recommends. The step is done when the test change applies in Terrakube, the change is visible in the run history and no env zero runner is still needed for that workspace.
Verify with no-change plans
For every migrated environment, run a plan with no configuration changes and confirm it reports no changes. A clean plan shows that Terrakube reads the same state and inputs that env zero used. Any drift must be explained and resolved before the environment is considered migrated. Keep the plan output in your change record. The step is done when each environment has a recorded no-change plan and the owning team has signed off.
Mark env zero environments inactive
After verification, mark each env zero environment inactive so it stops running but leaves its resources in place. Do not run a destroy in env zero during this step. Keep the env zero account and exported records for the retention period your audit requirements set, and confirm with env zero how inactive environments are handled under your contract. The step is done when every environment has a Terrakube workspace that is the only source of plans and applies, and the env zero environments show as inactive with no change to the live infrastructure.
What do buyers ask before switching from env zero to Terrakube?
What does it cost to switch from env zero to Terrakube?
The switch costs are mostly people time and infrastructure, not software licenses, because Terrakube is Apache 2.0 licensed. Ask for the cost components separately: the platform hosting (Kubernetes or Docker hosts), the database that Liquibase supports such as PostgreSQL, runner or executor capacity, the migration work itself, and the operations effort after cutover. One-time costs include mapping environments, recreating variables and VCS connections, and validation. Recurring costs include hosting, database operations, upgrades and on-call support. Costs rise with the number of environments, the size of each state file, the number of pipelines that depend on env zero hooks, and how many approval paths need rebuilding. Ask any quote to itemize these components so you can compare them with your current env zero invoice.
How long does an env zero to Terrakube migration take?
The timeline depends on the work, not on a fixed duration that applies to every team. The main drivers are the number of environments, the complexity of templates and approval policies, how many shared outputs use terraform_remote_state, and how deep your validation must go before cutover. Teams with a small set of environments and simple variables move faster than teams with many interdependent stacks. Plan for a parallel period in which env zero and Terrakube both exist, and for a sign-off step before environments are marked inactive. Ask any proposal for a phased schedule with named milestones and the criteria that end each phase.
Can our own team migrate from env zero to Terrakube without outside help?
Yes, a team can do it in-house when it already runs Terraform or OpenTofu in production and has working Kubernetes or Docker operations skills. The harder part is learning how Terrakube handles workspaces, runs, VCS connections, identity groups and extensions, which takes time even for experienced engineers. Start with a small, low-risk workspace to test the full path: the CLI-driven workflow using terraform login against the Terrakube API hostname, state migration with the remote backend, and a no-change plan. Be realistic about the staffing needed to run the platform after launch, including upgrades, backups and on-call coverage.
What do we need to provide during an env zero to Terrakube migration?
The migration needs access and decisions from several teams. Typically you provide:
- Administrator access to env zero, so the current environments, variables, templates and approval policies can be inventoried and exported where possible
- Access to the cloud accounts that hold the managed resources, with the permissions needed to run plans and applies
- Access to your VCS provider (GitHub, GitLab, Bitbucket or Azure DevOps) and the connections Terrakube will use
- Your identity provider, so Dex can be configured and groups mapped to workspace permissions
- Named owners for each environment and a written sign-off on the cutover plan before any environment is marked inactive
Confirm with your team which of these apply, because the exact list depends on how env zero is configured in your organization.
Can Terrakube replace env zero's policy and cost checks?
Terrakube can cover common policy and cost checks through its extensions, which add OPA policy checks and Infracost cost estimates to runs. Its API also supports custom integrations if you need checks that the extensions do not provide. Whether it matches your env zero setup exactly is a question to confirm, because the feature set of your current env zero plan and the policies your teams rely on must be listed and compared one by one. Ask for a feature-by-feature mapping that shows, for each env zero policy or cost control, the Terrakube equivalent, the owner, and any gap that needs custom work.
Should we hire a partner for the env zero to Terrakube switch?
Hiring a partner makes sense when you need a fixed scope, written deliverables and evidence for an internal or external review, and your team lacks the time or Terrakube experience. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports or certifications. Ask any partner for a written scope, the acceptance criteria for each deliverable, the handover process, and what ongoing support or retainer terms apply after cutover. DeployOpen does not publish a price list, so a quote follows from that written scope.
How DeployOpen helps evaluate, implement or migrate Terrakube
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For env zero vs Terrakube, we start from your environments, your state and your approval rules, then agree the scope in writing before any work begins.
How we scope
- Inventory which env zero environments, workspaces and templates your teams actually use today
- Agree whether runs will use the CLI remote backend, cloud block or VCS-driven workflows
- Define which identity provider groups, OPA policies and Infracost checks must carry over
- Confirm written scope, deliverables and timelines before any migration or build work starts
How we build
- Deploy Terrakube with Helm or Docker Compose in your infrastructure, on a database you select
- Connect VCS integrations for GitHub, GitLab, Bitbucket or Azure DevOps and configure group-based permissions
- Set up self-hosted executors or runners and wire in OPA and Infracost extensions where scoped
- Test state migration in a non-production workspace, including a no-change plan before cutover
How we hand over
- Document workspace structure, permission model, variable handling and runner configuration for your team
- Record the state migration steps, rollback path and how env zero environments are marked inactive
- Provide runbooks for upgrades, backups of the Terrakube database and state, and incident response
- Walk your platform and security staff through operation and confirm they can run it without us
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Track Terrakube and OpenTofu releases and plan upgrades against the scope you agreed
- Retest extensions, integrations and access controls after changes to your environment
- Ask for a quote built from the written scope, which sets the components and hours involved
