← Back to all posts

TTL on Intent Projects with automatic resource cleanup

Expose a ttl (or expires_at) property on Intent Projects with the following behavior:

  1. Configuration — TTL can be set at project creation or updated later, expressed either as a duration (72h, 7d, 30d) or an absolute timestamp. It should be settable via UI, API, GraphQL, and the Terraform provider.

  2. Default & policy control — Allow administrators to set a default TTL per space, and/or enforce a maximum TTL via an Intent policy (e.g., "all Intent Projects in the dev space must have a TTL ≤ 14 days").

  3. Notifications — Send notifications (email/Slack via existing notification policies) to the project owner at configurable thresholds before expiration (e.g., 72h, 24h, 1h) with a one-click "extend TTL" action.

  4. Expiration behavior — When the TTL elapses, Spacelift automatically performs a destroy of all resources managed by the project in dependency order, subject to existing Intent policies (so a policy denial on delete is still respected and surfaced). The full cleanup run is recorded on the project's History tab for auditability, matching how deletions are already tracked.

  5. Project lifecycle after cleanup — Configurable: either archive the project (keeping history/receipts for audit) or fully delete it. Archive should be the default.

  6. Lock & grace handling — If a project is actively locked by a user session when TTL expires, delay cleanup until the lock releases (or a configurable grace period elapses), and notify the lock holder.

Workaround
-
Problem
The dominant use case for Intent Projects — as described in Spacelift's own launch materials — is short-lived, non-critical workloads: QA setups, demo environments, hackathons, prototypes, experiments. These are exactly the workloads that tend to be forgotten and left running, accumulating cost and cluttering cloud accounts. Because Intent encourages fast, natural-language provisioning ("create a QA setup with two app servers, a database, and an S3 bucket") and explicitly lowers the ceremony of creating infrastructure, it equally raises the risk of orphaned resources. Without a cleanup mechanism, platform teams either have to: - Build external reaper tooling that talks to the Spacelift API to find and destroy stale Intent resources, or - Rely on cloud-native tag-based reapers (e.g., aws-nuke, custom Lambdas), which sit outside Spacelift's state and audit trail — defeating the "governed by default" model.

Please authenticate to join the conversation.

Upvoters
Status

👀 In Review

Board

💡 Feature Requests

Date

1 day ago

Subscribe to post

Get notified by email when there are changes.