Migrate an application
This guide moves one application from a source Coolify instance to a destination Coolify instance. It does not migrate the Coolify control plane, team members, servers, projects, or instance settings.
Coolify does not provide a single export and import operation for an application. Recreate the application on the destination instance, verify it with a temporary domain, move every stateful dependency, then transfer production traffic.
Data can change while the source application is running. Stop writes or stop the source application before the final database dump or file copy. Keep the source unchanged until the destination is confirmed stable.
Before you start
Make sure you can access:
- both Coolify instances
- the source and destination deployment servers over SSH when files or Docker volumes must be transferred
- the Git repository or image registry used by the application
- DNS for the production domain
- credentials for databases, object storage, email, OAuth, and other external services
Record the configuration from the source application:
| Source page | Record |
|---|---|
| Configuration > General | Source or image reference, branch, build pack, base directory, build-file locations, commands, domains, internal ports, and host port mappings |
| Configuration > Environment Variables | Production variables, build-time settings, preview variables, and shared-variable references |
| Configuration > Persistent Storage | Mount type, volume or source path, destination path, file content, and read-only setting |
| Configuration > Advanced | Deployment, Git, proxy, container, and operational settings that differ from the defaults |
| Other configuration pages | Health check, resource limits, scheduled tasks, webhooks, servers, tags, and preview settings |
Also list every database, cache, queue, storage bucket, callback URL, and third-party dependency used by the application. Coolify cannot discover all state held outside the container.
Choose how each type of state moves
One application can use several of these paths.
| State | Migration path |
|---|---|
| No persistent application data | Recreate the configuration and deploy from the same source or image. |
| Database | Create a logical backup with the database engine's supported tool, transfer it, then restore it into the destination database. |
| Docker volume | Stop writes, archive the named volume, transfer the archive, and extract it into the destination volume. |
| Directory or bind mount | Copy the exact source directory to the destination server while preserving ownership and permissions. |
| Coolify-managed File Mount | Recreate the file and its destination path in the destination application. |
| Host File Mount | Copy or independently recreate the host file at the required destination-server path. |
| External object storage or managed service | Keep the existing dependency or migrate it with that provider's supported process, then update the destination variables. |
Do not copy a running database's Docker volume as a substitute for a database-aware backup. Live database files can produce an inconsistent or unusable copy.
Recreate and test the application
Prepare the destination
Add and validate the destination deployment server. Confirm that its proxy is running, it can reach required registries and external dependencies, and it has enough CPU, memory, and storage for the application.
Create required private keys, Git integrations, registry authentication, S3 destinations, and shared variables on the destination instance. These instance and team resources are not copied with the application.
Recreate the application
Create a new application with the same deployment method and enter the recorded configuration.
Use a temporary domain and non-production credentials for the first deployment. Do not assign the production domain or change production DNS yet.
If the source application references shared variables, recreate those variables first or replace each reference with the intended destination value.
Verify the application without production state
Deploy the destination application and confirm that Coolify builds or pulls the intended image, starts the container, and passes its health check.
Open the temporary domain and verify the internal port, environment variables, outbound network access, and connection to non-production dependencies. Resolve build, proxy, or network failures before moving production data.
Move application state
Create destination mounts before restoring data. Then use each path that matches the application's state. One application can use several paths.
Databases and external dependencies
Create a logical database backup with the database engine's supported tool. Transfer and restore it into the destination database, then update the destination application variables with the new connection details.
For a Coolify-managed database, create the recovery file with Database backups, then follow Restore a database when the destination engine supports Coolify's import workflow. Verify required tables or records before the destination application uses the database.
Move object storage, queues, caches, and other external state through the provider's supported process. A cache usually does not need migration unless the application treats it as durable data.
Do not copy a running database's Docker volume as a substitute for a database-aware backup. Live database files can produce an inconsistent or unusable copy.
Persistent files
Use the subsection below that matches each mount, then confirm the destination container user can read and write the restored content.
Cut over to the destination
Perform the final synchronization
Stop writes or stop the source application. Create a final database dump and copy any files changed since the test migration.
Restore that final state on the destination, then redeploy or restart the destination application so it uses the final variables and mounts.
Transfer production traffic
Test the destination through its temporary domain first. Verify login, reads, writes, uploads, background jobs, email, OAuth, webhooks, and other critical integrations.
Assign the production domain to the destination application and update DNS when the domain points to a different server. Confirm TLS issuance and routing before declaring the migration complete.
Reconnect automation
Update manual Git webhooks, authenticated deploy webhooks, CI secrets, scheduled tasks, registry credentials, monitoring, and external callback URLs that still reference the source instance or server.
Trigger one test deployment and one scheduled or background operation.
Move a Docker volume
Use the scheduled storage mount backup workflow when it supports the source mount. Download the resulting .tar.gz archive before the migration because the dashboard does not restore storage archives.
Move a directory, bind mount, or host file
Find the exact source-server path under Configuration > Persistent Storage. Stop writes, then copy the contents while preserving ownership and permissions.
For a directory, run from the source server:
rsync -a --numeric-ids -e "ssh -p <ssh-port>" \
<source-path>/ \
<ssh-user>@<destination-server>:<destination-path>/The trailing / on <source-path>/ copies the directory contents into <destination-path>/.
Create the same mount in the destination application with the destination server's source path and the container's original Destination Path. For one Host File Mount, copy the file instead of the directory and confirm its destination-server path before starting the application.
For a Coolify-managed File Mount, recreate its content in the destination dashboard rather than copying a generated internal path.
Verify the migration
Confirm all of the following on the destination:
- the production domain serves the destination application with valid TLS
- the intended source revision or image is running
- health checks and application logs show a stable runtime
- login, reads, writes, uploads, and downloads work
- databases contain the expected final records
- scheduled tasks, queues, webhooks, email, OAuth, and external callbacks work
- backups run and create a usable destination copy
Monitor the destination until it is confirmed stable. Keep the source application stopped but unchanged, and retain the final backups for the rollback period you selected.
Roll back the cutover
If the destination fails after traffic moves:
- stop writes to the destination
- determine whether production data changed on the destination after cutover
- restore or synchronize those changes back to the source dependencies when required
- return the production domain or DNS record to the source application
- start the source application and verify its critical user flow
Do not send traffic back to an older source database without accounting for writes accepted by the destination. DNS rollback changes routing; it does not merge data.