Self-hosted Spacelift vs open-source Terrakube

Self-hosted Spacelift vs open-source Terrakube: which fits an in-environment IaC requirement

If a security, compliance or data residency requirement says that infrastructure runs, state files and cloud credentials must stay inside your own environment, the choice narrows quickly. Self-hosted Spacelift is offered only on Enterprise+ and is installed into your AWS account under an AWS License Manager license, so you buy a commercial product and operate it in your cloud. Terrakube is Apache 2.0 software that runs on any Kubernetes or Docker host, so the software itself carries no license fee and can sit in a data center, private cloud or air-gapped network. The trade-offs fall into three areas: licensing terms, portability between hosts and clouds, and the vendor support you can contract for.

Licensing is where the two diverge most. With Spacelift, the license terms, renewal conditions and any limits tied to the AWS account determine what you can run and for how long, so get the written terms before you design around them. Confirm whether the self-hosted install still depends on Spacelift-operated services, how upgrades reach the install, and what happens to scheduled runs if the license lapses. With Terrakube, the license question is settled, but the operating question is not: your team, or a partner you contract, owns patching, database backups, identity configuration and the executors. Portability favors Terrakube because the deployment is a Helm chart or Docker Compose stack, while a Spacelift install is tied to the AWS environment it was built for.

The right choice depends on the controls and contracts you must show an assessor. Ask for a data flow diagram that proves state, plan files and cloud credentials never leave your boundary, a written support commitment with response obligations, and evidence that each platform package and image was verified before it entered your network. Your change management process also needs an owner for Terrakube upgrades, which are published on its GitHub repository. If your assessor accepts a self-operated platform with documented support, Terrakube fits. If your contracts require a vendor to carry operational responsibility, Spacelift's self-hosted tier may be the better match, once its license and support terms are confirmed.

What an in-environment IaC platform has to satisfy

Running IaC orchestration inside your own boundary moves four questions onto your team: where runs execute, where state and plans sit, who holds the keys, and how software is verified before it crosses in. The cards below set out what to decide and check for each, whichever platform you choose.

Where runs execute

Terrakube runs plans and applies on executors you deploy, typically on a Kubernetes cluster or Docker host in your own account or data center. Every runner needs network paths to your cloud APIs, module sources and VCS hosts, and it needs nothing from outside the boundary once images are in place. Ask who controls the runner image, its egress rules and its credentials, because those decide whether a run can reach anything it should not.

Where state and plans live

State holds resource attributes, often including secrets, so it needs the same protection as the infrastructure it describes. Decide which database backs Terrakube, which object store or backend holds state, and whether plan files persist between plan and apply. Confirm backup, restore and access logging for each store before the first production run.

Client-side encryption of state

OpenTofu can encrypt state and plan files on the client before they reach any backend, using key providers such as AWS KMS, GCP KMS and OpenBao. This keeps plaintext out of the platform's storage layer, which matters if a database or bucket is shared across teams. Test that the key provider is reachable from executors and that a lost key is a documented recovery path, not a blocker.

Group-based access to workspaces

Terrakube authenticates users through Dex with identity providers such as SAML, Azure Active Directory, Amazon Cognito or GitHub, then grants permissions on workspaces, modules and VCS connections by group. Map your existing groups to platform roles before onboarding, and review who can read state, change variables and approve applies. Confirm how group changes in your identity provider are reflected and how stale access is removed.

Verified images and packages

A restricted boundary needs every container image, Helm chart, provider and module to be pulled, checked and then carried in. Kubernetes lets you pull control plane images in advance and point kubeadm init at a private registry with its image repository option, so the cluster never reaches public registries. Record checksums and provenance for each artifact you import.

Supply chain expectations for energy operators

If you operate high or medium impact BES Cyber Systems, NERC CIP-013-2 asks for supply chain procurement processes that address verification of software integrity and authenticity for vendor software and patches. Open-source tooling still needs that verification step, and it is your process that must show it. Confirm with your compliance team and the regional entity whether this standard reaches your IaC platform, since scope depends on your system categorization.

Where self-hosted Spacelift meets the constraint and where it leaves choices open

