Is Spacelift cost worth replacing with self-hosted Terrakube?
Replacing Spacelift removes its annual subscription from the budget, while infrastructure, migration and operations move to your side of the ledger. Terrakube is licensed under Apache 2.0, so the software itself carries no license fee, and version 2.33.2, released September 14, 2026, is the release to evaluate. What you still pay for includes the Kubernetes or Docker hosts, a relational database supported by Liquibase such as PostgreSQL, executor capacity, the staff time to install, upgrade and back up the platform, and the migration project. Spacelift's Starter+ plan is listed at $20,000 a year, while its Enterprise tiers are quoted with pricing tied to workers, so the comparison depends on a written quote you have not yet received.
Self-hosting tends to cost less only when your team already operates Kubernetes or Docker and has run-time demand that fits a self-managed platform. In that case Terrakube adds a workload to clusters you already patch, monitor and back up, and the marginal cost is mostly compute and database capacity. It tends to cost more when the team does not run either platform today. Then the first year carries cluster build-out, database operations, identity integration with your provider, and the learning curve for every engineer who depends on shared modules. Run volume cuts both ways: a handful of runs may not justify dedicated infrastructure, while many concurrent runs raise executor and database sizing. Illustrative example: a team with one existing cluster and a few dozen workspaces faces a very different calculation from a team building its first platform for a large estate.
Which cost components change when you move from Spacelift to Terrakube
This table lists each cost component that changes when a team moves from Spacelift's annual subscription to self-hosted Terrakube, who is paid for each one, and whether it recurs. Terrakube's software carries no license fee, so the comparison turns on infrastructure, operating staff and migration effort. Ask for a written scope and a quote for each row before comparing totals.
| Cost component | Spacelift (commercial) | Terrakube (self-hosted) | One-time or recurring |
|---|---|---|---|
| Subscription or license | Annual subscription. Starter+ is listed at $20,000 a year; Enterprise is quoted around workers | Apache 2.0 software with no license fee | Recurring for Spacelift; none for the software |
| Workers or executors | Workers included in the subscription tier or priced in the quote | Executors you size and run on your own compute | Recurring compute; size drives the cost |
| Kubernetes or Docker hosting | Not needed for the SaaS service; confirm any self-hosted option is a separate quote | Kubernetes through the Helm chart, or Docker Compose on hosts you manage | Recurring cloud or server cost |
| Relational database | Included in the managed service | Any Liquibase-supported database, such as PostgreSQL, that you provision, back up and patch | Recurring hosting, backups and patching |
| Identity and VCS integration | Included in the subscription; confirm SSO and VCS coverage in the quote | Dex with Azure Active Directory, Amazon Cognito, GitHub or SAML, plus GitHub, GitLab, Bitbucket and Azure DevOps | One-time setup, then recurring group and access reviews |
| Migration | Export of state, stacks, contexts and policies; effort depends on stack count | Recreate workspaces, variables and VCS connections; translate Rego policies | One-time; ask for a fixed-scope estimate |
| Support | Included according to subscription tier; confirm response terms in writing | Upstream project support varies; ongoing help comes from a retainer or in-house staff | Recurring if you buy a retainer |
| Upgrades | Handled by the vendor for the managed service | Your team tests and applies Terrakube and OpenTofu releases | Recurring staff time for each release |
| Internal skills | Fewer platform skills needed for day-to-day operation | Kubernetes or Docker, database, identity and CI skills to run the platform | Learning curve is one-time; upkeep recurs |
What the Spacelift subscription covers and how it is quoted
Spacelift is sold on annual subscriptions, so the first cost question is which tier your organization sits in and how the contract renews. The Starter+ tier is listed at $20,000 a year. Higher Enterprise tiers are quoted individually and priced around the number of workers you run. The figure on your invoice therefore depends on worker count, support level and the terms in your order form, and a public list price does not settle the question. Treat the Starter+ listing as a reference point only and build your cost model from the signed contract.
The subscription buys more than a seat count. It also pays for the managed control plane, state and runs, so each of those functions needs its own line in your comparison before you set Spacelift against Terrakube. List the control plane (run scheduling, the web interface, the API and version control integrations), the state backend and locking, the run execution itself on Spacelift infrastructure or on your private workers, and the policy, audit and notification features your teams use. For each function, record who operates it today, what it costs in staff time, and what you would need to build or buy to replace it. Functions you cannot name yet are the ones most often missed in a migration estimate.
Ask for the current terms in writing before you rely on any figure in this section. Confirm the tier and list price on your order form, the number of workers included and how extra workers are billed, the term length, and any renewal uplift along with the notice period for changing it. Also confirm which support and state or configuration export assistance is included, since those matter if you later move workloads. Your signed contract is the authoritative source for renewal cost, so carry its numbers into the cost model in the sections that follow.
How to build the cost comparison with your own numbers
This sequence turns the cost question into a like-for-like model built from your own Spacelift quote, your run volumes and your cloud bills, so the comparison reflects your environment rather than a generic estimate.
Inventory stacks, workspaces and runs
The platform or DevOps lead counts every Spacelift stack and every Terraform or OpenTofu workspace you would need to carry over, and records how many runs each one triggers per month, split into plans, applies and drift checks. Include stacks that are idle but still scheduled, since they still consume capacity. The output is one table with a row per stack, its runs per month and its peak concurrency. The step is done when the totals reconcile with the usage view in your Spacelift account.
Record the workers and resources in use
Using your Spacelift contract and any worker pool configuration, the platform lead notes how many private workers run, their size, and whether any are sized for peak load only. Ask your account team to confirm how the current plan prices workers and what counts toward your tier, and write those terms down in your own words. The output is a worker inventory with compute size and count. The step is complete when someone outside the platform team can read it and explain what drives the subscription line.
List the Spacelift functions you depend on
Platform engineering and security list every Spacelift feature your teams use day to day, such as policy checks, contexts, drift detection, approvals, notifications, VCS integrations, and any use beyond Terraform or OpenTofu. For each function, note the owner, the frequency of use and what would replace it. This list is where hidden cost usually sits, because a function you cannot replicate can change the total more than the license line does. The output is a dependency register. The step is done when every function has either a named replacement or a documented decision to drop it.
Price the self-hosted side by component
Infrastructure and platform engineers price each component of a self-hosted setup separately: compute for Terrakube and its executors, a managed or self-run PostgreSQL database, ingress and load balancing, backups and their storage, identity integration, monitoring, and any extensions you choose to run. Terrakube itself is open source under Apache 2.0, so the license line is zero, but the server and database costs are not. Take the figures from your own cloud bills or internal chargeback rates, and ask any provider for written pricing. The output is a monthly cost sheet per component. The step is complete when each line names its source.
Add one-time migration and internal effort
Separate the one-time costs from the recurring ones. One-time items include recreating workspaces, variables and VCS connections, translating policies, exporting state, parallel running and cutover, and any external implementation work you contract. Internal time for engineers, security reviewers and change managers belongs here too, priced at your own loaded rates. Ask any implementation partner for a fixed-scope written quote, since scope determines effort. The output is a one-time cost sheet with effort in person-days per workstream. The step is done when every workstream has an owner and a rate.
Set a horizon and compare annual totals
Choose the number of years you want to compare, and agree on it with finance so the model is not tuned to a preferred answer. For each year, add the recurring self-hosted run costs and the ongoing internal operations effort, then add one-time costs in the first year. Compare that with the annual Spacelift subscription, including any expected renewal change, shown as annual totals side by side. Include a sensitivity line that shows how the result moves if run volume or worker count grows. The output is a yearly comparison table with a stated assumptions list. The step is complete when a reviewer can change one input and see the result update.
Validate the model against your quote and bills
Before the model goes to a decision meeting, the CFO's delegate or procurement lead checks each input against a source document: the signed Spacelift order form, your cloud invoices, and the written migration quote. Any figure without a source is marked as an assumption and reviewed. Only the figures in those documents should drive the result, since prices differ by contract and region. The output is a reviewed model with source references for each input. The step is done when the decision-makers accept the assumptions and the open questions are assigned owners.
What moves the comparison up or down
Spacelift's cost is set by a contract, while Terrakube's cost is set by the infrastructure and people you commit to it. Six drivers decide where your total lands, and most of them scale with how many workspaces you run and how many of them run at once.
Workspaces and run volume
Every stack or workspace you bring over adds plans, applies, drift checks and state to manage. On the Spacelift side, check how your quoted edition and run allowance count these. On the Terrakube side, more workspaces mean more database rows, more executor time and more VCS webhook traffic. Ask Spacelift how runs are counted, then estimate your own monthly run volume from your pipelines before comparing.
Workers and executors for concurrency
Spacelift sells private workers as a quoted component, so more parallel runs usually means more workers under contract. Terrakube has no equivalent license line, but you pay for the compute that runs executors, sized to your peak concurrency. Teams with many simultaneous merges should model the peak, not the average, and confirm with Spacelift how its worker count is quoted.
Spacelift edition and quoted worker count
Spacelift's Starter+ tier is listed at a fixed annual price, while Enterprise tiers are quoted and tied to workers. A larger worker count moves the subscription up, and a self-hosted Spacelift deployment is offered only on Enterprise+. Request the written quote with the edition, worker count, support level and renewal terms stated separately, so you can compare line by line.
Availability and high availability database
A production Terrakube deployment needs a database that survives failure, along with multiple application replicas behind a load balancer and backups that you have tested. Those components cost money to run and time to operate, and they are the largest hidden item in a self-hosted comparison. A single-replica test install is cheaper, but it is not a fair baseline for a service that teams depend on daily. Confirm your uptime expectations before you size the cluster.
Identity and VCS integration effort
Terrakube uses Dex to connect identity providers such as Azure Active Directory, Amazon Cognito, GitHub and SAML, and it maps groups to permissions on workspaces, modules and VCS connections. It also integrates with GitHub, GitLab, Bitbucket and Azure DevOps. Each identity provider and each VCS platform adds configuration and testing work. Count the integrations you need on day one, and check whether your group structure maps cleanly to Terrakube permissions.
Existing Kubernetes skills
Terrakube documents installation with a Helm chart or Docker Compose, so the platform itself is accessible to teams without deep cluster experience. Running it reliably at scale still requires people who can operate Kubernetes, manage upgrades, rotate secrets and respond to incidents. If that skill sits in your platform team already, the operating cost stays mostly internal. If it does not, budget for hiring, training or a support retainer, and ask any implementation partner to name who will operate the system after handover.
Who operates Terrakube and what that costs in each model
A team that already runs Kubernetes, has on-call rotations and keeps a database service running will absorb Terrakube into its existing routines. The main cost is staff time, not licences. Terrakube installs with a Helm chart or Docker Compose, so the deployment fits into current cluster tooling, but someone still owns each layer the platform depends on.
- Patching: Internal staff apply Terrakube image and chart updates, and they track the Terrakube releases page and the Dex and executor components that ship with it.
- Database backups: Your existing PostgreSQL or other supported database operations team sets backup schedules, retention and restore tests for the Terrakube database.
- Credential rotation: Platform staff rotate VCS tokens, cloud credentials used by executors and the identity provider client secrets, and they record each rotation for audit.
- Upgrades: Staff test each Terrakube and OpenTofu version against a non-production workspace before promoting it, and they plan rollbacks.
- Where a partner fits: A fixed-scope implementation can cover the initial deployment, hardening and runbooks, while your team keeps routine operations.
Confirm that on-call coverage includes Terrakube as a named service and that someone can restore the database within your recovery targets.
An organization without a platform team usually has no one who owns Kubernetes, database recovery or secret rotation. In this model, Terrakube is an additional production system that someone must run, and the software is free while the operating work is not. Many teams in this position choose a fixed-scope implementation followed by a retainer for upgrades and monitoring.
- Patching and upgrades: Without a retainer, a named internal owner must watch releases and schedule changes, which often slips when the owner is busy with other work.
- Database backups: Someone must configure backups and test restores, because an untested backup gives no recovery guarantee.
- Credential rotation: Tokens for GitHub, GitLab or Azure DevOps, plus executor cloud roles, need an owner and a calendar, or they expire during an incident.
- Fixed-scope work: A written scope can cover architecture, installation, identity integration with Dex, VCS connections and handover documentation, with the agreed deliverables and timelines set in advance.
- Retainer: Ongoing support, upgrades and testing can be contracted separately, so the cost recurs at a level set by the agreed scope.
Ask any partner to state in writing who responds to a failed run, who restores the database and how upgrades are approved.
In an air-gapped network, Terrakube cannot pull images, providers or modules from public registries during a run, so every dependency must be mirrored inside the boundary. Operating work grows because updates arrive by controlled transfer rather than by pulling from the internet. The cost difference from connected models is mostly in the time needed to validate and move each change.
- Patching: Staff must mirror container images, Helm charts and any extension images into an internal registry, then verify them before deployment.
- Providers and modules: Terraform and OpenTofu providers, plus module sources, need an internal mirror or private registry, which the Terrakube registry can host for modules and providers.
- Credential rotation: Secrets that cannot reach a cloud secrets service may need internal vault tooling, and rotation schedules depend on how changes cross the boundary.
- Backups: Backup copies often need to stay inside the enclave, so storage location and restore testing are part of the design.
- Partner role: A fixed-scope engagement can cover the offline bundle process, mirror setup and the upgrade procedure, which is a common reason to bring in outside help.
Confirm with your security team how software and state transfers are approved, because that approval sets the realistic pace of every upgrade.
What migration adds to the one-time cost
The migration work is the largest one-time cost after the platform itself, and it is paid in engineering time rather than licenses. Plan it per stack. Each Spacelift stack needs its state exported, its workspace recreated in Terrakube, its variables and contexts rebuilt, its VCS connection moved, and its plan checked clean before anyone applies from the new home. For state, HCP Terraform exposes a JSON state download through the state versions API for states created by Terraform 1.3 or later, and Spacelift states can be pulled with terraform state pull in a task and written to your own bucket. Confirm which Terraform or OpenTofu version created each state, because older states follow a different export path.
Decide OpenTofu state encryption before any state moves. OpenTofu can encrypt state and plan files on the client using key providers such as AWS KMS, GCP KMS or OpenBao, and the choice of key provider, key ownership and rotation process determines how the migrated state is stored and read. Changing that decision after cutover means re-encrypting every state, so record it in the design before the first export. Policy translation is the other unpredictable item: Spacelift Rego policies must be rewritten for Terrakube, which runs OPA checks through its extensions, and the number of policies and their dependencies on stack metadata drive the hours needed. Cut over stack by stack, starting with low-risk stacks, and treat a clean plan with no unexpected changes as the gate for each one.
Effort scales with the number of stacks, the number of contexts and policies, and how much each stack depends on Spacelift-specific features. Give no assumption about duration in planning until a written scope lists the stacks in scope, the policies to translate, the state backends and the cutover order. Ask the provider to state which items are fixed and which depend on findings during discovery, and ask who performs the parallel run and rollback steps. Remaining run time on Spacelift during the transition also adds subscription cost, so ask how long both platforms will run side by side and what triggers the shutdown.
Questions buyers ask about Spacelift and Terrakube costs
Is Terrakube free to use?
Terrakube's software is licensed under Apache 2.0, so there is no license fee to run it. The cost moves to what the software needs to run. Budget for compute for the Terrakube API, the UI and the executors on your Kubernetes cluster or Docker host, a relational database such as PostgreSQL, storage for state and run logs, backups, monitoring, and the people who install, upgrade and patch the platform. Setup, identity integration and migration are one-time costs. Infrastructure, upgrades and on-call work recur. Price each component in your own cloud account, then set that total beside the Spacelift quote for the same period and scope.
How long does a migration from Spacelift to Terrakube take?
No single duration applies to every team. The length depends on how many stacks you run, how many use private workers or custom hooks, how many contexts, policies and VCS connections must be recreated, how Rego policies are translated, and whether each state file moves cleanly. Plan to cut over stack by stack so unfinished work stays on Spacelift until its replacement plans clean. Ask for a timeline in the written scope, with milestones per batch of workspaces and a clear acceptance check for each one. DeployOpen agrees fixed scopes, deliverables and timelines in writing before work starts.
Can our internal team run this without a partner?
Many teams can, provided the skills already exist in-house. The work needs people who operate Kubernetes or Docker, administer PostgreSQL, configure identity providers and group mappings, hold administrator rights on your version control system, and understand OpenTofu or Terraform well enough to convert policies and state. Confirm who owns on-call, upgrades and security patches before you commit. A sensible first step is a pilot on a small set of workspaces that your team migrates and runs for a period. Bring in outside help when schedules are tight or when one of those skills is missing.
What does Terrakube need from our environment?
Terrakube needs a short list of platform prerequisites, and each one should be confirmed with your platform team:
- A Kubernetes cluster, or a Docker host for Docker Compose, with the Helm chart or Compose install documented in the Terrakube README.
- A relational database that Liquibase supports, such as PostgreSQL, MySQL, Oracle or SQL Server.
- An identity provider supported through Dex, such as Azure Active Directory, Amazon Cognito, GitHub or SAML, with group mapping for workspace, module and VCS permissions.
- Administrator access to GitHub, GitLab, Bitbucket or Azure DevOps to connect repositories.
- Terraform 1.1 or later for the cloud block. Earlier versions can use the remote backend, which also supports migrating state.
Also plan secrets handling for provider credentials and backups for the database and state.
Does Terrakube cover all of Spacelift's features?
Not necessarily, so confirm the match feature by feature. Terrakube documents remote backend and cloud block runs, retrieval of Terraform and OpenTofu code from major VCS providers, a private registry for modules and providers, group-based permissions, and extensions that add OPA policy checks and Infracost estimates to runs. It also offers an API for custom integrations. Spacelift's scope beyond Terraform and OpenTofu, including its managed worker model and its own stack, policy and context features, needs mapping against Terrakube's behavior in your environment. Ask both vendors for a written feature matrix and test the gaps in a pilot before you decide.
How do we compare a Spacelift quote with self-hosted totals?
Put both options on the same term and the same scope. On the Spacelift side, ask for the tier, what it includes, worker or add-on charges, support terms, the contract length and the renewal terms. On the self-hosted side, total the cloud compute, database, storage, backups, monitoring, DNS and certificates, plus the engineering time for installation, migration, upgrades and on-call. Add the outside engagement scope if you use one. Include exit costs for both paths, such as export effort and parallel running. Request a fixed-scope quote from DeployOpen so the comparison rests on written deliverables rather than estimates.
Do we need ongoing support after go-live?
Most teams need some ongoing support, though the amount depends on your own capacity. Terrakube and OpenTofu ship new releases, Kubernetes versions change, databases need patching, and identity and VCS settings drift over time. Decide whether your team carries that work or buys it. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and fixed-scope implementation is agreed in writing before work starts. Whichever route you choose, ask what response times, upgrade cadence and escalation paths are included, and put them in the written scope.
How DeployOpen scopes a fixed-price Terrakube implementation
This sequence turns your current Spacelift cost and workflow into a written, fixed-scope plan for a self-hosted Terrakube deployment inside your own infrastructure, so you can compare the quote against your subscription with the scope in hand.
Review your current Spacelift footprint
DeployOpen starts by listing what you run today: stacks, the OpenTofu or Terraform versions in use, private workers, contexts, policies, VCS connections and the identity groups that need access. You confirm which items are contractual and which are used in practice, so unused subscription features are not carried into the plan. The step closes with a written inventory that you approve, which becomes the baseline for the scope.
Agree the target architecture in writing
Together with your platform and security teams, DeployOpen defines where Terrakube runs, whether through the Helm chart or Docker Compose, which relational database it uses, how Dex connects to your identity provider, and which VCS providers are integrated. The architecture also covers whether you need Atlantis for pull request workflows alongside Terrakube. The output is a written design document that you sign off before any build work begins.
Define deliverables, timelines and exclusions
Most engagements are fixed-scope, so the scope document lists each deliverable, the workspaces and modules included, the migration waves, the acceptance checks and the items excluded. Timelines are agreed in the same document, with dates tied to your change windows. Ask for the exclusions to be stated as plainly as the inclusions, since they are the most common source of cost changes later. Work does not start until both parties have signed this scope.
Build, integrate and harden the platform
DeployOpen deploys Terrakube in your cloud accounts, data centers or air-gapped network, connects it to your VCS, configures groups and workspace permissions, and sets up state storage and any extensions you need, such as policy checks. Hardening covers access controls, secrets handling and network exposure, measured against the internal baseline you agreed in the design. The output is a running environment that passes the acceptance checks in the scope document.
Migrate workspaces and verify plans
Each Spacelift stack is recreated as a Terrakube workspace with its variables and VCS connection. State is exported to your own storage using the approach your team has approved, then imported and checked. Every workspace must show a clean plan in its new home before cutover. The record of each verified workspace is kept as evidence for your change log.
Set up backups and runbooks
DeployOpen configures backups for the Terrakube database and state storage, documents restore steps, and writes runbooks for upgrades, access requests and incident response. Restores are tested in a non-production copy so the recovery steps are proven rather than assumed. The handover package includes the architecture document, runbooks, configuration records and the test results.
Hand over and choose ongoing support
Your team receives training on the platform and the runbooks, and the handover is recorded against the signed scope. Ongoing support, upgrades and continuous testing are available as retainers, which you can scope separately once the initial work is accepted. Ask for the retainer terms in writing, including what is covered at each Terrakube release, before you decide whether to run the platform in-house.
