Spacelift vs Terraform Enterprise: Features & Pricing Comparison

If you have ever run Terraform Enterprise (TFE), you already know it’s a pile of workspaces, a private module registry, some Sentinel policies, and a quarterly upgrade you schedule around.

However, things began to change once HashiCorp became part of IBM. The replicated deployment method you probably installed has been retired, releases have shifted from monthly to quarterly, and your stack may have grown to include OpenTofu, Ansible, or a few Pulumi projects that TFE cannot touch.

In a situation like this, you’ll probably start looking for another option. Spacelift might be a good fit, as it solves the same core problem (running IaC safely, with guardrails and an audit trail) from a different angle.

In this article, we will walk through what Terraform Enterprise and Spacelift are, compare them feature by feature, review the migration process, and give you a straight answer on which one fits which team.

Terraform Enterprise (TFE) is HashiCorp’s self-hosted distribution of HCP Terraform, built around the Terraform workflow, whereas Spacelift orchestrates multiple infrastructure as code (IaC) tools from one control plane.

• Terraform Enterprise runs Terraform only, self-hosted on Docker, Kubernetes, OpenShift, Podman, or Nomad, with governance through Sentinel or Open Policy Agent (OPA).
• Spacelift runs Terraform, OpenTofu, Terragrunt, Pulumi, CloudFormation, Kubernetes, and Ansible, with managed or private workers and pricing based on plan tier and worker capacity rather than Resources Under Management (RUM).

Choose Terraform Enterprise for Terraform-only estates, especially with a large Sentinel library you do not want to rewrite. Choose Spacelift for multi-tool environments, cost decoupled from resource count, or dependency chains that cross tools, such as an OpenTofu stack feeding an Ansible one.

Terraform Enterprise is the self-hosted distribution of HCP Terraform. It runs on your infrastructure rather than HashiCorp’s, which is why most people buy it. TFE is HashiCorp’s answer for teams in regulated environments or when your security team needs to ensure data doesn’t leave the network.

Using TFE, you get:

• Workspaces as the unit of execution. They are mapped to a Terraform configuration with its own state, variables, and run history.
• A private registry for your internal modules and providers.
• Policy as code through Sentinel or OPA, attached to workspaces as policy sets. These work on setup, plan, and apply time.
• Remote state management with locking, and also remote plan and apply.
• RBAC, SSO, and audit logging for the governance checkboxes.
• Run tasks for calling out to external services (security scanners, cost tools) at specific points in a run (you won’t be able to integrate other services than these).
• No-code provisioning, where you publish a module and let other teams deploy it through a form instead of writing HCL.
• Terraform Stacks (added in TFE 2.0), which group Terraform configurations into components that pass outputs to each other and deploy across environments as one unit.

Now, TFE deploys on Docker, Podman, Kubernetes, OpenShift, and Nomad. The old Replicated install is gone (last release was in March 2025), so if you are still on it, you need to migrate.

TFE also changed how it versions itself. The last date-based release was v202507-1 in July 2025. From August 2025 it moved to semantic versioning starting at 1.0.0, and current documentation sits at 2.0.x. Milestone releases ship quarterly, with monthly patches in between.

TFE runs only Terraform, which is a limitation. If your organization moved to OpenTofu after the license change, or you have a Pulumi project from a team that prefers TypeScript, none of those live in TFE. TFE cannot help you with container orchestration or configuration management either. You’ll end up needing other products to manage these tools.

Spacelift is an infrastructure orchestration platform that supports OpenTofu, Terraform, Terragrunt, Pulumi, CloudFormation, Ansible, and Kubernetes. It enables DevOps teams to provision, configure, and govern infrastructure from a single control plane.

Spacelift uses stacks instead of workspaces, which are hierarchical, so you can model teams and environments properly and let permissions inherit down the tree.

Using Spacelift, you get:

