Skip to main content

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
Status: ⬆️ Gathering votes1 comment

Log in to comment and vote

Comments1

  • Natalia Gazda

    Team•

    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.yml
    3. 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 commands

    This 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!