Instance migration

Instance migration moves a whole instance — the container/VM image and every site in it — from one node to another, including across providers (VPS → dedicated, provider A → provider B). It is the superset of the per-app Transfer app: a transfer moves one site by backup-and-restore; a migration ships the whole image via the reserved export → encrypt → stream → import path, then re-maps the network and cuts traffic over.

Migrate vs. Transfer app — which one?

Use Transfer app to move a single site between instances; use Migrate to move everything at once, or to move an instance to a different provider.

📷The instance workspace — Migrate (next to Edit limits / Remove) moves the whole instance to another node.img/instance-migrate-button.avif

The three scopes

The panel derives the scope from the source and destination — you don't pick it:

• Same-class — source and destination are the same topology class (e.g. both VPS). Only the network layer changes: import the image, re-map the NIC/IP, re-point routes, cut over.
• Cross-class — the destination class differs (e.g. VPS → dedicated with a routed IP block). On top of same-class, the migration reconciles topology — the address mode (NAT ↔ routed) and whether the instance can carry a routed IP — against the destination class before the move.
• Cross-provider — a different provider, possibly a different class and network fabric. The superset: a capacity and architecture precheck on the destination, resumable streaming for a multi-GB image over a flaky cross-provider link, and a cutover plan with rollback.

Consistency: snapshot vs. stop

A live root filesystem copy is torn (files change mid-read), so a migration never exports a running instance raw. You choose how the source is made consistent first:

• Snapshot (default) — snapshot the source, export the snapshot. The source keeps serving during the export — least downtime.
• Stop — stop the source, export, then restart it. A guaranteed-quiescent image at the cost of source downtime — the strict case.

How a migration runs

1. Precheck. Validate the source against the destination class (topology) and, for a cross-provider move, the destination's capacity and architecture. An illegal or over-capacity destination is refused up front — before anything is exported, so you're never left half-migrated.
2. Snapshot / stop the source for a consistent image.
3. Export the image out of the source node and encrypt it in the panel (the same envelope a backup uses — the key never reaches either node).
4. Stream the encrypted image to the destination, resumably: a dropped link picks up from the last acknowledged chunk, not from zero.
5. Import the image on the destination node — the instance materializes there.
6. Re-map the network: assign the destination's NIC/IP (re-mapping the address mode if the class differs), re-point every site's routes, and update DNS where the panel owns the zone.
7. Cutover — start the destination and health-check it; traffic flips only on a pass.
8. Teardown (optional) — tear the source down only after a proven-healthy cutover.

DNS at cutover

A whole instance can host many sites across many zones:

• The panel manages the zone (a self-hosted zone or a connected DNS provider account): the record is re-pointed automatically to the new node's IP.
• External DNS: the panel can't change it for you — you'll get the new node's IP to update each A/AAAA record yourself. If you also chose to tear the source down, you must tick "I've updated external DNS" first, or those hostnames would black-hole.

Rollback

Rollback is automatic on a failed cutover health-check — the source keeps serving the whole time, so traffic stays on it until the destination is proven. While a migration is in flight the workspace shows a Roll back button; it surfaces this honestly (there is no separate "cancel mid-stream" — that is a follow-up that needs a worker control hook the engine does not yet wire). To return to the original node after a successful migration, start a fresh migration back.

Starting a migration

In the instance workspace, click Migrate (admin only):

1. Pick the destination node (any other online standard node — a nameserver/storage box can't host workloads), the consistency mode, and — for a destination that can carry a routed IP — the address mode.

   

   📷Step 1 — pick the destination node, the consistency mode (snapshot vs. stop), and whether to tear the source down after.img/instance-migrate-pick.avif

2. Review the move: source → destination, the scope the panel will derive, and the DNS handling.

   

   📷Step 2 — review source → destination and the DNS handling. The panel re-checks the scope, capacity, and architecture before it moves anything.img/instance-migrate-confirm.avif

3. Confirm. A live progress view then shows the state, the bytes-streamed bar, and the current step as the migration runs — with the Roll back button described above.