Skip to main content
There is no safe one-click conversion from a Coolify instance to Towbar. Treat the move as a workload migration: inventory the current configuration, express the intended state in Towbar manifests, copy persistent data with the application stopped or read-only, verify the new deployment, and move traffic last. Coolify’s own application migration guide follows the same principle: recreate configuration on the destination, test through a temporary domain, migrate each stateful dependency deliberately, and retain the source for rollback.

​
Decide whether Towbar fits

This comparison is about fit, not an automatic claim that one platform is safer or faster. Validate the exact workload, build method, persistence model, and recovery procedure before choosing.

​
1. Inventory Coolify

For every application, record:
  • repository or image, branch, base directory, build method, Dockerfile or Compose paths, build and start commands;
  • domains, internal ports, health checks, replicas, CPU and memory limits, and restart behavior;
  • runtime variables, build variables, preview variables, and shared-variable references;
  • persistent volumes, directories, files, owners, permissions, and mount paths;
  • scheduled tasks, webhooks, preview settings, log drains, and external dependencies; and
  • the current commit or immutable image digest.
For every database, record its engine, major version, database names, users, extensions, volume size, connection consumers, backup format, backup destination, retention, and the result of the latest restore test. Coolify documents application variables separately from database variables, so inspect both.
A Coolify control-plane backup is not a workload-data migration. Coolify’s instance backup documentation explicitly separates its own database from application, database, and volume data.

​
2. Map each workload

Choose a Towbar deployment mode for every application: Read Deployment modes before moving Compose. Towbar rejects privileged containers, Docker socket mounts, host bind mounts, fixed public host ports, remote includes, external namespaces, and several other patterns that a general Compose installation may permit. Create towbar.yml and one entity file per app or resource. Run schema validation in the repository before connecting it, then connect each environment to its branch. Keep automatic deployments disabled during migration.

​
3. Recreate credentials and integrations

Configure GitHub or GitLab, registries, backup storage, notifications, log forwarding, Cloudflare, and external-secret providers in Towbar’s host environment. Only correctly configured providers appear under Manage → Integrations. Copy application values into Shared secrets or workload environment secrets. Do not copy Coolify’s encrypted database rows or encryption key into Towbar. Rotate long-lived credentials where practical, and update OAuth callback URLs, provider webhooks, CI secrets, and allowlists for the new Towbar origin.

​
4. Prepare a destination server

Install Towbar on a separate control-plane host, register the destination server, verify its SSH host key, and complete Server Preparation. You can reuse a workload server only after checking port, network, volume-name, and proxy conflicts. A separate destination is easier to test and roll back. Deploy stateless apps first through temporary domains. Verify the expected commit or image digest, health check, logs, outbound access, scheduled jobs, and private service connections.

​
5. Move persistent data

Use an engine-aware logical backup for databases. Coolify supports engine-specific backup and restore flows for several engines; review its current backup and restore instructions and compare the archive with Towbar’s supported format and major version. For application volumes or directories:
  1. Create the destination volume and confirm the expected container user.
  2. Stop writes on the source.
  3. Copy the files while preserving ownership, permissions, links, and timestamps.
  4. Start the destination and verify reads, writes, uploads, and background work.
Do not copy the live filesystem of a running database as a substitute for a logical backup. For a large dataset, rehearse the transfer and measure the final synchronization window before scheduling the cutover.

​
6. Cut over and verify

  1. Lower DNS TTL ahead of the change when you control DNS directly.
  2. Stop source writes and create the final database backup or file synchronization.
  3. Restore into Towbar, verify representative records, then start dependent apps.
  4. Test login, writes, uploads, jobs, queues, email, OAuth, webhooks, backups, and alerts through a temporary hostname.
  5. Assign the production domain in the manifest, sync, deploy, and update DNS if the server address changed.
  6. Confirm TLS, health, logs, a manual deployment, a backup, and notification delivery.
Keep Coolify stopped but intact for the agreed rollback window. If Towbar accepts new writes after cutover, returning DNS to the old service is not enough; reconcile that data before rollback.

​
Migration checklist

  • Every workload, dependency, secret, domain, job, webhook, and volume is inventoried.
  • Every Towbar manifest passes schema validation and review.
  • The target server is prepared and has enough CPU, memory, and disk headroom.
  • Persistent data has a tested, engine-aware migration path.
  • Temporary-domain tests cover critical user and background flows.
  • Production cutover and rollback owners, times, and data boundaries are written down.
  • Towbar backups and a restore rehearsal succeed before the source is removed.
Continue with Your first deployment, Database backups, and Troubleshooting.
Last modified on September 22, 2026