Move from Coolify

A wizard reads your Coolify installation over its API and recreates it here: projects, applications, one-click services, databases, domains, variables, volumes and backup destinations, with the data copied across. The configuration comes over the API; the data is read by a Deplo agent installed on each Coolify server and relayed through the control plane. Pick the tab that matches where Deplo is going: onto the machine Coolify already runs on, or onto a machine of your own.

Before you start

Turn the API on and mint a token

Coolify ships with its API switched off on some installs. If it is off, the scan says so in Coolify's own words: API is disabled. Turn it on under Coolify's Settings. If the API is restricted to a list of addresses, add the machine Deplo runs on, or the refusal reads You are not allowed to access the API.

Then: Keys & Tokens, API tokens. Tick root, and mint it from an account that is an admin or owner of the team. Root is one box and it covers both things a migration needs, reading your values and stopping a service before its data is copied.

If you would rather not grant root, tick deploy first, then read and read:sensitive - in that order, because Coolify's dialog clears the list the moment deploy is ticked. Without read:sensitive Coolify does not blank your values, it removes them from the response: every variable, every database password and every one-click stack's compose file would arrive empty. Deplo checks both at Connect and refuses rather than importing blanks.

One run per source team

A Coolify token is bound to the team it was minted in, and Coolify will not even list the other teams to it. For a second team, switch team over there, mint a token, then paste it here and press Add: it joins the Teams to bring over list with the Deplo team it lands in. Two Coolify teams may land in the same Deplo team, or each in its own.

A single walk of the wizard is one run per team, queued by the control plane and taken one after another. The list belongs to the server, not to the browser tab: close the page, reload it, come back tomorrow.

On every source machine

A Coolify instance often has more than one server, and the Install step lists every one behind the panel.

• One shell command, as root, on each machine behind the panel. It installs the Deplo agent, which is what reads the disks. Installing is outbound, so it works behind any firewall.
• Inbound TCP 9443 on each of them. Reading a volume is Deplo dialing that machine back, which its call home never does. A machine that went green can still be out of reach.
• A snapshot of every machine, taken first. It is one click at every provider, and it covers what nothing in the wizard can put back.
• Room on the destination disk. A copy writes a second copy of everything before the old one goes. Deplo warns under 10% free or under 5 GiB.

What the run stops

Every service you tick is stopped on Coolify when its data copy starts, and on a run that finishes it is never started again. That stop is the cutover. What you leave unticked is not touched at all.

Run the migration

curl -fsSL https://deplo.build/install.sh | bash

What comes across

What lands as what

What changes on the way

