Spacelift Templates: Self-Service Infrastructure for Every Developer

One of the persistent tensions in platform engineering is this: the people who need to deploy infrastructure are rarely the people who built the guardrails around it. App developers shouldn’t need to become Terraform experts just to spin up a database or a new service environment. And platform teams shouldn’t become a deployment bottleneck just because they want to keep infrastructure consistent and secure.

Today, we’re shipping Templates, a new feature in Spacelift that bridges that gap directly.

Most organizations land in one of two uncomfortable places.

Too much control: platform teams manage every stack themselves, nothing gets provisioned without a ticket, and developers wait days for infrastructure that should take minutes. Velocity suffers.

Too much freedom: developers get direct access to IaC tooling, things move fast, but configuration diverges across environments, standards erode, and one day you’re dealing with a compliance audit and no two stacks are alike.

Templates give you a third path: governed self-service. Platform teams define what can be deployed and how. Developers deploy it themselves, without needing to understand the underlying IaC.

If you’re already using Spacelift Blueprints, you might be wondering where Templates fit. The distinction is intentional.

Blueprints are a creation tool. They generate a stack and then step back. The resulting stack is fully editable and lives independently. Blueprints are great for one-time provisioning workflows or situations where you want stacks to evolve freely after creation.

Templates are a lifecycle management tool. They maintain an ongoing relationship with every stack they create. Deployments are version-pinned, immutable, and centrally governed. Templates are for infrastructure you want to remain consistent over time.

Both have a place. The right choice depends on whether you need a starting point or a contract.

A Template is a reusable infrastructure configuration, defined once by your platform team and deployable many times by end users, each time with different inputs.

The key design principle is that Templates maintain control over everything they create. Stacks created from a Template are immutable, meaning they cannot be manually edited, even by admins. If you want to change something, you do it through the Template itself, either by updating deployment inputs or publishing a new Template version. This isn’t a limitation; it’s the point. It’s what makes Templates trustworthy at scale.

For platform teams: The Templates Workbench

Platform engineers and template authors work in the Templates Workbench. This is where you define the Template’s YAML body, inputs, and configuration, publish versioned releases pinned to a specific VCS commit, and monitor all active deployments across the organization.

Versioning is first-class here. When you publish a new version of a Template, existing deployments are not automatically affected. Platform teams control when and how deployments are updated, keeping rollouts deliberate and predictable.

For developers: The Templates List

Application developers see a completely different experience. They browse a curated list of available Templates and deploy infrastructure by filling out a simple form — no Terraform knowledge required and no Spacelift configuration to wrestle with. Inputs are validated before anything runs, catching misconfigurations before they ever reach your cloud provider.

That’s it. The stack is created, managed, and governed automatically. The developer gets their infrastructure. The platform team keeps its standards.

Every published Template version is pinned to a specific VCS commit. This means the same Template version combined with the same inputs will produce identical infrastructure, every single time. Not “probably identical.” Actually identical.

This has real consequences for how you operate. There’s no configuration drift between environments deployed from the same Template. Disaster recovery is reproducible because you know exactly what you’re redeploying. And every running stack is auditable, traceable to a specific Template version and a specific set of inputs.

Templates are built for organizations with a platform team / application team split, where one group owns the infrastructure standards and another group needs to consume infrastructure quickly without becoming experts in it.

If your platform team is spending meaningful time fielding provisioning requests, or if you’re seeing infrastructure drift across environments that were supposed to be identical, Templates were built for you.

Templates are available on the Business plan and above. To get started, head to the Templates Workbench in your Spacelift account, define your first Template starting with something your developers provision frequently, publish a version and make it available to your teams, and watch your developers self-serve infrastructure without a single Slack message to the platform team.

Full documentation is available at docs.spacelift.io/concepts/template.

Templates represent our commitment to making Spacelift work for everyone in your organization, not just the people who live in IaC all day. We’d love to hear how you’re using it.