Skip to main content

spacectl local-apply

Feature RequestsIaC WorkflowsStacks

To make our TF code work with Spacelift, we had to add assume_role_with_web_identity block with role_arn and web_identity_token_file into our providers definition as per the documentation. I have seen that spacectl has feature called "local-preview", where you can run terraform plan with your local code. I find that very useful.

However, would it be possible to also run terraform apply in a similar way? I find this handy for early stage / crude development because I have witnessed many Terraform deployments to pass terraform plan, only to fail on terraform apply.

Workaround
Problem
Status: ❌ Rejected13 comments

Log in to comment and vote

Comments13

  • Jonah Kowall changed status to ❌ Rejected
    Team•

    Jul 3

    Pinned

    I am closing this out as it would enable the use of local execution to go around policies and governance which is a critical part of the value Spacelift Deploy provides.

    • Rose Beaver

      •

      Jul 14

      Hi, thanks for commenting on this! I am completely fine with the feature not being implemented (we have found a nice workaround), but I am not sure if I agree with the justification.

      All the Spacelift policies would still be in place, right? So doing local apply through Spacelift is still safer than giving users direct cloud access and thus the user would not “go around policies and governance” - in my opinion.

      • Jonah Kowall

        Team•

        Jul 14

        I agree that the guardrails would still be there (OPA). Where things are a bit more complex is provenance. If you use a local apply the infrastructure can be changed with unreviewed code. It’s more about “going around change management and code provenance” to be more accurate. Thanks for pushing back.

  • Black Breeze

    •

    May 14, 2025

    Quick thought experiment:

    What if we allowed runs on uncommitted code—local changes, pre-PR branches, etc.—but stored a git diff with the run, clearly showing what changed vs the tracked branch?

    The run would be marked as “Untracked Apply – Diff Attached.” It wouldn’t be the default, and wouldn’t touch prod unless explicitly allowed.

    We’d scope this via an inheritable Space-level setting, so teams could opt into it in dev while locking it down elsewhere.

    Not saying we’ll do it—just wondering if that tradeoff (faster iteration with visible deviation) would help more than hurt.

    • Azure Chipmunk

      •

      May 14, 2025

      Honestly, I’m good with that. Having the diff would definitely be useful. And making it obvious that it’s a “local-sourced” apply is good.

  • Black Breeze

    •

    May 10, 2025

    Thanks for the request! We totally get the desire for a faster feedback loop when developing infrastructure changes. That said, we believe strongly in Git being the source of truth—especially when it comes to applying changes. Introducing a local apply path would create divergence risks and break the guarantees Spacelift is built around.

    That said, we’re curious: what specific feedback are you trying to get faster? Is it about validating Spacelift configuration, previewing infrastructure changes, or something else entirely? There might be safer ways we can help speed up that loop without undermining GitOps principles. Let us know!

    • Pink Soup

      •

      May 11, 2025

      I have the same issues of slow feedback.

      Committing to my CI (GitHub in this case) and building an artifact (either container image or zip) can take 5-10 minutes remotely, then Spacelift can take time to initialise, then pull the repo, run the plan and then do the apply. Adding further minutes.

      To get around this in some scenarios I'm just directly pushing my Lambda code directly, which is fine but doesn't work when I change any configuration on Aws (event bridge rule, dybamo DB, S3 notifications etc). So I'm then unable to run integration tests without going through the slow deployment loop, which might then break. This is particularly telling when changing things like Step Functions or API Gateway configuration, and painful when using Eventbridge Rules to control my service triggers.

      Changing the code outside of CI gets around half the issue but not the other half.

      Many other IaC tools supports this set up, including CDK, SAM, Pulumi and SST, which massively speeds up that feedback loop of changing configuration in low tier environments, and has proven to be very useful.

      In a similar way that local preview uses the contents of your local working directory, I would assume local apply could do the same thing. And again I would imagine local apply being a toggle able capability that most/all people wouldn't allow to be enabled outside of development environments.

    • Azure Chipmunk

      •

      May 12, 2025

      I mean, I agree with most use cases that git needs to be the source of truth. But when dealing with development, especially, it doesn’t need to be.