Self-hosted Spacelift answers a placement requirement directly: the control plane is installed into your own AWS account rather than Spacelift's hosted environment, so run data, state and credentials stay within a boundary you already govern. The trade-off is the commercial frame around it. Per the vendor, self-hosted Spacelift is offered only on the Enterprise+ tier and is licensed through AWS License Manager. Before you put it on a shortlist, get that tier and licensing model in writing, along with who signs the agreement and how license entitlements are renewed.

Several questions are not answered by the placement alone and should go to Spacelift in writing. Ask which components are installed into the account, which AWS services and container images they use, and who holds administrative access to them. Ask for the upgrade and patch channels: how new releases are delivered, whether you can test them in a non-production account first, how long a version is supported, and whether you can pin a version while you validate changes. Ask what support covers in a self-managed model, including who troubleshoots the installation and what response paths exist when a fault is in the infrastructure rather than the product.

Finally, confirm whether any telemetry, usage reporting or license validation leaves the account. Ask for a list of outbound network destinations the installation needs, whether it works with egress restricted to approved endpoints, and what happens to runs if license checks cannot complete. Record the answers next to the requirements they serve, because they feed directly into your supplier risk review. Open-source Terrakube removes most of these questions because its source and deployment artifacts are inspectable, but the Spacelift path still needs this verification before a decision.

Comparing Spacelift, Terrakube and Atlantis against the constraint

This table compares self-hosted Spacelift, Terrakube and Atlantis on where runs and state live, licensing, portability, identity, policy and support. Read the Apache 2.0 license of Terrakube and Atlantis as covering the software only, since infrastructure, staff and support remain paid costs. Atlantis suits teams that mainly need plan and apply on pull requests and must add a separate state backend. Confirm each vendor cell against your contract and environment before deciding.

Requirement	Self-hosted Spacelift	Terrakube	Atlantis
Where runs and state live	Installed into your AWS account on the Enterprise+ tier; confirm where state and worker data sit	Runs on your Kubernetes or Docker host, with state kept in the database and storage you provision	Runs in your infrastructure; state lives in a backend you add and operate separately
Licensing and cost components	Commercial license delivered through AWS License Manager; price set by the quoted agreement	Apache 2.0 software; you pay for servers, database, executors, staff and any support	Apache 2.0 software; you pay for compute, the state backend, staff and any support
Portability across clouds and hosts	Self-hosted edition is tied to the AWS installation path; confirm other targets with the vendor	Any Kubernetes cluster or Docker host, using the documented Helm chart or Docker Compose	Runs wherever you host it, with a state backend chosen for each cloud or site
Identity integration	Confirm the SSO and group options included in your Enterprise+ contract	Dex with Azure Active Directory, Amazon Cognito, GitHub and SAML; permissions assigned by group	Access controlled through your version control provider and webhook setup; confirm controls with your team
Policy and cost checks	Policy support is part of the platform; confirm OPA scope and cost tooling in your contract	OPA policy checks and Infracost estimates added through Terrakube extensions	Plan output is commented on pull requests; policy and cost checks need add-ons you must confirm
Workflow model	Stacks with managed runs and private workers for each stack	Workspaces driven by the remote backend, the cloud block or version control connections	Pull request plan and apply with directory locking; suited to teams that work mainly in pull requests
Support model	Vendor support under the subscription; confirm response terms in writing	Community project support, plus any third party you contract; confirm before go-live	Community project support; contract separately if production support is required

Deploying Terrakube in AWS, on-premises Kubernetes or an air-gapped network

An AWS deployment places Terrakube inside your own account on a managed Kubernetes cluster, so runs, state and credentials stay within your existing controls. Terrakube installs from its Helm chart, and the Docker Compose path is useful for proving the configuration on a single host before the cluster exists. The main decisions are which AWS services hold each component and how users sign in.

Components: the Terrakube API, UI, registry and executor workloads run as pods, with ingress placed behind your load balancer and TLS policy.
Images: copy the container images into Amazon ECR or another registry in the account, then point the chart values at that registry.
Database: use a managed PostgreSQL service, since Terrakube supports any relational database that Liquibase supports. Confirm the engine version and backup settings with your database team.
State and artifacts: choose the storage backend for state and module artifacts in the documentation, and restrict bucket access with IAM policies and encryption keys.
Identity: connect Dex to your identity provider and map groups to workspace, module and VCS permissions.

