Migrate from Fly.io to Coolify

Migrate from Fly.io to Coolify: what the move involves

Moving from Fly.io to Coolify is mostly application and data work, not a rewrite. Most apps that run on Fly.io already ship as a container built from a Dockerfile, and Coolify can build that same Dockerfile from a Git repository, so the main job is translating the settings in fly.toml into Coolify configuration and moving the data. Platform or DevOps teams usually own this work, sometimes with an implementation partner for the database cutover and the server hardening. The effort and risk concentrate in three places: stateful data (volumes and Postgres), TLS and DNS cutover, and the operational duties that Fly.io currently carries for you. Coolify is licensed under Apache-2.0, and its pricing page describes the self-hosted edition as free forever with all features and no limitations or restrictions, so the software itself carries no license fee. What you pay for instead is the servers, their bandwidth, and the time your team spends running them. Start with an inventory of the fly.toml file for each app. Map the [build] section to a Dockerfile build pack, the [[services]] and [http_service] blocks to ports and domains in Coolify, and each entry under [processes] to a separate Coolify resource if web and worker roles must scale or restart independently. Release commands and health checks need a deliberate replacement, because Coolify's deployment flow does not reproduce every Fly.io hook one for one, so confirm the exact behavior in the Coolify documentation for your version before you rely on it. Note every [[mounts]] entry, since persistent files do not follow an image rollback. The operator takes on capacity, backups and recovery. Coolify's guide for teams coming from managed platforms notes that a rollback can redeploy a retained application image but does not restore databases or persistent files. Before you cut over, decide who owns server patching, disk growth, database backups, restore tests and certificate renewal, and ask your implementation partner or internal team to write those duties down. Per-region placement also ends: a Fly.io app running in several regions needs a new plan on your own servers, and that choice belongs in the scope document before any work begins.

Which Fly.io features map cleanly to Coolify and which need rework

This table maps the main fly.toml and Fly.io platform features to their Coolify equivalents and marks each as clean, needs rework or gap. Use it to scope the migration before you touch configuration, then confirm the details named in the last column against the current Coolify docs for your version.

Fly.io feature	Coolify equivalent	Status and what to check
Dockerfile build	Dockerfile build pack from a Git repository	Clean. Reuse the same Dockerfile; confirm build arguments and build target in the build pack docs.
Buildpack build (Heroku-style builders)	Nixpacks or Railpack (beta) build pack	Needs rework. Output and detected runtime can differ, so test the build and start command before cutover.
Prebuilt image deploy	Docker Image build method	Clean. Pull the existing image and set environment variables in Coolify.
Services and internal ports	Exposed port and domain settings on the application	Needs rework. Map each public port and confirm which ports stay private, since Coolify routes HTTP traffic through its proxy.
Processes (web and worker groups)	Separate applications, or Docker Compose services	Needs rework. Confirm current process group support in the Coolify docs; many teams split workers into their own resources.
Health checks	Health check settings on the application	Needs rework. Recreate checks and confirm restart behavior in the current docs.
Release commands	Pre- or post-deployment commands	Needs rework. Confirm how the current version runs one-off commands such as migrations before the new container takes traffic.
Volumes and mounts	Persistent storage on the server or Compose volumes	Gap for direct equivalence. Volumes are tied to one server, so confirm support and plan data copies explicitly.
Secrets	Environment variables set in Coolify	Clean. Move values through the Coolify interface or API, and keep a record of which secrets moved.
TLS certificates	Traefik or Caddy proxy with automatic HTTPS	Clean for standard domains. Point DNS at the server first; Custom (None) proxy mode leaves TLS to you.
Fly Postgres or Managed Postgres	PostgreSQL resource deployed by Coolify with scheduled backups	Needs rework. Backups cover PostgreSQL, but restores and failover are your job, and replication needs separate setup.
Multi-region placement	Multiple servers managed over SSH, one deployment target each	Gap. Coolify does not place one app across regions automatically; plan which regions and servers replace each Fly region.
Autoscaling and machine sizing	Fixed server resources and manual scaling	Gap. Size servers for peak load and confirm current multi-server behavior in the multi-server docs.

Which data and integrations to move, and how

A Fly.io to Coolify move touches four kinds of state: code and images, database contents, files on volumes, and the routing and integrations that point at the app. Each has its own export or re-creation step, and most of them are easy to miss until traffic is already on the new server. Work through the cards in order before cutting over DNS.

