Deploying Spacelift modules

Intent can deploy a module from your Spacelift module registry as a single managed resource, described in plain language. It's the same registry and the same modules you already publish and consume in stacks, reached through a new path: instead of writing a module block, you ask your AI client to deploy a module, and Intent applies it under your policies, state, and audit trail.

A deployed module shows up as one resource in your Intent project. Its type is spacelift/module, and the resources the module creates live inside its state.

Deploy a module

Just ask for the module by name:

Deploy the elb module.

The assistant looks up your Spacelift modules, finds the one you mean, and picks its latest active version. If the module needs input variables, it asks you for them before going ahead. You can be more specific when you want to, pinning a version or passing inputs up front:

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

Behind the scenes, Intent checks that the module is visible to you, that the version exists and is active, and that you've supplied every required input (and nothing the module doesn't declare). If something is missing or wrong, you get a clear error and nothing is applied.

Once the checks pass, Intent evaluates your Intent policies, then runs the module on a worker. Module deploys can take a while, so they run in the background and the assistant keeps you posted, with a summary in chat when it finishes.

You need read access to the module (one you own, or one shared into a space you can read) and the right to operate in the Intent project's space. See Execution and access control for the RBAC details.

Spacelift registry modules only

Intent deploys modules from your Spacelift module registry. It does not pull modules from the public Terraform Registry or directly from Git. The module has to be published to Spacelift first.

How modules are identified

Every Spacelift module has a slug of the form terraform-<provider>-<name>, so a module named elb for the aws provider has the slug terraform-aws-elb, and each deployment is pinned to an exact published version. You don't have to know either one. Name the module and the assistant resolves the slug and picks the latest active version for you. You can still give an exact slug or version when you want to be precise.

Update or upgrade a module

To change a deployment's inputs, just say what you want changed:

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

To upgrade it to a newer version, ask for the upgrade:

Upgrade the web load balancer to the latest version.

You don't have to restate the module's inputs. The assistant looks at the version you're on, the version you're moving to, and how the module's inputs changed between them. It carries your existing inputs forward and only asks you for anything new or newly required. The upgrade is applied in place: the new version's code runs against your existing state. The version you're moving to has to be active.

You can't change which module a deployment uses. The module is fixed when you create the deployment. To switch to a different module, delete the deployment and create a new one.

Delete a module

Reference the deployment and ask to remove it:

Delete the web load balancer.

Intent checks for other resources that depend on it first, asks you to confirm, and then destroys the module's resources and removes it from state. A module deployment takes part in the project's dependency graph like any other resource: things can depend on it, and on export its outputs become live references in the generated code.

Modules you depend on stay protected

Spacelift won't let you delete a module or a module version from the registry while an Intent deployment still uses it. It asks you to tear down the deployment first, so you can't accidentally orphan your own deployments. Yanking a version is fine too: you can still delete a deployment that was pinned to a version that has since been yanked.

The one case to watch is a module shared into your space from elsewhere. If that share is revoked, or the account that owns the module removes it, your deployment can lose visibility, and you won't be able to delete it through Intent until access is restored.

How a module shows up in Spacelift

In your Intent project:

• The Resources tab lists the module as a single resource of type spacelift/module. You can expand it to see the managed resources the module created. These are read-only: you manage the deployment as a unit, through its inputs and version, rather than editing the resources inside it directly.
• The History tab records every create, update, and delete, with full receipts.
• State is stored and encrypted by Spacelift, the same as any other Intent resource.

Policy and modules

Module deployments are governed by your Intent policies, evaluated before anything is applied. For a module, the policy input includes:

• resource_type: spacelift/module
• operation: create, update, or delete
• provider: the module slug
• provider_version: the exact version
• proposed_state: the input variables you supplied

Policies see inputs, not the expanded plan

For a module deployment, your policy sees the input variables you passed, not the individual cloud resources the module will create. If you need to govern the resources inside a module, do it where the module is authored and published, rather than relying on the Intent policy to inspect them.

Finding modules

You don't need to know a module's exact name ahead of time. Ask the assistant what modules are available and it lists the ones in your registry that you have access to, so you can pick one to deploy. You can also browse the Module Registry in the Spacelift UI.