Before go-live, confirm the chart version you deploy against the Terrakube releases page and test a run from the Terraform or OpenTofu CLI.

An air-gapped deployment has no route to public registries or chart repositories, so every artifact must be carried across the boundary and checked before use. The Kubernetes side follows the kubeadm workflow: list the control plane images with kubeadm config images list, pull them on a connected staging host, move them across, and point kubeadm init at your private registry with --image-repository. The Terrakube images and chart need the same staging, and you should confirm with the Terrakube documentation which external calls its installation and runs make before you assume the stack works offline.

Staging: pull Terrakube, database, Dex and Kubernetes images on a connected host, then push them to an internal registry inside the boundary.
Control plane: run kubeadm config images list and kubeadm config images pull in staging, then use --image-repository during kubeadm init.
Chart and modules: vendor the Helm chart and any Terraform or OpenTofu providers and modules into the enclave, since the private registry depends on them.
Identity: use an internal directory, because external identity providers will not be reachable.
Testing: validate the chart on minikube in a connected lab first, then repeat the install inside the enclave.

Treat every transfer as a controlled change, and confirm the offline behavior of each Terrakube component with the vendor before you commit to the design.

How to stand up Terrakube under the constraint, step by step

This sequence takes a team from confirming that its environment must stay inside its own boundary to a tested Terrakube install, with identity, state encryption and a state migration path in place before any production workspace moves.

Confirm the constraint and its owners
Before any install, write down the boundary the platform must stay inside: which cloud accounts, data centers or air-gapped networks, which data classes are in scope, and whether any requirement such as NERC CIP-005-7 or CIP-013-2 applies. Name the owner for each decision, including security, compliance, the platform team and the identity team. The step is done when the owners sign off a one-page scope statement that lists where state, plans, logs and credentials may live.
Test on minikube or a staging cluster
Install Terrakube on a minikube or staging cluster that matches your production Kubernetes version as closely as possible, and pin the release you test. The current release listed on the GitHub releases page is 2.33.2, so record that tag in your change log and confirm the upgrade path between releases with the Terrakube maintainers before production. The step is done when a sample workspace runs a plan and apply through the API, and the test cluster has been rebuilt from your own manifests at least once.
Pick the database and object storage inside the boundary
Terrakube supports any relational database that Liquibase supports, including PostgreSQL, MySQL, Oracle and SQL Server, so choose the engine your database team already runs and can back up and restore. Choose object storage for module and plan artifacts that sits inside the same boundary, and confirm with the vendor or your storage team which S3-compatible or native option fits. The step is done when both services are provisioned in the approved network, reachable only from the Terrakube namespace, and a restore test has succeeded.
Mirror all container images and charts into a private registry
Pull every container image and the Terrakube Helm chart, plus the images for Dex, the database and any extensions you plan to use, then push them to your private registry. For clusters with no internet access, Kubernetes documents pulling control plane images in advance and pointing kubeadm init at a private registry with the --image-repository flag, and the same discipline applies to application images. The step is done when the cluster can deploy the full stack with egress to the public internet blocked, and every image digest is recorded in your inventory.
Install with the Helm chart or Docker Compose
Install Terrakube with the Helm chart for Kubernetes, or with Docker Compose if your target is a single Docker host, and keep the values file in version control with secrets referenced from your secrets manager rather than typed into files. Confirm the API hostname, TLS certificate chain and ingress rules that the CLI will use. The step is done when all pods or containers report healthy, the API responds over TLS on the internal hostname, and the chart version and values are committed to your repository.
Connect Dex and map groups to workspace permissions
Configure Dex with your identity provider, using one of the supported options such as SAML, Azure Active Directory, Amazon Cognito or GitHub, and confirm the provider's group claims with your identity team. Map each group to the workspace, module and VCS connection permissions it needs, starting with the smallest set of roles. The step is done when a test user in each group can log in with terraform login and sees only the workspaces assigned to that group, and a user outside every group is denied.
Configure OpenTofu state encryption with a KMS key
Create a key in your own KMS, such as AWS KMS or a key managed through OpenBao, and configure OpenTofu client-side state and plan encryption to use it. Store the key policy under change control and document who can decrypt state. The step is done when a test workspace writes an encrypted state file, a second authorized operator can read it, and a user without key access cannot decrypt it. Confirm the exact configuration keys with the OpenTofu encryption documentation for the version you run.
Migrate state through the remote backend
Move one non-production workspace first. Use the remote backend, which supports migrating state, so that terraform init with the new backend copies existing state into Terrakube. Then run a plan and confirm it reports no changes. For sources outside Terrakube, such as the state versions API on HCP Terraform, export the JSON state first and verify its checksum. The step is done when the migrated workspace plans clean, the old state is retained under a documented read-only policy, and the cutover order for the remaining workspaces is written down.