Application code and Dockerfiles

Coolify deploys from a Git repository, a Dockerfile, a Docker Compose file or a prebuilt image. If your Fly app is built from a Dockerfile, the same file can usually be reused, which keeps the build path unchanged. Confirm that the repository is reachable from the Coolify server, that the deploy key or Git App has access, and that the branch and build context match what fly deploy used. Apps built from buildpacks on Fly need a choice of build pack in Coolify, so test the build on a staging server first.

Container images and registry access

If you deploy a prebuilt image rather than building from source, Coolify's Docker Image method pulls it directly. Private images need registry credentials stored in Coolify before the first deploy. Check which image tags Fly was running, since a tag such as latest can point to a different build later. Pin a specific digest or version tag on the new server so that a rollback is predictable, and confirm where the image is stored and who can pull from it.

Postgres data and dump formats

Export the database with pg_dump in custom format, which Coolify's Import Backup accepts, or as a plain SQL dump, which it also accepts. Match the PostgreSQL major version on the target to the source to avoid restore errors, and test the restore on a copy before the cutover window. Confirm the export method against current Fly Postgres documentation, because Fly's tooling and connection details change over time. Plan a final sync step for writes that arrive after the dump starts.

Persistent files on Fly volumes

Fly volumes are not moved automatically. Coolify's persistent storage is attached to the container on the target server, so files such as uploads or generated assets must be copied across as a separate step. Inventory which paths are mounted as volumes in fly.toml, copy them out with an approach you confirm against Fly's current volume documentation, and verify file counts and checksums after the copy. Coolify's managed database backups do not cover these files.

Secrets re-entry

Secrets set with fly secrets are not carried over, so each value must be re-entered in Coolify's environment settings for the application. Build-time and runtime variables may need to be separated, since some values are only read during the build. Rotate credentials that were shared with contractors or stored in chat logs during the migration. Keep a record of which secret was entered, by whom and when, for your change log.

DNS, certificates and webhooks

Coolify's proxy issues HTTPS certificates for domains once DNS points at the new server, so lower the TTL on the existing records before the change. Fly-managed certificates do not transfer, so plan the point at which the new server takes over each hostname. Git providers need the webhook or GitHub App reconnected to Coolify, and preview deployments need wildcard DNS for the {{pr_id}}.{{domain}} pattern. Check each record, certificate and webhook from an outside network before retiring Fly.

Migration sequence from inventory to decommission

This sequence moves each Fly.io app, volume and database to Coolify in an order that keeps Fly running until the new servers have proven they can serve traffic and restore data. Each step ends with a written record that the next step depends on.

Build the inventory of apps and resources
List every Fly app with its fly.toml, Machine count and size, process groups, attached volumes, Postgres clusters, certificates, custom domains, secrets and regions. Record which resources serve production traffic, which run scheduled tasks and which exist only for testing. The owner of each app signs off the sheet. Done means one inventory sheet exists per app, every domain has a named owner, and every volume and database has a recorded size and last backup date.
Map each app to a Coolify build method
For each app, decide whether Coolify will build from the existing Dockerfile, use a Nixpacks or Railpack build pack, or deploy a prebuilt image through the Docker Image method. Translate fly.toml settings into Coolify configuration: ports, health checks, release commands, environment variables and persistent storage paths. Confirm which settings have no direct equivalent and need a workaround, such as per-region placement. Done means a mapping table lists each setting, its Coolify target and any open question for the owner.
Stand up a pilot app on a Coolify server
Provision one non-critical app on a server that Coolify manages over SSH, using a server that meets the published minimum requirements for CPU, memory and disk. Point a test subdomain at it, confirm the reverse proxy issues certificates and run the app's health checks. Test a deploy, a rollback and a restart. Done means the pilot passes a written checklist covering deploys, TLS, logs, secrets and the rollback path, and the team has reviewed the results.
Migrate data and rehearse the restore
Copy volume contents to the new server and move Postgres data with a method that fits the downtime the business accepts: a logical dump and restore, or logical replication between versions. Restore a copy of the production data into a separate Coolify database and run the application's read and write tests against it. Coolify's backups cover PostgreSQL but not Redis, so plan Redis contents separately. Done means a restore test log records the restore time, row counts, application test results and any data differences.
Run both platforms in parallel and sync data
Deploy the remaining apps to Coolify while Fly continues to serve production. Keep the database replicated or synchronized on a schedule the team agrees, and compare logs, error rates and job output between the two platforms. Confirm that background workers and scheduled tasks run exactly once, because duplicate runs are a common failure during parallel operation. Done means the owner of each app records that behavior matches Fly for a defined observation window.
Cut over with lowered DNS and a rollback path
Lower the DNS TTL for each production domain ahead of the change window and confirm the lower TTL has propagated. Freeze writes, run a final data sync, switch the records to Coolify and verify the application. Keep Fly Machines stopped rather than deleted so that the rollback path stays available. Done means a signed-off cutover checklist names the approver, records the switch time, confirms health checks and lists the exact steps to revert DNS if needed.
Decommission Fly resources after verification
After the agreed observation period passes without a rollback, take final snapshots of any remaining Fly volumes and database backups, then stop and remove Machines, volumes, certificates and IP addresses. Confirm that billing for each removed resource has stopped on the next invoice. Revoke Fly API tokens and remove stored secrets from CI systems. Done means a decommission record lists each deleted resource, the snapshot location and the date the owner approved removal.

