Skip to main content
Live. This area is documented as current, user-reliable behavior.

​
Goal

Set the right operator expectations before moving stack workloads across nodes.

​
Prerequisites

  • A stack with a known placement target

​
Workflow

1
Treat stateless reassignments differently from stateful migrations.
2
Use backups and restore-aware thinking for stacks with named volumes.
3
Confirm health on the target side before treating the move as complete.

​
What reassign does

Reassign repoints a stack at a different node and redeploys it there. For a stateless stack this is the whole story: the stack comes up on the new node and you confirm health.

​
Stateful stacks need backup-and-restore thinking

Named-volume data does not silently follow a stack across nodes. For a stateful stack, treat a move as a backup-and-restore operation: take a stack backup first, then restore it on the target so the volume data is actually present where the stack now runs.
  • Back up the stack before moving anything stateful.
  • Restore from a completed backup on the target node.
  • Do not assume volume data migrated just because the stack redeployed.

​
Confirm the move

A redeploy finishing is not the same as a healthy stack. Check service health and the application itself on the target before you consider the migration done.

​
Expected result

You understand how safe stack movement works today and where caution is still required.

Back up and restore a stack

Use S3-backed named-volume archives to protect and recover stateful stack data.

Stack logs, health, and placement

Use the stack detail, logs, and placement information to understand how the stack is actually running.

Recovery states, logs, and troubleshooting

Read the operation state on a resource — its status, current step, attempt count, retryable flag, and last error — together with logs, instead of treating a single “error” badge as the whole story.