Spacelift for Terraform & Infrastructure Orchestration
Writing Infrastructure as Code is the easy part, especially with competent AI. The hard part is running it safely across multiple teams, multiple clouds, and multiple environments without someone's unreviewed terraform apply taking down production on a Tuesday afternoon.
Terraform solves the "describe your infrastructure in code" problem well. What it doesn't solve is the operational layer around that code: who can run it, when, against which environment, with what approvals, and with what visibility into what actually changed. At a certain scale, those questions become the real work, and teams end up duct-taping together CI pipelines, shell scripts, and shared credentials to answer them. Spacelift is built specifically to answer them properly.
At Absolute Ops, we recommend Spacelift to customers who have outgrown the "someone runs Terraform from their laptop" phase and need a cloud operations model that can actually scale.
What Terraform is and why teams use it
Terraform is an open-source tool from HashiCorp that lets you define cloud infrastructure in configuration files and apply those definitions through a CLI. Instead of clicking through the AWS console to create a VPC, a subnet, a security group, and an EC2 instance, you write a declarative configuration that describes what you want, and Terraform figures out the API calls to make it happen.
The core idea is that infrastructure should be treated like code: written in text files, stored in version control, reviewed before it's applied, and reproducible on demand. If you need a staging environment that matches production, you run the same Terraform configuration against a different set of variables. If you need to tear it down and rebuild it, you do that from the same files. The state of your infrastructure is documented in the repository rather than living in someone's memory or a shared spreadsheet.
Terraform also handles dependencies. If a security group needs to exist before an EC2 instance can reference it, Terraform figures out the right order of operations automatically. If you remove a resource from the configuration, Terraform destroys it cleanly rather than leaving orphaned resources accumulating on your bill.
The other significant advantage is the plan step. Before applying any changes, Terraform produces a diff showing exactly what will be created, modified, or destroyed. Teams can review that output before anything touches real infrastructure, which catches mistakes that would otherwise only surface after the fact.
For these reasons, Terraform has become the dominant IaC tool for AWS environments, and is widely used on Azure and GCP as well. The ecosystem of community-maintained modules covers most common infrastructure patterns, so teams rarely start from scratch.
The problem with Terraform at scale
Terraform is a tool, not a workflow. On a small team with one or two engineers managing a modest amount of infrastructure, it works fine without much scaffolding around it. State is stored in S3, plans are reviewed manually, and everyone roughly knows what everyone else is doing.
As the team grows, that model starts to break. Multiple engineers running plans concurrently creates state conflicts. Credentials get passed around in ways that don't hold up to a security review. There's no consistent policy about what requires approval before applying. Drift happens when someone makes a manual change in the console and nobody updates the Terraform. And when something goes wrong, the audit trail is whatever ended up in Slack.
The usual response is to build something in CI: a GitHub Actions workflow or a GitLab pipeline that runs terraform plan on pull requests and terraform apply on merge. That's better than ad hoc runs, but CI systems were designed to build and deploy application code. They don't have native concepts for infrastructure run lifecycles, workspace dependency graphs, drift detection, or policy enforcement. You end up building and maintaining a lot of that yourself, and it never quite works the way you want.
What Spacelift adds to the Terraform workflow
Spacelift wraps the Terraform workflow in an orchestration layer that handles the operational concerns that CI pipelines handle badly.
The most immediate difference is how runs are managed. Spacelift understands the full lifecycle of an infrastructure change: plan, review, approve, apply, and verify. Approval gates are configurable based on the scope of the change. A plan that touches IAM roles in a production account can require two reviewers; a change to a dev environment's instance tags can apply automatically. The rules live in code and apply consistently, rather than depending on someone remembering to follow a process.
Drift detection runs continuously. If someone makes a change directly in the AWS console or edits a resource outside of Terraform, Spacelift detects the divergence and surfaces it. With a standard CI setup, drift is invisible until it causes a problem.
Stack dependencies are another area where Spacelift closes a real gap. In most infrastructure setups, some stacks depend on outputs from others: a networking stack that exports VPC IDs consumed by an application stack, for instance. Spacelift models these dependencies explicitly, so changes trigger downstream plans automatically in the right order, rather than requiring someone to remember which stacks need to be re-applied after a shared resource changes.
The audit trail is complete and tamper-evident. Every plan, apply, and approval is logged with who triggered it, what changed, and what the policy evaluation produced. For teams preparing for a SOC 2 or compliance audit, that record is significantly easier to present than reconstructed CI logs and Slack threads.
Policy as code, without the overhead
One of Spacelift's more useful features is its policy engine, which uses Open Policy Agent (OPA) to enforce rules against every infrastructure change before it runs. The rules are code, version-controlled alongside everything else, and applied automatically.
The kinds of policies teams actually write include things like: no public S3 buckets, only approved instance families allowed in production, any change to IAM requires a second approver, production applies can only be triggered from the main branch. These rules would otherwise live in documentation that people read once during onboarding and then forget.
Encoding them in policy means they're enforced rather than recommended. A developer submitting a plan that would create an open security group sees the policy violation in the plan output before anything applies, not during a security review a week later.
This is the path toward genuine self-service infrastructure: developers can provision what they need without waiting for a platform team member to review every change, because the guardrails are already in the workflow.
Multi-cloud and multi-tool without the chaos
Beyond Terraform, Spacelift supports OpenTofu, Pulumi, CloudFormation, Terragrunt, and Kubernetes manifests, which matters for organizations that have accumulated different tools across teams or clouds over time. Rather than maintaining separate pipelines for each tool, everything runs through the same orchestration layer with the same governance model.
For teams managing infrastructure across AWS, Azure, and GCP simultaneously, or across cloud and on-premise environments, having one control plane with consistent policy enforcement and visibility is operationally simpler than the alternative. Private worker pools let Spacelift reach into isolated networks or on-premise environments that aren't publicly accessible.
What self-service infrastructure actually requires
The goal most platform engineering teams are working toward is giving developers the ability to provision the infrastructure they need without requiring a ticket to the platform team. The obstacle isn't willingness; it's that handing developers cloud access without guardrails creates risk that platform teams are rightly uncomfortable with.
Spacelift's RBAC model and parameterized stacks make the middle path practical. Developers work with pre-approved patterns: a stack configured for a web application, a database stack with sensible defaults, a messaging stack. They can customize within the parameters the platform team defines. Policies enforce the boundaries. Credentials never leave Spacelift's execution environment.
The platform team retains control over what can be deployed and how. Developers get autonomy within those bounds, without needing to understand every detail of the underlying cloud configuration.
Whether Spacelift is the right fit
Spacelift is a good investment when the operational overhead around Terraform (or other IaC tools) has become a real cost: engineers spending time maintaining CI pipelines, manually enforcing policies, chasing down drift, or stitching together audit trails for compliance purposes.
For smaller teams with simple infrastructure, the overhead of adopting a dedicated orchestration platform may not be justified yet. A well-structured CI setup with disciplined state management gets you a long way.
For teams at the scale where infrastructure management itself has become an engineering problem, Spacelift is worth a serious look. If you want to talk through whether it fits your current setup, get in touch. We've implemented it across a range of environments and can give you a realistic picture of what the transition looks like.
