Per-project workflow.yml
For setting up multiple stacks for a repository with project subfolders that are deployed separately, it looks like the .spacelift/workflow.yml is still per-repo and has to be at the repository root. It seems like it would make more sense for it to be located in the project root as specified on the stack so we can supply one workflow.yml per project rather than per repository.
- Workaround
- Problem
Log in to comment and vote
Comments1
Natalia Gazda
Aug 7, 2025
Hey @Quin Bedard !
Thanks for sharing this feature request. I understand the challenge of managing multiple projects in a monorepo, each needing its own workflow configuration. Good news - this is already achievable in Spacelift using contexts!
Here's how:
1. Create a context for each project (e.g.,
payments-team-workflow,infrastructure-workflow)2. Mount your custom workflow.yml in each context as a file at
.spacelift/workflow.yml3. Attach the appropriate context to each stack
yaml # In your payments context, mount this file at .spacelift/workflow.yml init: payments-tool init -input=false plan: payments-tool plan -out={{ .PlanFileName }} # ... other custom commandsThis approach actually provides better control and reusability than scattered workflow files:
- Each project gets its own workflow configuration
- You can share workflows across similar projects by reusing contexts
- Version control and review workflows in your IaC
- No file discovery magic or precedence confusion
The context-based solution aligns with Spacelift's philosophy of composable primitives - you build what you need by combining simple, powerful building blocks rather than adding special-case file discovery logic.Would this context-based approach work for your use case? If you're hitting any specific limitations with this solution, I'd love to understand more about what's blocking you!