• Throwaway hostnames are re-hosted. A name on sslip.io, traefik.me, nip.io or localhost has the old server's IP baked into it, so Deplo mints a generated nip.io address with the same route and the app's Domains section says which became which. Real domains you own come across as they are, and you repoint DNS when you are ready. In a takeover the app lands on the same machine, so the generated name keeps working and stays as it is.
• Connection strings are rewritten. A database keeps its data but not its hostname - it answers as db-<name> here - and every variable that named the old one is updated. What Deplo cannot reach is what an app stores about itself: a saved trusted_domains or siteurl still holds the old address, and the report tells you to fix it from the app's Console.
• A volume keeps the name you gave it. Coolify stores a persistent storage as <resource id>-<name>, and that id is its own bookkeeping, so the volume arrives as plain <name>.
• A volume the compose file pins by name is not the one that was running. Coolify renames every volume a compose declares to <resource id>_<key> and honours neither external: true nor a pinned name:. Deplo copies what was actually running, and the report names the pinned volume so you can decide what to do with what is in it.
• The compose is the one its author wrote, not the copy Coolify renders with its own labels, container names and per-resource network. Deplo writes those itself.
• A published host port comes across, and needs the publish-ports permission. Without it the app still arrives and the report names the ports it left behind. A port under 1024 cannot be republished; a domain is usually the answer.
• A network you created yourself does not come across. It exists only on that machine, and left in place the stack would not start here at all. An Environment owns one network and every app in it shares that one, so two stacks that talked over a network of your own keep talking as long as they land in the same Environment.
• A service name another stack already answers to is renamed. Two one-click stacks in one Environment both calling their database db cannot both have the name; the second arrives as <app>-db, and its depends_on, its variables and its domain follow.
• A bind comes across with what is in it, a single file included. A one-click stack keeps its state beside its own compose file under Coolify's data directory, and a config file Coolify keeps at a real path outside it travels too, landing in Deplo's own files directory rather than recreating Coolify's path. A bind that names a file rather than a directory copies that file alone.
• A {{team.KEY}} reference becomes a real link. A value that is exactly one reference to a shared variable of the same name arrives linked to it, not as a second copy. When the names differ a link cannot express it, so the value Coolify resolved arrives instead and the report says so.
• A server-level shared variable is offered to the project. Coolify scopes it to a machine, across projects; Deplo has no server scope.
• A variable is a secret here only if Coolify marked it one. Deplo never types a variable secret from its name: a secret is write-only and cannot be turned back, so a guess would lock away a value nobody can check. A variable Coolify marks shown once is the exception - but its API answers with no value for most of them, whatever the token holds, so those land plain and empty and the report names the keys. Fill them in under Variables before you deploy.
• An address Coolify stored without a scheme arrives on plain http. It answered on :80 over there, so it answers on :80 here and every link anyone had written keeps working. The report names it; add a certificate under Domains when you want https.
• A template address recorded without a port still routes. A one-click template that declares SERVICE_FQDN_<NAME> and no port has the port read off the service instead, and the report says which one it took.
• A $ Coolify would have expanded is named. Unless a variable is marked literal there, Coolify lets compose expand every $ in its value, so the running value could differ from the one you typed. It arrives written as it was.
• Imported basic-auth credentials are flagged. They never went through Deplo's password policy or the breach check.
• Anything needing a permission you do not hold lands in the report instead, naming what asked for it and who turns it on.

What is left behind

• KeyDB and Dragonfly. There is no engine for either here. Both are named in the report.
• Coolify's own COOLIFY_* variables. They name the machine and the panel you are leaving.
• Deploy keys and connected-source credentials. A public repository clones here with nothing; attach a git connection for a private one, which also turns on auto-deploy.
• Private registry passwords. Coolify never exposes them. Add the registry under Registries before the deploy fails on it.
• A volume's own backup to an S3 storage. Coolify's API writes those schedules but never lists them. Set it again under Backups: one app backup here covers every volume of the app.
• A database backup that saved only to the local disk. There is no destination here to put it on, so the report names it.
• The machine's own files. Coolify files every bind mount under Storages, /etc/localtime and /etc/resolv.conf included. Those belong to the host, and the destination already has its own.

Backing out

Before the data step. Stop and undo removes everything the run created here and takes the agent back off the source. Coolify keeps all of its data.

During or after the data step. Nothing is rolled back. Everything already created here stays as it is, every service whose data did not arrive is marked and refuses to deploy, and what this run stopped on Coolify is started again. The agents stay where they are so the copy can run again.

A takeover, before the ports move. Cancel and remove Deplo starts every service the migration stopped, starts Coolify's own containers with the restart policy each had, removes everything Deplo created here with its volumes and networks, and uninstalls Deplo. It asks for the token again, because the run's own copy is wiped when the run ends.

A takeover, after the ports move. The snapshot is the only way back. If the port move itself fails, the unit puts the ports back and starts Coolify again on its own, and the step offers Try again with the reason - usually a container of yours that grabbed 80 while the proxy was down.

Running the whole thing again is safe: everything already here is kept, its data is copied across again when you tick it, and Install shows the line to paste once more.

Troubleshooting

More in Servers and agents.

Next steps