Spacelift Intelligence Now Deploys Modules Straight From Your Module Registry

Your developers don’t want a Terraform lesson. They want the load balancer, the database, the network stack you already built and blessed. It’s sitting in your module registry right now, reviewed, versioned, and ready for deployment.

The problem is the last mile. To use it, a developer still has to find the module, learn its slug, write the module block, wire up the inputs, and open a PR. Or they skip all of that and ask you to do it. Either way, the guardrails you built into that module don’t save you from the ticket queue. You wrote the module to stop being the bottleneck, but it’s no longer enough.

Spacelift Intelligence can help to eliminate the bottleneck. Spacelift Intent can now deploy a module from your Spacelift module registry as a single managed resource, described in plain language. Same registry and modules, now with a new way in.

A developer doesn’t need the slug or the version number. They simply ask:

Deploy the elb module.

Intent looks up your registry, finds the module, and picks its latest active version. If the module needs input variables, it asks for them before doing anything else. When someone wants more precision, they can supply it:

Deploy the elb module at version 1.2.0, with the web load balancer inputs.

Every module in your registry has a slug in the form of terraform-<provider>-<name>, so elb for the aws provider resolves to terraform-aws-elb. Nobody has to memorize that. Name the module, and Intent resolves it. Give it an exact slug or version when precision matters, and it’ll respect that too.

Before Intent applies anything, it runs three checks: is the module visible to this user, does the requested version exist and is it active, and did they supply every required input with nothing extra. Miss a check and the request stops with a clear error. Nothing gets applied. Pass the checks and Intent evaluates your Intent policies, then runs the module on a worker. Module deployments can take a while, so they run in the background, and the assistant reports back with a summary when the run finishes.

This only reaches modules published to your Spacelift registry. It doesn’t pull from the public Terraform Registry or straight from Git. If it’s not in your registry, Intent won’t deploy it, which is the point: you already decided what’s safe to hand developers, and this feature doesn’t go around that decision.

Once a module is deployed, changing it stays conversational. To change an input:

Set the idle timeout on the web load balancer to 120.

To move to a newer version:

Upgrade the web load balancer to the latest version.

Nobody has to restate the module’s existing inputs to upgrade it. Intent compares the version you’re using to the version you’re moving to, figures out how the inputs changed between them, carries your current inputs forward, and only asks about anything new or newly required. The upgrade applies in place: the new version’s code runs against your existing state, and the target version has to be active.

One thing stays fixed: you can’t swap which module a deployment points to. That’s set when the deployment is created. If you need a different module, delete the deployment and create a new one against it.

Ask Intent to remove a deployment and it checks whether anything else in the project depends on it first, then asks you to confirm before it destroys the module’s resources and removes it from state. A module deployment sits in your project’s dependency graph like any other resource. Other resources can depend on it, and if you export the project, its outputs become live references in the generated code.

The registry side is protected too. Spacelift won’t let you delete a module or a module version while an Intent deployment still uses it. You tear down the deployment first, so you can’t orphan it by accident from the registry side. Yanking a version is fine. You can still delete a deployment pinned to a version that’s since been yanked.

One edge case to flag: if a module was shared into your space from elsewhere and that share gets revoked, or the owning account removes the module, your deployment can lose visibility, and you won’t be able to delete it through Intent until access comes back.

A deployed module isn’t a black box bolted onto your project. In the Resources tab, it’s a single resource of type spacelift/module, and you can expand it to see the resources the module created underneath. Those nested resources are read-only. You manage the deployment as a unit, through its inputs and version, not by reaching in and editing individual resources.

The History tab records every create, update, and delete on that deployment, with full receipts. State is stored and encrypted the same way as any other Intent resource. Nothing about audit trail or state handling changes because the resource happens to be a module.

Governance doesn’t step aside either. Module deployments are evaluated against your Intent policies before anything gets applied. For a module, the policy sees resource_type: spacelift/module, the operation (create, update, or delete), the module’s slug as provider, the exact version as provider_version, and the input variables as proposed_state.

That’s the level policies operate at for a module: the module and the inputs, not the individual cloud resources the module will create inside its own plan. If you need to govern what happens inside the module, that governance belongs where the module is authored and published, not bolted onto the Intent policy layer.

Nobody has to know your registry by heart. Ask Intent what modules exist and it lists what’s in your registry that the requester has access to, so they can pick one to deploy. The Module Registry in the Spacelift UI is still there for browsing the same catalog visually.

The module registry was already your answer to “how do we let developers self-serve without letting them do anything they want.” This feature removes the part of that answer that still ran through you: writing the module block, opening the PR, being the person who translates a request into Terraform.

Developers describe what they want. Intent finds the right module, checks it against your rules, and deploys it under your existing policies, state, and audit trail. Nothing about what’s governed changes. Who has to sit in the middle does.

If you’re already publishing modules to your Spacelift registry, there’s nothing to set up. Point your team at Intent and have them ask for what they need.

Get started with Intent or read the full reference on deploying Spacelift modules.