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:
Move the worker pool and VCS integration to the root space temporarily
Update the stack's space_id to move it to the target space
The stack will inherit the worker pool and VCS integration from the root space
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:
Create a temporary worker pool in the target space
Update the stack to move to the target space, pointing to the temporary worker pool and target VCS integration
After the move succeeds, switch the stack to the desired worker pool in the target space
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.