What drives the cost and duration of the move

This table breaks the migration into cost components, shows who is paid for each, and names the drivers that push effort up or down. Use it to structure a written scope and to compare quotes on the same basis, since no duration or price is stated here.

Cost component	What it covers	One-time or recurring	What drives it
Translation of fly.toml	Converting build, services, processes, checks, release commands and mounts into Coolify application settings	One-time	Number of apps, number of process types per app, and how many custom health checks and release commands must be reproduced
Build path	Confirming the Dockerfile or buildpack builder still produces the same image, or moving to a Git build pack	One-time	Whether apps already have a tested Dockerfile, and whether any build depends on Fly.io-specific tooling
Data migration	Moving volume contents and Postgres data, then validating restores	One-time	Total volume and Postgres size, the change window allowed, and whether logical replication or a dump and restore is used
Testing and cutover	Staging runs, DNS and TLS switch, and rollback planning	One-time	Number of domains, preview environment needs, and how much downtime the business accepts
Multi-region placement	Replacing Fly.io regional Machines with servers Coolify manages, or accepting a single location	One-time design, then recurring	Regions in use today against the multi-server model Coolify provides, and the latency or residency rules that apply
Servers	Hosts that run Coolify and applications, sized to the workload	Recurring	Sizing input: Coolify needs at least 2 CPU cores, 2 GB RAM and 10 GB free disk per server, and more for real workloads
Backup storage	Scheduled database dumps and retained files in S3-compatible storage	Recurring	Database size, backup frequency, and retention by count, days or size
Operating time	Patching, monitoring, certificate checks, restores tests and on-call response	Recurring	Team size, how many servers and databases are owned, and whether a support retainer covers upgrades
Compliance evidence	Access records, backup restore tests, change logs and configuration evidence for assessors	One-time setup, then recurring	Regulatory scope and how much evidence the auditor expects from the self-hosted layer

How the move differs by starting point

A single app with one process group and a small Postgres database is the simplest case. Coolify can connect one server over SSH, build the app from its Dockerfile or a supported Git build pack, and deploy it with a database in the same project. The work is mostly translating the [http_service] section of fly.toml into a domain, health check and port in Coolify, then moving data.

Build path: Reuse the existing Dockerfile where possible. Coolify's Dockerfile build pack or Nixpacks can replace the Fly builder, but confirm the image builds the same way on the target server.
Postgres version: Check the version your Fly database runs. Supported PostgreSQL major versions are 14 through 18, so a 13 or older database needs an upgrade before or during the move.
Major version choice: For a new deployment, PostgreSQL 18 is the newest supported release. Logical replication or a dump and restore lets you move to it from an older major version with a short cutover.
Backups: Enable Coolify's scheduled PostgreSQL backups to S3-compatible storage and test a restore before cutover.
Cutover: Plan a short write freeze, a final dump, and a DNS change with a TTL you have lowered in advance.

Before cutover, confirm the current Postgres version on Fly, the database size, and whether any dependency on Fly-specific private networking or secrets needs replacing.

An estate with several apps, shared volumes and background workers needs an inventory first. Each Fly app usually maps to a Coolify application, but workers, cron-style jobs and shared storage behave differently on a self-managed server, and each one needs an explicit owner and location.