Evidence assessors and regulators ask for

Assessors and regulators rarely accept a claim that a self-hosted orchestration platform is secure. They ask for artifacts that show how it is built, who can reach it, where state lives and what changed over time. The cards below list the evidence a team should be able to produce for a Terrakube deployment, and DeployOpen prepares these systems and records, while independent auditors issue any audit report or attestation.

Architecture and trust boundary diagrams

Draw where the Terrakube API, its executors, the relational database, the state store and the VCS connections sit relative to your network zones. Mark every path that carries credentials, state or plan files, and every point where a CLI on a laptop or CI runner talks to the API. Assessors use this map to decide which controls apply to which component, so keep it current with each change to the cluster or network layout. Confirm the diagram matches the deployed Helm chart or Compose stack, not the design intent.

Mirrored image inventory with checksums

List every container image the platform runs, including Terrakube components, the database, executors and any extension tools, with the tag and digest you deployed. Where your environment is isolated, record how each image crossed the boundary and the checksum or signature verified on import. This maps to the supply chain control that asks you to verify software integrity and authenticity before installation, and it is the evidence that gets asked for first after an upgrade.

Identity provider role and group mappings

Export the mapping between your identity provider groups and the Terrakube permissions on workspaces, modules and VCS connections. Terrakube uses Dex for sign-in and assigns permissions by group, so a stale or overly broad group can grant apply rights that no one intended. Review the mapping on a fixed schedule, store the export with the review record, and confirm that removing a user at the identity provider also removes their run access.

State encryption configuration and key policies

Document where state and plan files are stored, which encryption applies at rest, and whether OpenTofu client-side state encryption is in use with a key provider such as AWS KMS, GCP KMS or OpenBao. Keep the key policies that define who can decrypt, and record key rotation and access reviews. State often contains secrets, so assessors will ask who can read it from the database, the object store and the key service, and they will expect a separate answer for each.

Run logs and audit trails

Keep plan and apply logs, approval records and API activity for each workspace, and set a retention period that matches your policy. Confirm where Terrakube writes these logs, whether they are forwarded to your SIEM, and whether an operator can alter or delete them. A reviewer will trace a production change from the merge or request, through the plan, to the apply and the identity that ran it, so test that chain end to end before the review.

Upgrade change records

Record each Terrakube and OpenTofu version you deploy, the release notes you reviewed, the test results against a non-production workspace, the approver and the rollback plan. Pin the version in your deployment manifests so the running release can be matched to a record at any time. Assessors look for a repeatable change process rather than a single good upgrade, so keep the template consistent across releases.

Questions buyers ask before choosing Terrakube or Spacelift

What does self-hosted Spacelift cost compared with running Terrakube?

Spacelift is a commercial subscription, while Terrakube's software is free under Apache 2.0, so the comparison comes down to the components you pay for. For self-hosted Spacelift, the cost is the license, which is typically negotiated as an annual quote, plus the infrastructure it runs on. For Terrakube, the components are the infrastructure, a relational database that Liquibase supports such as PostgreSQL, executor capacity for runs, staff time to install, upgrade and operate it, and support if you buy it. Ask Spacelift for a written quote that states the license term, what it covers, what infrastructure it expects and whether support is included. Ask yourself the same questions about Terrakube, then compare the totals over the same period.

How long does a Terrakube deployment take?

The duration depends on scope, not on the software alone. The main drivers are how many workspaces and VCS connections you migrate, how many identity groups and permissions need mapping, whether you need the private registry for modules and providers, which extensions such as OPA policy checks or Infracost are in use, and how much of the surrounding network and cluster work is already in place. Terrakube installs with a Helm chart or Docker Compose, and the documentation describes minikube for testing, so a proof of concept can be quick, but a production rollout includes hardening, backups and cutover. DeployOpen agrees timelines in writing as part of a fixed-scope plan, so ask for a timeline tied to a defined list of deliverables.

