Move Coolify apps between servers.

Back up one app or a whole server. Paste one command on the new one. It arrives running, and verified.

Start the move View on GitHub

Terminal: coolify-mirror installed with one command, showing its main menu on the old server

Two commands. One on each server.

The first installs the tool and opens its menu. The old server prints the second one after the backup.

Old server

$ curl -fsSL https://raw.githubusercontent.com/mtalavi/coolify-mirror/main/install.sh | sudo sh

New server (copy the real line from your old server)

$ curl -fsSL https://raw.githubusercontent.com/mtalavi/coolify-mirror/main/install.sh | sudo sh -s restore 203.0.113.10/hi4i-2dzx-hmeg-42qp-palx-52s7-zq

example

SHA-256 checked on install Linux amd64 and arm64 Coolify 4.3.x, same version on both

What travels with your app

Pick a domain in a list. Everything that makes it run comes along, and the new server starts it through Coolify itself.

Data, copied while it runs

Volumes, bind folders and files. Containers pause for the seconds a copy takes. Databases never pause.

Backup progress: files, volumes, a database dump and an image, with size, speed and time left

Native database dumps

PostgreSQL, MySQL and MariaDB are saved with pg_dumpall and mysqldump, then loaded with the same image on the new server.

Every Coolify setting

Projects, environments, variables, storages, tags, scheduled tasks and backup schedules. Secrets are re-encrypted for the new server's key.

Dependencies found for you

Pick the app. The Postgres behind its DATABASE_URL is found and offered.

Question: also back up what they depend on, listing shop-db used by shop-web through DATABASE_URL

No rebuild on the new server

The exact images your apps run are shipped. Docker Compose apps start from them without cloning or building, which matters most on a slow connection.

0 builds

Domains, last

Right before anything starts, keep each domain or type a new one. Coolify updates its proxy labels.

The whole move, screen by screen

Real screens from a move to a freshly installed Coolify 4.3.23 with the released tool. Pick a step, then a screen.

On the old server

Make the backup and share it

SSH into the old server as root or a sudo user, then run:

curl -fsSL https://raw.githubusercontent.com/mtalavi/coolify-mirror/main/install.sh | sudo sh

What do you want to do?Back up apps
Which app should be backed up?Arrow keys to the app, then enter. Several: space on each, then enter.
Also back up what they depend on?Yes
Backup settingsRecommended
How should the other server get this backup?Share a link through Coolify's proxy on port 443
On the other Coolify server, run this one commandCopy the green curl line.

Keep this window open while the new server downloads, or press b to keep sharing in the background for 24 hours.

Install and main menu — Install and start: one command, then the menu.

On the new server

Paste the line and say Yes

SSH into the new server and paste the line you copied. It looks like this:

curl -fsSL https://raw.githubusercontent.com/mtalavi/coolify-mirror/main/install.sh | sudo sh -s restore 203.0.113.10/hi4i-2dzx-hmeg-42qp-palx-52s7-zq

example

Getting the backupInstalls, downloads and checks every byte. Nothing changes yet.
Restore these resources into this Coolify?Read the list, then Yes.
DomainsEnter keeps each domain, or type the new one.
Rebuild N application(s) once now?Yes proves the next deploy works here. Slow connection: No.
Restore complete · everything verifiedDone. Open the new Coolify.

The rebuild question only appears for apps Coolify builds from Git. Already have the tool here? Run sudo coolify-mirror and choose Restore a backup.

The pasted command installing the tool and verifying the backup — Paste: install, download and verify before any change.

Your DNS and the old server

Point the domains to the new server

Open Coolify: http://<new-server>:8000Check the apps in the new Coolify. The address is printed at the end.
DNSPoint each domain's A record to the new server's IP.
Old serverStop the moved apps and turn off their scheduled tasks and backups.

The menu has the whole move as a guide: sudo coolify-mirror, then How it works.

The built-in guide How a move works — The built-in guide, from backup to free space.

On both servers

Delete the backups you no longer need

sudo coolify-mirror

What do you want to do?Saved files & disk space
What do you want to clean up?All backups
Which backups should be deleted?First line ALL takes every backup. Or enter on one, or space on several.
Delete N backup(s) and free X?Yes. The default is No.

On the new server, once everything works, also delete the safety copies under Everything kept here. Without the menu: sudo coolify-mirror files delete --backups

Summary of saved files and the clean up question — What the tool keeps here, and the free disk space.

↑↓move enterchoose spacetick several /search escback ctrl+cstop

Restore complete means it really runs

Coolify starts everything. Then the tool checks what actually happened, and says so plainly when something does not work.

Restore complete, everything verified: shop-db and shop-web running, domains answering through the proxy

Same services

Every service that ran on the old server is up on the new one.

Stable for 30 seconds

All containers healthy, without a single restart.

Domains answer

Each domain is reached through the local Traefik, not just configured.

Next deploy works

Optional rebuild from the same commit, without cache.

Real moves

Three runs on real Coolify 4.3.23 installs, with what was measured.

A 7-service Compose app over a slow link

A production Docker Compose app with 7 services, Postgres, 6 volumes and a build script on the host, moved to a server with a slow internet connection.

~1 minto running, no clone, no build

Coolify deploy11 minutes of cloning alone, then hours of building

