Spacelift vs Terrakube: which to choose

Spacelift vs Terrakube: which fits your OpenTofu or Terraform team

If your team runs only OpenTofu or Terraform and you want the run platform inside your own network under an Apache 2.0 license, Terrakube is the closer fit. If you need orchestration that also covers other infrastructure as code tools, such as Pulumi, and you would prefer a vendor to operate the control plane, Spacelift is the stronger match. Spacelift suits platform teams that want managed runs, managed state and private workers without carrying the operational load of a self-hosted control plane. The trade-off is an annual commercial subscription and dependence on the vendor's roadmap for policy, scheduling and worker features. Before you decide, list every IaC tool your teams use today, not only the Terraform estate, because that list alone can settle the question.

Terrakube fits when control matters more than convenience. It installs with a Helm chart or Docker Compose on your own infrastructure, stores its data in any relational database that Liquibase supports, and keeps workspace, module and VCS permissions under your administration. Authentication runs through Dex, so you can connect identity providers such as Azure Active Directory, Amazon Cognito, GitHub or SAML and assign access by group. Policy checks with OPA run through Terrakube extensions, so confirm that the extension covers your Rego rules and approval flow before you commit. The remote backend and cloud block let engineers start runs from their own CLI, which keeps existing OpenTofu or Terraform workflows intact. The Terrakube documentation is the place to check each of these against your requirements.

The decision turns on three questions. First, who operates the platform: with Terrakube, your team owns upgrades, database backups, executor capacity and on-call for the run service, so name that owner before you start. Second, which IaC tools you run: Spacelift orchestrates Pulumi and other tools alongside Terraform and OpenTofu, while Terrakube's documented scope is Terraform and OpenTofu runs, so confirm any non-Terraform stacks with the vendor or project. Third, how much policy and identity integration you need, including whether your directory's groups map cleanly to Dex and to the workspace permissions you require. If the answers point to a small platform team, mixed tooling and a preference for managed scope, Spacelift remains the simpler path. If they point to an owned platform under Apache 2.0 for OpenTofu or Terraform, Terrakube is the better fit.

Which option fits which team

This table matches common team situations to the better fit between Spacelift and self-hosted Terrakube, based on capability conditions rather than cost. Read each row as a condition: if it describes your team, the right-hand column names the option that usually fits better and why. Where the answer depends on details only your environment can settle, the reason says what to confirm.

