Instance migration: move Coolify control plane + workloads to a new VM

[mdrakibislam68]

Problem

Today Coolify can add servers and copy/clone resources, but there is no first-class way to move an entire Coolify instance (dashboard + coolify-db + APP_KEY/SSH keys + resource volumes) to a new VPS.

Common need: replace the Coolify host, change providers, or recover onto fresh hardware while keeping projects, apps, services, and data.

Manual recovery today usually means dumping Postgres, reinstalling Coolify, restoring keys, and copying Docker volumes by hand — easy to get wrong (especially with non-root SSH).

Proposal (high level)

Add an Instance migration flow (Settings → Migrations) that:

1. Packages a backup from the current Coolify host (coolify-db dump, APP_KEY, SSH keys)
2. Installs Coolify on a fresh target VM (or reuses an empty install)
3. Restores the control-plane database into the new coolify-db
4. Syncs persistent volumes from managed servers onto the new host
5. Reassigns resource destinations to localhost on the new instance
6. Verifies the new dashboard is reachable

Keep a separate resource copy path for copying selected resources between already-managed servers (without installing a second Coolify).

Why discuss first

CONTRIBUTING.md asks for discussion before large features / UI. This touches settings UI, remote SSH orchestration, and backup/restore of the control plane — so I want maintainer alignment before opening a feature PR.

Questions for maintainers:

1. Is this in scope for v4 / current main, or should it wait for v5?
2. Preferred UX: Settings page vs CLI-only (artisan) vs both?
3. Any hard constraints around restoring coolify-db / rotating APP_KEY / APP_PREVIOUS_KEYS?
4. Should volume sync be optional / best-effort vs required for “completed”?

Status

I have a working prototype from real multi-VM testing (including non-root SSH permission issues on /data/coolify). Happy to adjust scope or split into smaller PRs based on feedback.

Related bug-fix PR (separate, already opened): #11252

[jcruzer2012]

I have essentially the same use case.

I already have multiple servers configured and validated in Coolify as deployment targets. What I’d really like is the ability to take one of those existing managed servers and promote it to become the new Coolify localhost / control-plane host from the GUI.

Ideally, Coolify would handle the migration of the controller state, keys/secrets, database, and internal references automatically, then preserve the existing relationships to all of the other managed servers.

That would make moving the Coolify control plane much safer and simpler than doing a manual migration, especially for users who already have the destination server connected and working.

[mtalavi]

The manual database, keys, and volume steps you describe are why I built Coolify Mirror, an independent open-source migration CLI/TUI: https://github.com/mtalavi/coolify-mirror

Super fast to get started, super easy to use: make a backup on the source server, paste the generated restore command on the destination, then review and confirm the move.

For a move to a new self-hosted Coolify instance, it can package a whole instance or selected resources with configuration and persistent data, restore them, and check the result. A full restore requires a fresh, empty destination and the exact same Coolify v4.3/v4.4 version on both hosts. It also needs root/sudo access. The GUI flow for promoting an already-managed server to localhost is a different use case, so I would not claim this covers that workflow.

If the new-host case is relevant, please check the repo and its limitations. Ideas or reports about unsupported setups are welcome. Not affiliated with Coolify.