Process groups: Fly's [processes] entries become separate Coolify applications or Docker Compose services, each with its own start command and resource limits.
Volumes: Fly volumes are attached to a single Machine in a region. On Coolify, persistent files live in Docker volumes on one server, so back them up and confirm how each app reads them.
Release commands: Fly's release commands need a deploy step or pre-deploy hook that runs migrations once. Test that behavior on a staging server first.
Server layout: Decide which apps share a server. Coolify's multi-server deployments add capacity, but placing apps on a fixed set of servers is your decision, not automatic.
Recurring cost: Server, backup storage and operating time become fixed or recurring costs, while Fly charges by Machine, volume and egress usage.

Ask the team for a list of every app, volume, scheduled job and secret before estimating the work, and confirm which apps can tolerate a short outage during cutover.

What usually goes wrong and how to prevent it

Moving from Fly.io to Coolify shifts backups, routing, TLS and on-call duties from the platform to your team. The failures below tend to appear after cutover rather than during the build, so each card pairs the risk with a check to run before and after the switch.

Backups that were never restored

Coolify schedules PostgreSQL backups to S3-compatible storage, but a backup that has never been restored proves nothing. Before cutover, restore a recent dump into a scratch Coolify database and start the application against it. Record how long the restore took and which steps were manual. Repeat the test on a schedule, because a restore runbook written once tends to drift from the live setup.

Rollback does not restore data

Coolify's guide for teams coming from managed platforms notes that a rollback can redeploy a retained application image but does not restore databases or persistent files. Fly.io users often assume a release rollback also reverts data. Write down which state lives in volumes, database rows and external storage, and define a separate recovery path for each. Test that path before the first production release on Coolify.

Redis and KeyDB outside scheduled backups

Coolify's scheduled backups cover PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse, but not Redis, Dragonfly or KeyDB. If an app on Fly.io uses Redis as a store of record, for example for queues or sessions with data you cannot rebuild, the migration needs its own export and storage job. Confirm which Redis data is cache and which is durable, and back up the durable part outside the scheduled feature.

Preview deployments without wildcard DNS

Coolify builds pull or merge requests at a default {{pr_id}}.{{domain}} URL, and that address only resolves when wildcard DNS points at the server. Teams that relied on Fly.io preview apps may find previews silently unreachable after the move. Create the wildcard record during setup, confirm it resolves from outside your network, and check that Coolify deletes previews when requests close or merge so stale environments do not accumulate.

Latency changes after leaving regional placement

Fly.io Machines can run in many regions close to users, while a Coolify setup places each application on the servers you connect over SSH. Users far from the chosen server may see slower responses than before, and the change is easy to miss in internal testing. Measure response times from the regions your users occupy, both before and after cutover, and decide in writing whether a second server or a CDN is needed for the affected routes.

TLS unmanaged under the Custom proxy

Coolify runs one coolify-proxy container per server, with Traefik as the default and Caddy as the alternative. Both handle HTTPS automatically. The Custom (None) option leaves routing and TLS certificates to your team, so certificate renewal can fail without any alert. If you choose Custom, assign an owner for renewals, set expiry monitoring on every domain, and test a renewal before the first production certificate expires.

No on-call coverage after cutover

On Fly.io, the provider operates the underlying machines and networking. After migration, your team owns server patching, disk capacity, proxy health, backup jobs and database failures. Name a primary and secondary responder for each server and application, define alerts for failed backups and full disks, and write an escalation path. Decide before cutover who responds at night and at weekends, and confirm that person can reach the servers.

Questions teams ask before moving from Fly.io to Coolify

How much effort does moving from Fly.io to Coolify take?

The effort depends mostly on how many apps you run, how many of them use volumes or Postgres, and how many regions they span today. A stateless web app with a Dockerfile and no volumes is the simplest case. Each app needs its fly.toml translated into Coolify settings for build, ports, health checks, environment variables and persistent storage. Stateful workloads add work because volume data and database backups must be moved and verified. Ask any partner to price the work from a written inventory of apps, databases, domains and regions, since that list sets the scope.

What drives the cost of a Fly.io to Coolify migration?

Two cost types apply. The Coolify software is licensed under Apache-2.0, and its self-hosted edition is free with all features, so the recurring cost is the servers you run and the people who operate them. Coolify Cloud is an alternative that charges $5 per month for 2 connected servers plus $3 per month for each additional server, with a 20% discount for annual billing, according to Coolify's pricing page. Migration labor is one-time. Recurring costs include servers, storage, off-site backup storage and the time spent on updates and monitoring. Compare those against your current Fly.io bill, which is metered by Machine, volume and egress.

