Skip to main content

Support for multiple git repositories

Feature RequestsVCSStacksIntegrations

Native support for cloning and using additional Git repositories within a single stack. Ideally, these repositories could rely on the same or different Git integrations and be checked out under “/mnt”.

Workaround
Problem
Status: ❌ Rejected2 comments

Log in to comment and vote

Comments2

  • Magenta Spaghetti

    •

    Dec 23, 2025

    Thanks for the reply and for explaining the current model.

    The issue is that the suggested approaches don’t really cover the use case being raised. This is not about decomposing infrastructure into multiple stacks with dependencies. It is about a single plan needing access to multiple repositories at evaluation time, typically owned by different teams and evolving on different cadences.

    A common pattern is Terraform code in one repo and environment configuration files in another. The Terraform needs to read those files directly during plan and apply. There is no meaningful output or deploy boundary here, so stack dependencies don’t help.

    Repository consolidation is often not viable in larger organisations where infra code and config are intentionally separated for ownership, review, and risk management reasons.

    The before_init workaround also breaks down in practice. Even with credentials injected, changes in the secondary repository cannot trigger runs, which undermines event driven automation and requires manual or scheduled execution.

    The core ask is first class support for a single stack and state that can consume multiple Git repositories, with proper webhook support and native git integrations.

  • Black Breeze

    •

    Dec 16, 2025

    Thanks for the detailed feature request!

    I understand the workflow challenge you're facing with needing access to multiple Git repositories within a single stack.

    This request touches on some fundamental architectural decisions in Spacelift. Our stack model is built around the principle that each stack has a single, clear source of truth - one repository and branch that defines what gets deployed. This design provides several benefits:

    • Clear audit trails and change tracking

    • Simplified webhook and trigger management

    • Predictable state management

    • Straightforward policy evaluation

    For your use case, I'd recommend exploring these approaches that work within Spacelift's current architecture:

    Stack Dependencies: Create separate stacks for each repository and use stack dependencies to model the relationships between them. This gives you:

    • Clear separation of concerns

    • Proper dependency ordering

    • Input/output wiring between stacks

    • Individual control over each repository's deployment

    Repository Organization: Consider consolidating related infrastructure code into a single repository, using Spacelift's project_root setting to target specific directories.

    Enhanced before_init approach: While you mentioned the limitations of your current workaround, you could enhance it by:


    • Using Spacelift contexts to securely provide Git credentials

    • Leveraging cloud integrations (AWS, GCP) for credential management

    • Setting up proper SSH keys or tokens through mounted files

    The stack dependency approach in particular aligns well with infrastructure best practices and gives you the orchestration capabilities you're looking for while maintaining clear boundaries between different infrastructure components.