• Policy as code based on OPA across multiple decision points: You can control what kind of resources your engineers can create and what parameters they have, control how many approvals you need for a run, control what happens when a pull request is opened or merged, and control where to send notifications.
• Stack dependencies enable you to create dependencies between your configurations and even share outputs. These are directed acyclic graphs (DAGs), meaning you can have as many nested levels as you want with your dependencies. The best part is that you can create dependencies between configurations that use different tools (e.g., you can have an OpenTofu parent with a dependency to an Ansible child).
• Contexts are logical containers for your environment variables, mounted files, and lifecycle hooks that can be reused by any number of stacks, either explicitly or automatically by label. So, in this case, your environment variables and your pre-plan security scan live in one place instead of being copy-pasted across forty stacks.
• Worker pools are used by stacks to carry out your workflow. They are either Spacelift-managed public workers or private workers in your own infrastructure, so credentials and state never leave your network boundary.
• Drift detection can be scheduled to detect changes made outside your IaC processes (E.G., through ClickOps or scripting), and you also get out-of-the-box remediation.
• Blueprints are YAML templates for your stacks that help you to self-serve infrastructure. They integrate natively with ServiceNow and Backstage to meet your developers where they are.
• Cloud integrations enable dynamic credentials for AWS, Azure, and Google Cloud instead of static credentials. This means that if your credentials are intercepted, they will be useless because they are short-lived.
• Spacelift Intelligence is an AI layer with Infra Assistant for questions about your actual deployments and Intent for natural language provisioning that still runs under the same policies and credentials.

This comparison is based on publicly available documentation, product materials, and hands-on experience with both platforms. Spacelift is the publisher of this article and is one of the platforms being compared, so treat the Spacelift entries as a vendor’s own description and confirm current Terraform Enterprise capabilities against HashiCorp’s documentation. Capabilities on both platforms change often.

Let’s see how these platforms compare.

1. IaC tool support

TFE supports only Terraform.

Spacelift runs OpenTofu, Terraform, Terragrunt, Pulumi, CloudFormation, Ansible, and Kubernetes under one roof with the same policies, the same RBAC, and the same audit trail applied to all of them. This difference is the biggest between these two platforms and is why most migration conversations start.

2. Policy as code

TFE gives you Sentinel, which is HashiCorp’s own language, or OPA, scoped to workspaces as policy sets.

On the other hand, Spacelift gives you only OPA across the board, and the decision points go wider. You can control what happens when a pull request is opened or merged, require two or more approvals from specific teams on production, route notifications based on what changed, and control what kind of resources your engineers can create or what kind of parameters these resources have.

3. Workflow orchestration

TFE 2.0 added Terraform Stacks. Components inside a Stack pass outputs to each other, and linked Stacks share values through publish_output and upstream_input blocks, triggering downstream runs when an upstream output changes. For a Terraform-only estate, that replaces most of the remote state plumbing run triggers used to need.

The catch is that Stacks stop at the Terraform boundary. A Stack can’t depend on an OpenTofu, Ansible, Pulumi, or CloudFormation run, linked Stacks must sit in the same project, and Stacks on TFE require a RUM license.

Spacelift stack dependencies work across every tool Spacelift runs. An OpenTofu stack provisions your VMs and passes their IP addresses straight to the Ansible stack that configures them, and any stack that produces outputs can feed any other, Ansible and Kubernetes included. One dependency graph, no glue code between tools.

4. Execution and workers

Both TFE (agents) and Spacelift (private worker pools) give you managed execution and additionally a self-hosted option. Spacelift lets you bring your own runner image, so in case your runs need kubectl, aws-cli, helm, or an internal binary, you bake it in rather than fighting the environment.

5. Self-service

TFE’s no-code provisioning works, but it is also tied to Terraform modules and a fixed workflow.

Spacelift gives you Blueprints, which are YAML templates that spin up a stack for any support tool, with policies attached from the start. In addition, Spacelift offers Templates that ensure stacks self-served from them are immutable. Also, if you add Intent on top, developers can describe what they want in plain language while remaining bound by your guardrails.

6. Pricing model

HCP Terraform and Terraform Enterprise bill on Resources Under Management (RUM). This means that every managed resource counts, including EC2 instances, security group rules, IAM policies, and S3 buckets.

For public HCP Terraform, the pricing lands around $0.10 per resource-month, for Essentials, $0.47 for Standard, and $0.99 for Premium, billed on hourly peak usage. TFE is a custom enterprise license, and HashiCorp typically keeps this pricing under custom quotes.

The problem here is that your bill grows every time somebody adds a new resource, more IAM policies, etc. Stacks on TFE also require RUM licensing.

Spacelift bills on plan tier and worker capacity, with no per-resource charge. Free covers two users, Starter starts at $399 per month for 10 users, and Business and Enterprise are quoted, with unlimited users and public or private workers. See the pricing page for what each plan includes.

Summary table

The table below summarizes the differences between Terraform Enterprise and Spacelift.

If you want to migrate from Terraform Enterprise to Spacelift, the good news is that you are not doing it by yourself. Spacelift ships liftoff, which is a migration kit distributed as a single static binary that handles the bulk work.

