Moving stacks between spaces with different worker pools and VCS integrations

Last updated: September 15, 2025

When moving a stack to a different space that uses a different worker pool and VCS integration, you cannot update all three attributes (space_id, worker_pool_id, and VCS integration) simultaneously in a single operation. This is because both VCS integrations and worker pools are scoped to the space they're created in, and Spacelift validates these resources from the stack's current space before the move completes.

Why the error occurs

The validation process creates a catch-22 situation:

  • Target-space resources aren't visible yet when you try to reference them

  • Source-space resources stop being valid as soon as you change the space_id

Solution options

Option 1: Use root-level inheritance (Recommended)

This is the most straightforward approach:

  1. Move the worker pool and VCS integration to the root space temporarily

  2. Update the stack's space_id to move it to the target space

  3. The stack will inherit the worker pool and VCS integration from the root space

  4. After the move is complete, you can re-scope the resources back to the appropriate spaces if needed

Option 2: Use a temporary worker pool

If you cannot use root-level inheritance:

  1. Create a temporary worker pool in the target space

  2. Update the stack to move to the target space, pointing to the temporary worker pool and target VCS integration

  3. After the move succeeds, switch the stack to the desired worker pool in the target space

  4. Remove the temporary worker pool

Both methods ensure the stack always has valid resources at each step and preserve your run history, avoiding the need to destroy and recreate stacks.

For more information, see the official documentation on moving stacks.