Does env zero cost more than self-hosting Terrakube?
Terrakube's software license costs nothing, so the comparison with an env zero renewal turns on what you pay to run it. An env zero subscription is a custom quote, and the supplied facts do not include any published env zero price, so the only reliable number is the one in a written quote from env zero. Before comparing, ask env zero to state in writing which unit it bills on (environments, successful applies or seats), what the minimum commitment is, and whether the quote covers support, SSO and the self-hosted agent option. On the self-hosted side, the recurring costs are the infrastructure for Terrakube's API, UI, database and executors, the people who patch and upgrade it, backups and monitoring, and the engineering time spent on the OpenTofu or Terraform CLI version pinning and VCS connections. One-time costs include installation, identity provider integration, workspace and variable migration, and any policy or cost extensions you add. Those one-time costs can be paid to your own staff or to an implementation partner under a fixed-scope written agreement.
Self-hosting tends to cost less when the environment count is high and grows predictably, because a per-environment or per-apply bill scales with usage while the Terrakube platform cost grows more slowly. It also favors teams that already run Kubernetes and have operators comfortable with Helm charts, since the Terrakube documentation describes Helm and Docker Compose installs and the platform then sits on skills you already pay for. Usage that is steady makes capacity planning simple, and a fixed number of executors may be enough. Ask your platform team to estimate hours per month for upgrades and on-call support, then compare that figure with the quote, not with the license line alone.
Self-hosting tends to cost more for small teams with a handful of environments, few applies per week, and no platform engineers. In that case the fixed effort of running a database, an identity integration, executor capacity and upgrade testing is spread over very little usage, and an hour of an application engineer's time is expensive. The gap also widens when no one owns the platform after go-live. Before you decide, confirm whether env zero's quote is genuinely higher than your internal run cost, and include the exit cost of moving state out of env zero, which the state migration guidance covers in detail.
Which cost components sit on each side of the comparison?
This table sets each cost component of env zero against the same component in a self-hosted Terrakube and OpenTofu setup, and marks whether it is paid once or recurs. Read it by asking who receives each payment, then compare the recurring rows, since those decide the long-term difference. Exact env zero prices are not published in the sources used here, so confirm them in a written quote.
| Cost component | Commercial side (env zero) | Self-hosted side (Terrakube with OpenTofu) | One-time or recurring |
|---|---|---|---|
| Subscription or license | env zero charges per environment or successful apply; paid to env zero | Terrakube and OpenTofu are free software under Apache 2.0 and MPL-2.0; no license fee | Env zero recurring; self-hosted none |
| Infrastructure | Included in the vendor's hosted service | Compute, database and networking in your cloud account; paid to your cloud provider | Recurring |
| Implementation | Onboarding and configuration by your staff or the vendor | Helm or Compose install, identity, VCS and runner setup; your staff or DeployOpen | One-time |
| Migration | Moving state and environments in or out; your staff | State export, workspace recreation and cutover; your staff or DeployOpen | One-time |
| Support | Included in the subscription tier; paid to env zero | Internal on-call or a DeployOpen retainer; paid to your staff or DeployOpen | Recurring |
| Upgrades | Handled by the vendor | Terrakube releases and database changes tested and applied by your team or DeployOpen | Recurring |
| Internal skills | Smaller platform team needed for daily runs | Kubernetes, database and identity skills in-house; paid to your staff | Recurring |
| State and backup storage | Hosted by env zero; included in the subscription | Your own database and object storage with backups; paid to your cloud provider | Recurring |
What moves the cost of each side up or down?
Env zero bills on environments and successful applies, while Terrakube is free software that you run on your own compute and database. The cost gap therefore depends on how many environments, runs and teams you operate, and how much platform engineering time you can spare to keep the stack running.
Number of environments or workspaces
Env zero's cost grows with the number of environments it manages, so a large estate of short-lived or per-team environments pushes the commercial side up. On the self-hosted side, more workspaces add database rows, executor jobs and state volume, which are small compared with the operational work of organizing them. Ask env zero for its current environment billing terms in writing, and count your active workspaces, including those that exist only for testing.
Successful applies per month
Env zero's billing is tied to successful applies or environments, so teams that deploy frequently face rising usage charges. With Terrakube, run volume raises executor capacity, log storage and runner load, but not a per-run fee. Measure your monthly successful applies over a typical quarter, including peaks around releases, and estimate the executor capacity that peak needs.
Number of teams and users
Commercial platforms often price or gate seats and roles differently from what your organization expects, so adding teams can change the bill quickly. Terrakube assigns permissions on workspaces, modules and VCS connections by group, which fits a directory-driven model but requires you to design the group structure and identity provider integration yourself. Confirm which users and roles env zero counts toward your plan.
Cloud accounts and regions
Each additional cloud account, region or data residency boundary can require its own runners, network paths and credentials. In env zero, these are often covered by the platform's runner model, which you pay for through the subscription. In Terrakube, each boundary needs executors and secrets placed inside it, which adds infrastructure to build and patch. Map your accounts and regions before comparing the two quotes.
Availability and recovery requirements
Higher availability targets raise the self-hosted cost, because a production Terrakube deployment needs a highly available database, redundant executors, tested backups and a documented restore procedure. Env zero carries that operating burden as part of the service. Ask what availability and recovery commitments env zero provides in its contract, and specify the same targets for your own design so the comparison is like for like.
Platform engineering skills in house
The self-hosted cost depends heavily on staff time. Teams that already run Kubernetes, PostgreSQL and CI pipelines can absorb Terrakube operations with modest added effort, while teams without that experience will pay for training, an implementation partner or ongoing support. Count the hours your engineers would spend on upgrades, identity changes and incident response each month, and put that figure next to the env zero subscription.
How env zero's pricing model shapes the bill
env zero bills on an environment-based model rather than a flat seat or per-resource fee, so the size of the bill depends on how many environments you run, how often they are applied, and which plan you hold. The supplied research does not include env zero's free tier limits or its custom pricing per successful apply or per environment, so no figure appears here. Treat every number as something to confirm in writing with env zero before you compare it with the cost of running Terrakube yourself. Ask for the current price sheet in effect on the date of the quote, not a marketing summary.
The quote should answer five specific questions. First, what is the billing unit: an environment, a successful apply, a run, or a combination, and is it counted per month or per year. Second, what counts as a successful apply, including failed applies, plan-only runs, drift checks and retries. Third, how destroyed or inactive environments are billed, and whether an environment you mark inactive but leave in place still counts toward the total. Fourth, what support levels and SSO capabilities each tier includes, since identity integration is often gated by plan. Fifth, how price changes are handled at renewal, including any notice period, caps on increases and the right to move plans mid-term.
Ask env zero to model your actual usage. Export a count of environments and applies for the last 12 months from your current tooling, then request a quote based on that data and on a growth scenario you define, labeled as illustrative in your own planning. On the self-hosted side, the recurring costs are the compute and database that run Terrakube, the staff time to operate it, and any extensions you adopt, while the software itself is free under Apache 2.0. Those costs also scale with usage, so the comparison should be made on the same workload for the same period.
What running Terrakube costs in each component
Terrakube is licensed under Apache 2.0, so the software itself carries no license fee. Terrakube does not charge per managed resource, per run or per environment. Your software line is therefore the staff time needed to evaluate, pin, test and upgrade the platform, along with the IaC CLI you choose to run beside it.
- License fee: Apache 2.0 means no license charge from Terrakube itself, at any scale of workspaces or runs.
- Release tracking: The latest release supplied is 2.33.2, released September 14, 2026. Confirm which release your team tests against before you upgrade.
- CLI choice: Terrakube runs both Terraform and OpenTofu. Your CLI choice affects your long-term licensing position, so record it in the design decision.
- Recurring effort: Upgrades, changelog review and regression testing recur for as long as the platform runs, and they are the main software line to budget.
Confirm the license terms and current release details in the Terrakube GitHub repository on the day you begin your evaluation.
Terrakube documents installation with a Helm chart or Docker Compose, and it is tested with minikube. Hosting cost therefore depends on whether your platform team already runs a Kubernetes estate or prefers virtual machines. Authentication runs through Dex, which connects to identity providers such as Azure Active Directory, Amazon Cognito, GitHub and SAML, and assigns permissions by group.
- Kubernetes installs: The Helm chart fits estates that already run clusters, so the marginal cost is capacity, not a new platform.
- Docker Compose installs: Compose suits smaller or evaluation environments, but you own the availability design and patching.
- Identity through Dex: Dex connectors and group mappings are configured by you, which adds design and support work in exchange for group-based access on workspaces, modules and VCS connections.
- Operational overhead: Backups, TLS certificates, monitoring, log retention and disaster recovery recur with the hosting footprint.
Ask your platform team which Helm chart version and Dex connectors fit your identity provider, and confirm how the cluster capacity is already charged internally.
Terrakube supports any relational database that Liquibase supports, including PostgreSQL, MySQL, Oracle and SQL Server. The database cost depends mostly on the engine you already operate and the license terms attached to it. A team that already runs PostgreSQL with a standard support model has a different cost profile from one that must add a commercial database engine.
- Open-source engines: PostgreSQL and MySQL carry no license fee for the database software, although hosting and support still cost money.
- Commercial engines: Oracle and SQL Server licensing follows your existing agreements, so confirm whether Terrakube use falls under current entitlements.
- High availability: Replication, failover testing and point-in-time recovery add cost that grows with the required recovery objectives.
- Schema changes: Liquibase manages schema changes, so plan for upgrades that alter the schema and test them in a non-production copy first.
Ask your database team which engine, high availability model and backup retention they already support, and whether a new instance for Terrakube would be an added cost or part of an existing service.
Executors are where Terrakube runs plans and applies, so they carry most of the compute cost. The supplied documentation does not give a full executor model, so confirm the executor architecture, concurrency controls and image management in the documentation for your release. Your compute bill follows how many workspaces run at the same time and how long each run takes.
- Concurrency: More workspaces that run at once require more executor capacity, which is the largest driver of compute spend.
- Provider credentials: Executors need access to cloud credentials. Scope those credentials per environment, which adds design and rotation work.
- Binary versions: Pinning Terraform or OpenTofu versions per workspace adds image maintenance when new CLI releases arrive.
- Scaling model: Autoscaling on Kubernetes can lower idle cost, but it adds monitoring and tuning effort.
- Patching: Executor images require regular rebuilds and patching, which recurs with each CLI or base image update.
Ask your platform team for the expected peak number of concurrent runs and how each executor's compute is charged in your environment.
Terrakube extensions add tools to runs, including OPA policy checks and Infracost cost estimates, and the Terrakube API supports custom integrations. Each extension adds run time and some maintenance, and the cost depends on which controls your organization requires. Policy and cost controls that a commercial platform bundles must be built, tested and maintained by your team when you run Terrakube yourself.
- OPA policy checks: You write, version and test the policies, so the cost is the policy engineering effort plus the extra time each run takes.
- Infracost estimates: Cost estimates add a step to each run. Confirm the Infracost terms, any account or key requirement, and the pricing data you need for your cloud providers.
- Custom API integrations: Ticketing, chat or approval systems that call the API need development and ongoing support when the API changes.
- Policy governance: Owners must review and update policies as standards change, which is a recurring effort.
- Run time: Every added check lengthens the run, which can matter for teams that expect fast feedback on pull requests.
Before you budget, list the controls you need today, then confirm each extension's requirements and support model with its maintainers.
How to build the comparison with your own numbers
This sequence turns the cost components in this comparison into a worksheet built from your own environment counts, written quotes and internal rates, so the three-year totals reflect your organization rather than an estimate.
Count environments, workspaces and monthly applies
Pull your env zero usage data for the last several months and record how many environments are active, how many workspaces sit behind them, and how many successful applies run each month. Note which environments are short-lived, such as per-branch or per-ticket environments, because they drive billing differently from long-lived production stacks. Your platform or cloud team owns this step, and the output is a single table of environments, workspaces and monthly applies by month. You know it is done when the totals reconcile with the invoices or usage reports you already receive from the vendor.
Obtain the env zero quote in writing
Ask env zero's sales team for a written quote based on your environment counts, apply volume, user seats, support level and any contract term they propose. Ask them to state how each billing unit is defined, whether unused capacity carries over, and how renewal increases are capped or calculated. Procurement or finance owns this request. The output is a dated quote document that lists each recurring line item, and you know it is done when every line has a unit, a quantity and a term.
Price Terrakube hosting from your rate card
Using your cloud provider or data center rate card, price the compute for the Terrakube API and UI, the PostgreSQL or other supported relational database, object or block storage for state and logs, network egress, backups and the executor capacity that runs plans and applies. Use the database engines that Terrakube's documentation lists through Liquibase as the reference for what you must support. Your infrastructure team owns this step, and the output is a monthly and annual hosting estimate with each component named. You know it is done when the estimate shows how it changes if apply volume doubles.
Scope DeployOpen implementation and migration
If you want outside help, request a written fixed scope from DeployOpen that covers the Terrakube deployment, identity integration, VCS connections, the state migration path, workspace and variable recreation, extensions you need, and handover documentation. DeployOpen does not publish prices, so the quote follows from that scope. Your sponsor and the DeployOpen team own this step. The output is an agreed scope document with deliverables and a timeline, and you know it is done when each cost in your model maps to a named deliverable in that document.
Estimate internal skills effort by role
List the internal roles that will carry the work, such as platform engineers, security engineers, and the people who own the existing pipelines and modules. For each role, estimate the hours for migration, ongoing upgrades of the IaC CLI and Terrakube, on-call support for runners, and access reviews. Ask your managers to validate the numbers against current capacity. The output is an hours-by-role table with one-time and recurring rows separated, and you know it is done when the total hours are multiplied by your internal loaded rates in a documented way.
Set a three-year horizon and separate costs
Build a three-year model with one column per year and three groups of rows: one-time costs such as migration, implementation and training; recurring costs such as hosting, database, storage, support retainers and internal operations; and vendor costs such as the env zero subscription. Keep the env zero line and the Terrakube line in the same currency and period so they compare directly. Finance and the platform lead own this model. You know it is done when each cost sits in exactly one group and the two options produce a three-year total you can explain line by line.
Run sensitivity checks on growth and renewals
Change the environment count, monthly apply volume and renewal increase in the model, one at a time and then together, and record how each change moves both totals. Include a scenario where your environment count grows faster than your headcount, and a scenario where the vendor renewal rises by an amount you set from the written quote terms. Test whether the hosting estimate still holds at higher executor concurrency. The output is a short table of break-even points and the variables that move the decision most. You know it is done when you can state, in plain terms, which input would change your decision.
What do buyers ask before costing a Terrakube move?
How much effort does a move from env zero to Terrakube take?
The effort depends mostly on how many environments, workspaces and variable sets you run, how many templates and approval policies need rebuilding, and how many VCS connections must be recreated. A small estate with a few workspaces and direct CLI use is far simpler than one with dozens of templates, cost policies and per-environment variables. Ask for an inventory of environments, templates, policies and runners before anyone commits to a number. Terrakube's own documentation covers workspaces and CLI-driven runs, so the work is mainly configuration, testing and cutover planning rather than new tooling.
Can our own team migrate to Terrakube without outside help?
Yes, a team with Terraform or OpenTofu experience and access to its own cloud and Kubernetes or Docker hosts can usually do it alone, provided it has time to learn the platform and test the result. The main risks are not the tooling but the gaps: rebuilding approval flows, cost governance and environment lifecycle, which env zero handles for you and Terrakube handles through its own features and extensions. An outside partner is most useful when the team lacks capacity for a parallel run or needs an independent review. Confirm the skills you have in-house before deciding.
What people does a Terrakube migration need from our side?
Plan for three roles. Platform engineers own the Terrakube deployment, runners, OpenTofu or Terraform versions and the CLI workflow. A database owner manages the relational database that Terrakube uses, since it supports any database Liquibase supports, including PostgreSQL, MySQL, Oracle and SQL Server, along with backup and access. A security reviewer checks identity configuration through Dex, group-based permissions on workspaces and VCS connections, and how credentials and state are protected. In small teams one person may cover two roles, but each role still needs named time during the cutover.
How long does an env zero to Terrakube migration run?
Length is set by the number of environments to move, the number of approval and policy rules to recreate, how long parallel running lasts, and how much change control your organization requires before cutover. Each environment is migrated in turn, verified with a no-change plan, and then marked inactive in env zero without destroying its resources. No duration figure has been supplied for this work, so ask any provider for a timeline in writing, based on your inventory and the scope agreed before work starts. Ask how they count testing and rollback time.
Does choosing OpenTofu instead of Terraform change the cost?
The software licence cost is zero for both, because OpenTofu is an MPL-2.0 fork under the Linux Foundation and Terrakube is Apache 2.0 licensed. What changes is the compatibility and tooling work. Terrakube documents running both Terraform and OpenTofu, and Terraform moved to the Business Source License with version 1.6.0, so the choice affects future licensing risk rather than today's invoice. Confirm the exact version you will run in each workspace, and check that your providers, modules and any state encryption setup work with it before you commit.
How should we handle state during the migration?
Treat state as the first thing to move and the last thing to change. Each env zero environment's state is read through its remote backend, backed up locally, then moved to the new backend with the migrate-state step. After the swap, run a plan that should show no changes before you retire the old environment. The step-by-step path is described in the write-up on how to move state out of env zero, which covers login, backup, backend changes and verification. Keep the old state until several plans have run cleanly.
What does ongoing Terrakube support cost compared with a retainer?
Ongoing cost has three parts: your own platform engineers' time for upgrades, runner capacity, database operations, backups and security patching, the infrastructure that hosts Terrakube, and any external support you buy. A retainer replaces some or all of the operational time with a defined service, and DeployOpen offers ongoing support, upgrades and continuous testing on that basis. Ask any provider for the recurring scope in writing, what is included in each upgrade cycle, and how incidents are handled. DeployOpen does not publish prices, so a quote follows from the written scope.
How DeployOpen scopes a fixed-price Terrakube implementation
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For env zero cost vs self-hosted Terrakube, we start from your current env zero usage and agree a written scope before any work begins.
How we scope
- We inventory env zero environments, templates, variables, VCS connections and runner setups before estimating anything.
- The written scope lists which workspaces, state backends and Terrakube components are in and out of the engagement.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts, and we quote from that scope.
How we build
- We deploy Terrakube with Helm or Docker Compose in your environment, with the relational database and identity provider you choose.
- We configure Dex-based authentication and group permissions for workspaces, modules and VCS connections against your directory.
- We test a no-change plan on migrated workspaces and run security tests against the Terrakube deployment before cutover.
How we hand over
- You receive documentation covering architecture, workspace inventory, access model, backup and restore steps.
- We walk your platform and security teams through runbooks for approvals, extensions such as OPA and Infracost, and upgrades.
- Compliance readiness evidence is prepared for your independent auditor, since DeployOpen does not issue audit reports or certifications.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainer scope, response expectations and upgrade cadence are defined in writing so you can compare them with your current contract.
- Ask us to confirm which env zero cost drivers remain on your side, such as runner compute and database hosting, before signing.