The process is straightforward: You need to point it at your TFE instance. It runs a read-only discovery pass that pulls your whole estate into local storage, then you batch units into manageable groups, audit what it found, generate the configuration, publish it to Spacelift as an admin stack, mutate to fill in secrets, and finalize.

Confirming a publish looks like this:

Before you start migration, get these ready:

• A Spacelift account with an API key that has root-space admin access.
• A TFE admin user token.
• A VCS integration with access to your repositories, plus a VCS token if you use private modules.
• At least one available Spacelift worker.

Here are two things you need to plan for:

• Sensitive variables need a separate capture step: TFE masks sensitive values, so discovery brings them over empty. liftoff mutate --allow-mutation secrets briefly switches each workspace to agent execution mode to read them, then restores its settings, and liftoff finalize sensitive pushes the values to Spacelift.
• Sentinel policies do not translate automatically: Spacelift has no Sentinel support, as it is HashiCorp proprietary, so if you have a real Sentinel library, you need to rewrite it in Rego. Most policies are simple checks on resource attributes, so this is less painful than it sounds, but do not schedule the cutover assuming it is free. If you are already on OPA in TFE, you keep the language, the mental model, and your Rego skills, and you skip the Sentinel rewrite entirely.

See what a migration looks like using an AI assistant from HCP Terraform to Spacelift:

You should stay on Terraform Enterprise if your entire estate is Terraform, and you think it will stay that way, you have a large Sentinel investment you do not want to rewrite, and your IBM relationship gets you pricing that makes the RUM model tolerable.

Choose Spacelift if you run more than one IaC tool or expect to, you want cost decoupled from resource count, you need real dependency chains between layers of infrastructure, you want self-service without building a portal yourself, or you want managed SaaS with private workers for operational relief without the data exposure.

Terraform Enterprise is a solid platform for Terraform, but the transition to IBM slowed down its releases and forced users running the Replicated deployment model to migrate to a new deployment method.

Spacelift has the same governance ground and adds multi-IaC support, hierarchical spaces, stack dependencies that work across every tool it runs, and broader policy decision points. On pricing, RUM billing scales with your infrastructure. Spacelift’s tier and worker model scales with your concurrency needs.

Migration from TFE to Spacelift is a real project, but using liftoff will remove a lot of manual work. You should plan for secrets and Sentinel rewrites, and proceed in batches. If you want to see how Spacelift can help you migrate off of TFE, book a demo with one of our engineers.

Frequently asked questions

• Does Spacelift support Sentinel policies?No. Spacelift uses Open Policy Agent (OPA) and Rego for every policy type, so a Sentinel library has to be rewritten before you cut over. Most Sentinel policies are attribute checks against planned resources, and those map to Rego directly.

Does Spacelift support Sentinel policies?

No. Spacelift uses Open Policy Agent (OPA) and Rego for every policy type, so a Sentinel library has to be rewritten before you cut over. Most Sentinel policies are attribute checks against planned resources, and those map to Rego directly.

• Can Terraform Enterprise manage OpenTofu, Pulumi, or CloudFormation?No. Terraform Enterprise runs Terraform only, so anything written in OpenTofu, Pulumi, CloudFormation, or Ansible needs a second platform to govern it.

Can Terraform Enterprise manage OpenTofu, Pulumi, or CloudFormation?

No. Terraform Enterprise runs Terraform only, so anything written in OpenTofu, Pulumi, CloudFormation, or Ansible needs a second platform to govern it.

• How does policy enforcement differ between Spacelift and Terraform Enterprise?TFE attaches policy sets to workspaces and checks the Terraform plan against them during each run. Spacelift evaluates OPA policies at more decision points, covering what gets planned and applied, what a push or pull request triggers, how many approvals a run needs, who can reach a stack, and where notifications go.

How does policy enforcement differ between Spacelift and Terraform Enterprise?

TFE attaches policy sets to workspaces and checks the Terraform plan against them during each run. Spacelift evaluates OPA policies at more decision points, covering what gets planned and applied, what a push or pull request triggers, how many approvals a run needs, who can reach a stack, and where notifications go.

• Can I migrate from Terraform Enterprise to Spacelift?Yes. The liftoff binary runs a read-only discovery pass against your TFE instance, generates stack configuration, and publishes it to Spacelift as an admin stack. Plan to set sensitive variables by hand and rewrite Sentinel policies in Rego, because neither carries across.

Can I migrate from Terraform Enterprise to Spacelift?

Yes. The liftoff binary runs a read-only discovery pass against your TFE instance, generates stack configuration, and publishes it to Spacelift as an admin stack. Plan to set sensitive variables by hand and rewrite Sentinel policies in Rego, because neither carries across.