Skip to main content
This is the audit behind the Coolify exit plan. It compares what a Coolify v4 instance holds with what the importer reads, and says for each item whether it moves, is reported, or is invisible to the tool.

​
How far to trust this

No real Coolify instance was available while this was written. The importer was checked against JSON fixtures shaped from Coolify’s documented API responses, with fake credentials. That proves the mapping logic, the read-only guarantee (the fixture server rejects every non-GET) and the report. It does not prove that a field name or route matches your Coolify version. Field names such as is_build_time, manual_webhook_secret_github and the /databases/{uuid}/backups route are best knowledge, and a read that fails softly shows up as a note on the report instead of stopping it. Before you delete Coolify, run migrate coolify --dry-run against your own instance, then compare the output with the Coolify dashboard for two or three apps you know well.

​
Audit

Status words: moves means created on the new side, reported means the tool names it and you finish it, invisible means the tool does not read it at all.

​
What the exit plan adds

  • migrate coolify --dry-run prints a precise plan, one row per resource with its outcome: imported, manual or skipped, each with the reason and the next step.
  • The same report is available over the API, in the dashboard import flow and as a read-only MCP tool.
  • A DNS switch order (stateless apps first, apps with a volume and a database last) and an ordered cutover checklist that keeps Coolify as the fallback until you have verified.
  • ready_to_retire is true only when every resource is imported and nothing needs a person. Skipped items always block it.

​
Not proven yet

  • A run against a real Coolify instance, including large instances with many environments.
  • That Coolify’s API returns the fields above for every build pack and version.
  • Restoring a backup copied across, and the write pause needed for a database that takes writes during the final copy.
  • Fallback to Coolify after the first write lands on the new database. Copy the data back first.

​
Next gaps, by value

  1. Map Coolify environments to Levelrail environments instead of one project.
  2. Import database backup schedules and S3 targets instead of listing them.
  3. Detect apps that depend on a custom Docker network.
  4. Per-server node placement for multi-server instances.
  5. Recreate git webhooks through the git provider integration.
Last modified on October 23, 2026