Team situation	Better fit	Reason
Standardized on OpenTofu, with its own Kubernetes cluster	Terrakube	Terrakube installs with a Helm chart or Docker Compose and runs its executors inside your cluster, so runs stay on infrastructure you already operate.
Running Pulumi alongside OpenTofu	Spacelift	Spacelift orchestrates Pulumi as well as OpenTofu and Terraform. Terrakube is built for Terraform and OpenTofu runs, so Pulumi stacks would need a separate runner and state process.
Regulated team that must keep state and runs in its own accounts	Terrakube (confirm with Spacelift's deployment options)	Terrakube runs entirely in your environment and stores state in your database or bucket. Confirm which Spacelift deployment model your procurement and assessor accept before ruling it out.
Team that needs OPA policy checks on every run	Either, after testing	Terrakube supports OPA policy checks through extensions. Spacelift has Rego-based policies built in. Test your existing policies on both before choosing.
Team that relies on Git providers beyond GitHub and GitLab	Confirm for your provider	Terrakube documents integration with GitHub, GitLab, Bitbucket and Azure DevOps. Confirm your exact edition and hosting model with the Terrakube documentation before committing.
Team with no platform engineers to operate a run platform	Spacelift	Spacelift is operated by its vendor. Self-hosted Terrakube means someone owns upgrades, database backups, executor capacity and authentication setup, typically through a retainer or internal staff.
Team that wants OpenTofu and Terraform plus Dex-based SSO by group	Terrakube	Terrakube assigns permissions on workspaces, modules and VCS connections by group through Dex, which suits group-based access models you already run.
Team that needs a private module and provider registry	Terrakube	Terrakube provides a private registry for Terraform modules and providers. Confirm the registry features your module publishing workflow depends on.

Where state, runs and credentials live under each option

Spacelift operates its control plane as a vendor-hosted service, and its private workers run plans and applies inside your cloud account. Run orchestration, scheduling and run history therefore sit with the vendor, while the execution environment sits with you. Self-hosted Terrakube places its API, user interface, executors and database on infrastructure you choose, and it installs with a Helm chart or Docker Compose on any Kubernetes or Docker host. The documentation covers both paths, so your architecture team should review it before deciding.

Control plane ownership: Spacelift hosts scheduling, the user interface and run metadata for you. In Terrakube, all of those components run inside your network boundary.
Execution location: Spacelift private workers run in your environment. Terrakube executors run wherever your cluster schedules them, so node placement and network policy become your responsibility.
Network exposure: with Terrakube you decide ingress, DNS, TLS termination and whether the API is reachable outside the corporate network.
Availability ownership: a vendor incident affects Spacelift's control plane. With Terrakube, uptime depends on your cluster, database and on-call coverage.

Confirm in writing with Spacelift which regions host its control plane and what run metadata it stores. Confirm that your Terrakube executors can reach your version control hosts and cloud APIs from the networks where they run.

What Apache 2.0 and the OpenTofu fork change for licensing

The licensing question for this comparison is less about Terrakube's own code and more about the IaC engine underneath it. Terrakube is licensed under Apache 2.0, and the Terrakube documentation positions it as a replacement for closed-source tools such as Terraform Enterprise, Scalr or env0. Its license permits you to run, modify and redistribute the platform inside your own environment without a per-run or per-resource fee to the software author. The engine is a separate decision. HashiCorp announced on August 10, 2023 that future Terraform releases would move from the Mozilla Public License 2.0 to the Business Source License 1.1, and IBM completed its acquisition of HashiCorp on February 27, 2025. Terraform itself is now under the BSL, so a Terrakube deployment that runs Terraform carries that license for the CLI.

OpenTofu is the MPL-2.0 fork that was created in response to that change by a group including Gruntwork, Spacelift and Harness. It sits under the Linux Foundation and was accepted to the CNCF Sandbox on April 23, 2025. Spacelift helped create the project it now competes with, which is useful context when you read its product terms. Terrakube and Atlantis both document OpenTofu as well as Terraform, so you can choose the engine on licensing grounds and keep the orchestration layer the same. Check whether your legal team needs the MPL-2.0 file-level obligations or the BSL restrictions reviewed for the CLI version you pin in your pipeline.

Confirm Spacelift's current edition terms directly with the vendor before you rely on any statement about its license, support or usage rights, because these terms can differ by plan and change over time. Ask for the written terms that cover running Spacelift in its managed form and any self-hosted or private worker option, and ask how they apply to your data and to exit assistance if you leave. Ask Terrakube's maintainers or your integrator to confirm the license of every extension, module and container image you plan to deploy, since the Apache 2.0 license of the core project does not automatically cover third-party components.

What running each platform asks of your team

Spacelift is operated as a managed service, so your team owns the workers, the policies it runs and the state you keep. Terrakube moves the control plane into your environment, which adds database, cluster and release work to the same people who run your Terraform or OpenTofu pipelines. The cards below show who does each job under each option.

Upgrades and release tracking

Under Spacelift, the vendor ships platform changes and your team tracks their effect on stacks and private workers. Under Terrakube, your team owns every upgrade of the platform, its Helm chart or Compose file, and the extensions you enable. Terrakube 2.33.2 was released on September 14, 2026, so assign someone to watch its GitHub releases and test each new version in a non-production environment before rollout. Also track the OpenTofu or Terraform CLI version pinned in each workspace, because the CLI and the platform move on separate schedules.

Database and Kubernetes operations

Terrakube runs as a set of services backed by a relational database that Liquibase supports, such as PostgreSQL, MySQL, Oracle or SQL Server. Your platform or DevOps team owns the cluster, the database engine, its patching, its high availability design and its capacity planning. Spacelift removes this layer from your estate entirely. Before choosing Terrakube, confirm which database engine your standards allow and whether your Kubernetes platform team has capacity to operate it.

Executor capacity and queueing

Spacelift private workers are a managed part of its pool model, while Terrakube executors are containers your team sizes and scales. Someone must decide how many executors run in parallel, how much CPU and memory each run needs for large plans, and how queued runs are handled when several teams apply changes at once. Under-sized executors show up as slow or stuck runs, so load test with your largest state files before cutover.

Backup of database and state

In Terrakube, the platform database holds workspace metadata and run records, while the state itself lives in the backend you configure. Your team owns scheduled database backups, restore tests and retention rules, and must confirm that state storage is versioned and recoverable. Spacelift keeps state and run history on its side, so you should ask the vendor what export and retention options you rely on. Rehearse a restore of both the database and one state file before you depend on either.

Policy authoring in Rego and OPA

Spacelift policies are written in Rego and attached to stacks for plan, approval, trigger and push decisions. Terrakube runs OPA policy checks through its extensions, so your team owns the policy repository, the test suite for each rule, and the wiring that decides whether a failed check blocks an apply. Teams moving from Spacelift often find that the policy logic transfers but the attachment model does not, so map each Spacelift policy type to a Terrakube check before cutover.

On-call coverage and incident ownership

With Spacelift, the vendor carries the platform side of an outage, and your team handles stack-level failures. With Terrakube, the platform, database and executors all fall to your on-call rota, including out-of-hours failures that block production changes. Name an owner for the control plane, define a severity path for stuck runs and state lock problems, and confirm who can approve emergency applies when the pipeline is down.

How the cost of ownership splits between subscription and operations

Spacelift is a recurring annual subscription, and its cost depends on the edition, the worker terms and the scale agreed in the order form. Before comparing it with Terrakube, ask the vendor in writing which edition covers your stacks, how private workers are counted and priced, what the renewal terms say about price changes, which support tier is included, and whether any self-managed deployment carries separate fees. Those answers define the recurring line you are replacing. Also confirm what happens to the subscription during the overlap period, because most teams run both platforms for some weeks while stacks move across.

Terrakube has no licence fee, since it is released under the Apache 2.0 licence, so its one-time costs are the work of moving. Expect engineering time for exporting state, for example with terraform state pull or the state versions API, for recreating workspaces, variables and VCS connections, and for translating Rego policies into the OPA checks that Terrakube runs through its extensions. Identity setup is also one-time: Dex must be connected to your identity provider and group-based permissions on workspaces, modules and VCS connections must be mapped to your existing teams. Price these items as separate work packages in any quote so you can see which parts scale with the number of stacks.

The recurring costs of Terrakube are the infrastructure and the people who run it. That means Kubernetes or Docker hosts, a database that Liquibase supports such as PostgreSQL, executor capacity sized to your peak concurrent runs, backups, monitoring and time spent tracking upgrades from the Terrakube releases page. The main cost drivers are the number of workspaces, the size of the state files, how many runs happen at once, the number of VCS platforms and the evidence your compliance team needs. A fixed-scope written quote from an implementation partner should list each of these components, the deliverables for each, the handover arrangements and whether ongoing support is a separate retainer.

How a move from Spacelift to Terrakube proceeds

The sequence moves state, configuration and run automation out of Spacelift stack by stack, so each workspace ends in Terrakube planning clean against the same code and state. Your team owns the result at every step, and nothing is switched off until its replacement has passed a plan.

Inventory stacks, contexts, policies and VCS links
Your platform team lists every Spacelift stack, its repository and branch, its attached contexts and environment variables, its Rego policies by type, its triggers and its dependencies on other stacks. The output is a written inventory that maps each stack to a target Terrakube workspace, with secrets flagged for relocation to your own secrets manager. Confirm the inventory with the stack owners before any export begins, because anything left off the list will be missed at cutover.
Export state with a task or external state access
For each stack, the team pulls current state using a Spacelift task that runs terraform state pull, or through external state access if your Spacelift plan includes it, and writes the result to a bucket or store you control. Check that every exported file is versioned and that its checksum matches the source. Confirm the export on the Spacelift side as well, since state must match the last applied run. Detailed commands and checks are covered in the sibling page on exporting state from Spacelift.
Stand up Terrakube and its identity provider
Your team deploys Terrakube with its Helm chart or Docker Compose on infrastructure you operate, connects it to a relational database that Liquibase supports, and configures Dex with your identity provider. Groups are then mapped to permissions on workspaces, modules and VCS connections. The step is done when administrators can sign in, a test group sees only the workspaces it should, and the database and backups have been verified. Confirm the supported database and identity options against the Terrakube documentation before you commit to a design.
Recreate workspaces and variables
For each inventoried stack, the team creates a Terrakube workspace pointing at the same repository and branch, then re-enters variables and secrets from the inventory, with sensitive values injected from your secrets store rather than typed into the platform. Workspaces are created in a non-production environment first. The step closes when every workspace shows the expected variables and VCS connection, and no secret appears in plain text in a configuration file or log.
Translate Rego policies for Terrakube extensions
Your policy engineers rewrite each Spacelift Rego policy as an OPA check that runs through a Terrakube extension, then test each one against saved plan output from known good and known bad changes. Policies that depend on Spacelift-specific inputs, such as stack or run metadata, need an explicit replacement or a documented decision to drop them. The step is done when every policy has a passing and failing test case and the owners have signed off on the rules that remain. Note that Spacelift policy types such as approval or notification do not map one to one, so confirm each behavior in the Terrakube documentation.
Swap private workers for Terrakube executors
Spacelift private workers that reach internal networks, private registries or on-premises endpoints are replaced by Terrakube executors deployed inside the same network boundary, with the same network paths, credentials scope and egress rules. Your network team verifies each path from the executor, not from a developer laptop. The step is complete when executors reach every endpoint the inventory lists and the old workers have been drained of queued runs. Confirm executor scaling and isolation choices against the Terrakube documentation.
Cut over stack by stack and confirm clean plans
Each stack moves in turn: the team points the Terrakube workspace at the exported state, runs a plan, and confirms it shows no changes, or only the changes the team expected. Any unexpected diff stops the cutover for that stack. After the plan is clean, the team disables the Spacelift trigger for that stack, keeps the Spacelift stack and its state in place as a fallback until the owners approve retirement, and records the result. Migration of the remaining stacks follows the same pattern, and the sibling migration page sets out the detailed sequence.

Questions buyers ask before switching from Spacelift

How much does it cost to move from Spacelift to Terrakube?

The software itself is free, because Terrakube is licensed under Apache 2.0, so the cost is the infrastructure it runs on, the database it needs, the people who migrate and operate it, and any ongoing support you buy. Spacelift's subscription ends when you stop paying it, but the one-time migration effort and the recurring platform operations stay with you. The main drivers are the number of stacks, how many variables and contexts you must recreate, how many policies need translating, and whether you also rely on Spacelift features that Terrakube does not replace. Ask for a written scope that lists each of these components and separates one-time work from recurring costs before comparing it with your renewal quote. Our fees are set from that written scope, not from a price list.

How long does a migration from Spacelift take?

The duration depends mainly on how many stacks you have, how complex their dependencies are, and how many workspaces you cut over at a time. Each stack needs its state exported, its workspace recreated with variables, VCS connections and access groups, and a clean plan confirmed before you switch the source of truth. Teams with many stacks usually move them in waves, which means the timeline is set by the batching plan rather than by a single cutover date. Shared state across stacks, custom Rego policies and private workers that reach internal networks add time. We do not publish a fixed duration, so ask for a timeline in the written scope that is tied to a stack inventory.

What does my team need to provide during a Spacelift exit?

Your team needs to provide access and knowledge that only your organization holds. This includes read access to Spacelift stacks, contexts and policies, administrative rights in the cloud accounts where Terrakube will run, and a named owner for each stack who can confirm expected plan output. You also need to decide on identity: Terrakube authenticates through Dex with providers such as Azure Active Directory, Amazon Cognito, GitHub or SAML, and group mappings must be agreed before cutover. Expect your platform or security team to review the design, and expect application teams to test their first plans in the new workspace. Confirm these responsibilities in the written scope so nothing is assumed.

Can our own engineers migrate off Spacelift without outside help?

Yes, a capable platform team can do it in-house, and the OpenTofu migration guidance follows a short sequence: back up state and code, install OpenTofu, initialize and verify the configuration, then test with a small change. The migration is designed to be safe and reversible, which helps when you run it yourself. The harder parts are usually the ones specific to your environment: re-creating Spacelift contexts and Rego policies, replacing private workers with Terrakube executors that can reach the same networks, and handling configurations that share outputs through the terraform_remote_state data source. If your team has spare capacity, a staged internal pilot on a few low-risk stacks is a sensible first step. Outside help makes most sense when the stack count is high or deadlines are fixed.

Does Terrakube replace Spacelift for tools other than Terraform?

No, not directly. Spacelift orchestrates OpenTofu, Terraform, Pulumi and other IaC tools, while Terrakube is built around Terraform and OpenTofu runs, so any Pulumi or other non-Terraform stacks need a separate plan. Terrakube's extensions can add tools such as OPA policy checks and Infracost cost estimates to runs, and its API supports custom integrations, which covers some of the governance a Spacelift user might rely on. Where Spacelift features such as its drift detection or other orchestration workflows are central to your operation, list them in the inventory and confirm the Terrakube equivalent or a custom build before you commit. Gaps should appear in the written scope, not after cutover.

How do we export state from Spacelift without breaking workspaces?

State export is a per-stack task. Teams commonly run terraform state pull inside a Spacelift task and push the result to a bucket they control, or enable external state access, then point the new backend at that copy. Capture the stack settings, contexts and policies alongside the state, because state alone does not recreate the workspace. The key check is that each workspace plans clean in Terrakube before you retire the Spacelift stack, and that no second run writes to the old backend during the switch. Keep the Spacelift state available for a rollback window agreed in the scope. Terrakube's remote backend supports migrating state, which simplifies the cutover for each stack.

Is OpenTofu compatibility guaranteed when we switch?

No, compatibility is not guaranteed in the long term. OpenTofu describes its goal as feature parity with Terraform for future releases, but it states that the community decides which features it adopts, so future Terraform releases may diverge. Today, OpenTofu is positioned as a drop-in replacement that preserves existing workflows and configurations, and the migration overview describes the switch as reversible. Test your provider versions, modules and any Terraform-specific features in a pilot, and pin OpenTofu versions in your pipelines. Because the state and plan encryption feature is OpenTofu-specific, decide early whether you will use it, since it affects key management and recovery.

When staying on Spacelift is the right call

Staying on Spacelift is often the better decision when the platform team does not want to operate the orchestration layer itself. Spacelift is a managed service, so the vendor runs the control plane, upgrades and the stack-level features, while your team focuses on the Terraform or OpenTofu code. With Terrakube, the run API, executors, database, authentication and registry all sit in your Kubernetes or Docker estate, and someone on your side owns their patching, backups, scaling and incident response. Before you decide, count the engineers who would carry that work and ask whether they have the hours to do it well every quarter. Breadth of IaC coverage is the second reason to stay. Spacelift runs OpenTofu, Terraform, Pulumi and other IaC tools in one orchestration model, so a team that also manages Pulumi projects or other tooling can keep one approval, policy and audit process. Terrakube is built around Terraform and OpenTofu runs through the remote backend and the cloud block. If your estate is mostly HCL, that narrower scope is an advantage. If it is not, confirm with the vendors which tools each platform supports today and map each of your repositories to a supported path before you commit. The third case is a requirement to run the orchestrator inside your own environment while keeping a commercial product. Self-hosted Spacelift is offered only on Enterprise+ and is installed into your AWS account with an AWS License Manager license, which is a different cost and support model from open-source Terrakube. If that install path, the vendor support contract and the contractual terms meet your needs, the sibling page Self-hosted Spacelift vs open-source Terrakube compares the two on licensing, portability and support.

How DeployOpen helps evaluate, implement or migrate

DeployOpen approaches Spacelift vs Terrakube as an implementation question: which runs, state and policies must move, and where the self-hosted platform needs its own controls. We plan and build the Terrakube environment inside your own infrastructure, then document and support it. Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.

How we scope

Inventory of Spacelift stacks, contexts, policies, VCS connections and private workers before any build starts
Written mapping of each stack to a Terrakube workspace, with the OpenTofu or Terraform version it uses
Decision record on which Spacelift capabilities Terrakube covers and which need an alternative or a gap plan
Agreed, fixed-scope deliverables and timelines confirmed in writing before work begins

How we build

Terrakube deployed with a Helm chart or Docker Compose into your Kubernetes or Docker host
Identity wired through Dex to your identity provider, with permissions assigned by group on workspaces and VCS connections
OPA policy checks and state handling configured as extensions, with state backend and encryption settings reviewed
Testing of plan and apply behavior per workspace before any production cutover

How we hand over

Runbooks covering workspace setup, executor operation, backup of the database and state, and upgrades
Documented controls and evidence records that your internal teams or external auditors can review
Knowledge transfer sessions so your platform engineers can create and manage workspaces themselves
Cutover checklist per stack, with rollback steps recorded before each move

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the build
Upgrade planning for Terrakube and OpenTofu releases, with testing in a non-production workspace first
Security testing of the self-hosted platform and its APIs on request, as a separate fixed-scope engagement
Regular review of extensions, access groups and state backups as your Terrakube estate grows

Spacelift vs Terrakube

Spacelift vs Terrakube: which fits your OpenTofu or Terraform team

Which option fits which team

Where state, runs and credentials live under each option

What Apache 2.0 and the OpenTofu fork change for licensing

What running each platform asks of your team

Upgrades and release tracking

Database and Kubernetes operations

Executor capacity and queueing

Backup of database and state

Policy authoring in Rego and OPA

On-call coverage and incident ownership

How the cost of ownership splits between subscription and operations

How a move from Spacelift to Terrakube proceeds

Inventory stacks, contexts, policies and VCS links

Export state with a task or external state access

Stand up Terrakube and its identity provider

Recreate workspaces and variables

Translate Rego policies for Terrakube extensions

Swap private workers for Terrakube executors

Cut over stack by stack and confirm clean plans