Coolify MirrorStarted from the shipped images in about a minute

6 containers healthy, Coolify showing running:healthy
The domain answered 200 through the new server's Traefik
One deployment recorded, with the new server's IDs

Five kinds of apps, zero manual fixes

0manual fixes

A Compose app with a host build script and a named buildx builder, a Dockerfile app, an image app, WordPress with MariaDB, and Postgres. Same secrets, volume data and database rows (md5) as the source, every domain answering, and a full rebuild on the new server.

From paste to verified

2m 39srestore to verified

The tutorial above: an app and its Postgres moved through port 443 to a brand-new Coolify. The 47.5 MB download and its checks took a second on the lab network.

Built so nothing gets lost

Encrypted end to end

The backup is one age-encrypted file. It travels over HTTPS with a certificate pinned by the share code. Plain HTTP is never served.

Checked before anything changes

Same Coolify version, disk space, Coolify's own bundle validation, conflicts, and a trial import in a transaction that is rolled back.

Rollback

If the import fails, everything it created is removed. A full restore puts back the previous Coolify database and .env.

Nothing deleted behind your back

An existing volume keeps its data as <name>.cm-old-<time>. Replaced folders stay as safety copies until you delete them.

One run at a time

A lock stops two backups or restores at once. Paused containers always resume, even after ctrl+c.

Ready for Coolify updates

Every run checks the Coolify parts it relies on. A daily job moves real apps between two fresh installs of each new Coolify release.

Under the hood

One file goes from one server to the other. This is what happens on each side.

Old server

Coolify rows of the picked apps
volumes, files, images, dumps
Coolify's own transfer bundle
tar, zstd, age: backup.cmb

HTTPS on port 443, pinned certificate

New server

download, resume, verify
preflight and trial import
restore and import, new IDs
start through Coolify, verify

The tool

Go 1.26, one static binary for Linux amd64 and arm64
Bubble Tea, huh and Lip Gloss for the terminal interface
age encryption (scrypt passphrase) and zstd compression

Inside Coolify

Server Transfer bundle (schema_version 1), made and validated by Coolify's own code
Secrets decrypted with the old APP_KEY, encrypted again with the new one
Traefik TLS passthrough carries the share on port 443

Releases

GitHub Actions builds every release and its SHA-256 sums
The installer checks the checksum before anything runs
A daily test runs a full move on each new Coolify release

Version history

Every release is on GitHub Releases with its binaries and checksums.

1.7.12026-10-07

A step-by-step guide

A 4-step quick start and every screenshot retaken from a real move. Behind Coolify's proxy, the share screen names the other server instead of the proxy's address.

1.7.02026-10-06

All backups at once

The ALL line deletes every backup in one go, or pick some. On the command line: files delete --backups.

1.6.02026-10-06

Saved files and disk space

See and delete what the tool keeps on both servers. Enter picks the highlighted app, Recommended settings, and a built-in guide.

1.5.02026-10-06

Share codes and one command

One short command per server. Checks against every Coolify update, and coolify-mirror update.

1.4.02026-10-06

Compose apps without a build

Docker Compose apps start from the restored images, without cloning or building.

1.3.12026-10-06

Verified restores

Success only when the new server really runs the apps. Build dependencies on the host travel too, and --verify-redeploy proves the next deploy.

1.2.02026-10-05

Pinned HTTPS and native dumps

HTTPS-only transfer with a pinned certificate, native database dumps, a mandatory preflight, and Coolify's official transfer bundle inside.

1.1.02026-10-04

Domains last, open source

A domains step at the end of every restore. Released under MIT with a one-line installer.

1.0.02026-10-01

First release

Selective and full backups, sharing, restores with rollback, and the interactive menu.

Questions

Which Coolify versions work?

Coolify v4.3.x, with exactly the same version on both servers. At start the tool says whether this version is tested. If the versions differ, it tells you which server to upgrade.

Does the old server go down during the backup?

No. With Recommended settings, containers pause only for the seconds their volume copy takes, and databases are dumped while they run. Nothing is deleted on the old server.

Can the new server already have other projects?

Yes. Backing up apps merges them into the new Coolify and keeps everything that is there. An app that already exists can be restored as a copy or skipped. A whole-server backup only goes onto a fresh, empty Coolify.

The new server cannot connect to the old one.

Port 443 of the old server is blocked. On the old server press q, choose Share a saved backup, the same backup, then Share a link on port 8123. Allow 8123 in your provider's firewall too, and run the new command it shows.

My SSH connection dropped during the download.

Keep the old server sharing and run the same command again: the download continues where it stopped. On big servers, run the tool inside tmux.

The new server has no access to GitHub.

The old server also prints a second command that downloads the tool from the old server itself, over the same pinned connection.

What does not move?

Resources on remote servers, preview deployments and Swarm. Webhooks and DNS keep pointing to the old server until you switch them. Between different CPU architectures, Coolify rebuilds the apps.

Is this an official Coolify tool?

No. It is an independent open-source project under the MIT license, not affiliated with Coolify or coolLabs.

Your next move takes two commands.

$ curl -fsSL https://raw.githubusercontent.com/mtalavi/coolify-mirror/main/install.sh | sudo sh

Start the move View on GitHub