What must our team provide before a Terrakube deployment starts?

You need to provide access to the target environment and a set of decisions that shape the design. The usual inputs are:

Cluster or host access, either a Kubernetes cluster or a Docker host in your own cloud account, data center or air-gapped network.
An identity provider, such as Azure Active Directory, Amazon Cognito, GitHub or SAML, which Terrakube reaches through Dex, along with the groups that will hold permissions.
Network decisions covering ingress, egress to VCS providers, and access from runners and developers to the Terrakube API hostname.
Key and database decisions, including where state is stored, which database engine to use, and which key provider to use for OpenTofu state and plan encryption.

If the environment is air-gapped, the Kubernetes images must also be mirrored to a private registry ahead of time.

Can an internal team run Terrakube without outside help?

Yes, a team with Kubernetes or container operations experience can run Terrakube, provided it has the skills and time to operate the surrounding stack. Operating it means owning upgrades (Terrakube publishes releases on its GitHub releases page), database backups and restores, executor capacity, identity configuration and the audit trail for runs. It also means maintaining the OpenTofu or Terraform versions your workspaces use. Before deciding, ask who on the team will hold each of these duties, how they will be covered during absences, and what a failed upgrade or restore looks like in your environment. The honest answer depends on your staffing, not on the product.

How does DeployOpen's fixed-scope engagement work, and what do retainers add?

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. Most engagements are fixed-scope, meaning scope, deliverables and timelines are agreed in writing before work starts, and DeployOpen does not publish a price list, so a quote follows from that written scope. Ongoing support, upgrades and continuous testing are available as retainers, which suit teams that want someone to keep Terrakube current after the initial rollout. Ask for the written scope to list the workspaces, integrations, identity setup, backup approach, documentation and handover items, and ask which of those are included in the fixed scope and which would move to a retainer.

Can Terrakube replace Spacelift policies and VCS workflows?

Terrakube covers the core run workflow, but policy and VCS coverage differ and need to be checked against your current setup. Terrakube integrates with GitHub, GitLab, Bitbucket and Azure DevOps to retrieve code, and its extensions add OPA policy checks and Infracost estimates to runs. Your existing Rego policies can often be carried over, but the translation, the trigger model and the mapping from Spacelift stacks to Terrakube workspaces need to be tested against real plans. Also confirm which Spacelift features you rely on beyond Terraform and OpenTofu, because Terrakube does not replace all of them. Ask for a gap list covering each policy type and VCS trigger, and test every workspace before cutover.

What should a team check on the Spacelift side before committing to Terrakube?

Start with your contract terms, your Spacelift deployment model and the exit path for your state. Self-hosted Spacelift is offered only on Enterprise+ and is installed into your AWS account with an AWS License Manager license, so confirm the license terms, renewal dates and any notice period with your account team. Next, confirm that you can export state and configuration, using a task that runs terraform state pull or external state access, and that you can recreate contexts, variables and policies elsewhere. Finally, record which teams depend on Spacelift features that would need a different owner after the move, so the decision is based on your full set of dependencies.

How DeployOpen works on this

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 Terrakube, that means scoping the run platform, identity, state database and VCS connections to your environment, then handing over a working system your team can operate.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
We confirm which Terraform or OpenTofu versions, VCS hosts and identity groups your workspaces depend on.
We record where state, plans and variables will live and which Kubernetes or Docker host will run Terrakube.

How we build

We install Terrakube with its Helm chart or Docker Compose method inside your own infrastructure.
We connect the relational database that Liquibase supports, configure Dex identity and group-based permissions.
We wire VCS connections, the private module registry and any extensions such as OPA policy checks, then test runs end to end.

How we hand over

We document the deployed architecture, configuration, backup procedures and the steps for onboarding new workspaces.
We walk your platform and security teams through run approvals, group permissions and state access controls.
We prepare a migration runbook for moving state and workspace settings, with each workspace checked to plan clean.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainer work can cover Terrakube version upgrades and Helm chart changes, scoped in writing.
We prepare systems, controls and evidence for your compliance assessments, while independent auditors issue any formal reports.

Self-hosted Spacelift vs open-source Terrakube