How long does the move take and what sets the timeline?

The timeline is set by the number of stateful services, the cutover tolerance for each app and the time needed to prove backups restore. Stateless apps can usually be moved in parallel, with DNS changed once health checks pass on the new servers. Databases take longer because you must confirm a restore, plan a write freeze or replication window, and rehearse the cutover. Fixed-scope engagements agree deliverables and timelines in writing before work starts, so ask for a dated plan based on your inventory rather than a generic estimate.

What does the work require from our own team?

Your team needs to own the decisions that only you can make: which domains move, which secrets are rotated, who approves cutover, and what the acceptable downtime is. On the technical side, someone must provision Linux servers that meet Coolify's minimum of 2 CPU cores, 2 GB RAM and 10 GB of free disk, and must manage SSH access, firewall rules and DNS. Application owners must confirm which environment variables, health endpoints and background processes each app needs. Ask the partner which of these tasks are included in scope and which remain with your staff.

Can our team migrate the apps ourselves?

Yes, for simple apps, a small team with Docker and Linux experience can translate fly.toml into Coolify resources and deploy from a Git repository, Dockerfile or prebuilt image. The gap usually appears in data work, proxy and TLS setup, and operational runbooks. Coolify's guide for teams coming from managed platforms notes that a rollback can redeploy an application image but does not restore databases or persistent files, so you must plan backup and recovery yourselves. If your apps are business critical or hold regulated data, consider a fixed-scope engagement for the cutover and handover.

Does Coolify replace Fly.io's multi-region placement?

No, Coolify does not place Machines in regions automatically. Coolify connects to each server over SSH and deploys applications onto servers you have connected, and its multi-server deployment model is a different mechanism from Fly.io's regional Machines. If you need an app close to users in several places, you must provision servers in each location, decide how traffic is routed between them, and manage data replication yourselves. Confirm the exact multi-server behavior and any routing or failover you need against Coolify's multi-server documentation before committing to a design.

How does Postgres data move, and what backup coverage does Coolify provide?

Postgres data moves with a logical dump and restore, or with a replication window if downtime must stay short. Coolify's scheduled PostgreSQL backups use the pg_dump custom format, can be uploaded to S3-compatible storage, run on cron schedules and apply retention by count, days or size. Its Import Backup accepts SQL dumps, custom archives, tar archives and all-database dumps. Coolify's scheduled backups do not cover Redis, Dragonfly or KeyDB, so any cache or queue data needs a separate plan. Test a restore on a separate server before cutover, and plan point-in-time recovery separately if you need it.

Should we choose Coolify Cloud or self-host Coolify?

Choose self-hosting when you need full control of the Coolify instance, its data and its network location, and your team can operate it. Choose Coolify Cloud when you want the control plane run for you while your servers stay in your own infrastructure. Coolify Cloud is priced at $5 per month for 2 connected servers plus $3 per month for each additional server, with a 20% discount for annual billing, according to Coolify's pricing page. Self-hosting removes that fee but adds the operating time for upgrades, backups of the Coolify instance and access control. Check where your compliance requirements allow the control plane to run before deciding.

How DeployOpen scopes and runs the migration

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, including your cloud accounts, data centers or air-gapped networks. For a move from Fly.io to Coolify, that means the Coolify instance, the servers it manages over SSH, the proxy layer, the database backup path and the deployment pipeline all run in environments you control. The work starts with an inventory of each Fly.io app's fly.toml, its Dockerfile or buildpack builder, its volumes, its Postgres clusters and the regions where its Machines run, so the scope reflects what actually exists rather than what the app list suggests.

Most engagements are fixed-scope. Before work starts, scope, deliverables and timelines are agreed in writing, and that document is the basis for a quote. The decisions that most affect the scope are usually the ones you must make first: which apps move in the first phase, whether any app still needs multi-region placement (which Coolify's multi-server model does not replicate in the same way), how Postgres data will be backed up and tested for restore, and who owns the rollback runbook after cutover. Ask for the quote to list each of these as a separate line item, along with the cutover and parallel-run window you expect. Ongoing support, upgrades and continuous testing are available as a retainer, which suits teams that want someone to keep the Coolify host patched and its backups verified after the migration project closes. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work.

Migrate from Fly.io to Coolify