Drive a run entirely from runtime configuration (No Stack required!)
Similar to how GitHub Actions and Gitlab-CI work, I would really like to just write the expected stack config in the source code config, and have the runner execute it. Eliminate the need to create and manage Stacks as separate entities entirely!
The runtime configuration is kinda halfway there already. We can drive Stack behavior from source code. But we still have to separately create the Stack first. Why? Let’s remove that limitation, and just drive the run entirely from source.
- Workaround
- No
Log in to comment and vote
Comments12
Yellow Mirror
Feb 11, 2025
If accepted, ideally the feature would support separate config files for each “stack”. The “single file” approach currently used by runtime config is harder to scale.
Black Breeze
Jun 6, 2025
Thanks for the feedback, Loren! This is an interesting perspective, and I'd love to understand the specific friction you're experiencing.
Stacks in Spacelift are fundamentally different from GitHub Actions workflows because infrastructure is stateful while CI/CD jobs are ephemeral. A Stack isn't just execution instructions - it's:
State management: Tracks what resources exist and their current configuration
Identity: Provides a stable entity for policies, approvals, and dependencies
History: Maintains audit trail of who changed what and when
Drift detection: Monitors if real-world resources diverge from declared state
Governance: Applies consistent policies and access controls over time
GitHub Actions runs are stateless - each execution starts fresh. But infrastructure needs continuity. Your S3 bucket from last week is the same bucket today, with accumulated state and relationships.
Discovery question: What specific friction are you hitting with creating/managing Stacks today? Is it:
Too much clicking to set up similar stacks across environments?
Repetitive configuration that feels like boilerplate?
Managing many stacks in a monorepo?
Something else entirely?
Understanding your workflow pain points will help us figure out if there's a better way to reduce friction while preserving the stateful benefits that infrastructure requires.
Yellow Mirror
Jun 7, 2025
All of the above, and the chicken-egg problem of the stack must be created by something else first, before there is any kind of runner available to the project. It’s harder for us to introduce additional users outside the platform team to Spacelift, when they have to learn Stacks first. Instead, we’re more likely to restrict Stacks to the platform team.
Maybe it’s a whole new concept in Spacelift. Maybe it’s a deeper integration with source control CI features, via they’re own apps/integrations, environments, and deployments. Maybe the stack is simply “auto-created” on first-use. I’m not sure exactly what form the implementation might take, other than simply being driven more purely and completely by the repo-level config.
Black Breeze
Jun 8, 2025