When does Coolify on your own servers cost less than Fly.io?
If your Fly.io bill is hard to forecast and you are weighing self-hosting, start with this: Coolify's software is free under Apache-2.0, and its self-hosted edition is free with all features, so the comparison is the cost of servers you run plus the operating time self-hosting adds, set against Fly.io's metered charges. There is no universal price gap. The answer depends on fleet size, how much capacity must stay on around the clock, how much data you store and move, how much egress you pay for, and how many staff hours the platform consumes each month. Coolify itself needs at least 2 CPU cores, 2 GB RAM and 10 GB of free disk on each server it manages, so the smallest machine that meets those minimums is the floor for your fixed cost, not the ceiling.
Run the comparison on your own workload. List every Fly.io Machine that runs continuously, every volume and snapshot, your monthly egress, and the IPv4 addresses and certificates you pay for, then ask Fly.io's current pricing page for the rate on each line. On the Coolify side, price the servers that would host the same processes with headroom for deploys and restarts, and add the bandwidth and backup storage they need. Separate what is one-time from what recurs: installation and migration effort is paid once, while server rent, backup storage, patching and on-call time recur. Ask your provider for the exact instance sizes and transfer allowances, and confirm them against your own metrics before you commit. Self-hosting tends to favor steady, predictable workloads with modest burst needs and a team that already runs Linux servers. It tends to favor Fly.io when you depend on fast scaling across regions, when a small team cannot absorb the on-call work of databases and server patching, or when the operating time would cost more than the metered charges you avoid. Treat the operating time as a real cost line: budget the hours for upgrades, backups, restore tests and security updates, and decide who owns them before the first cutover.
Which cost components move between Fly.io and self-hosted Coolify?
This table maps each Fly.io charge to its self-hosted equivalent under Coolify and marks whether the cost is one-time or recurring. Coolify itself is free under Apache-2.0, so the real spend sits in servers, storage, backups and the staff time that operates them. Confirm every Fly.io unit price on Fly.io's current pricing page before comparing, since no rates are supplied here.
| Cost component | Fly.io charge | Self-hosted under Coolify | One-time or recurring |
|---|---|---|---|
| Compute | Machines billed by size and running time | Servers you rent or own, sized for the apps and their builds | Recurring |
| Volumes | Persistent volume storage billed per gigabyte | Server disk or block storage, sized for databases and uploads | Recurring |
| Snapshots | Volume snapshot charges | Scheduled backups from Coolify to S3-compatible storage you choose | Recurring |
| Egress | Outbound bandwidth charges | Included transfer from your server provider, check its overage terms | Recurring |
| Dedicated IPv4 | Per-address charge for a dedicated IPv4 | Usually included with the server, confirm with the provider | Recurring |
| Certificates | Free TLS certificates through Fly.io | Traefik or Caddy issues certificates automatically, with no license cost | Recurring effort only |
| Support plans | Optional paid support tiers | Coolify's self-hosted edition has no license fee; any retainer is a separate written scope | Recurring if chosen |
| Coolify license | Not applicable | Zero: Coolify is Apache-2.0 and its self-hosted edition is free | None |
| Backup storage | Included in volume snapshots and billed separately | Object storage fees and retention policy you set | Recurring |
| Engineering and upgrades | Largely absorbed by Fly.io operations | Staff time for setup, patching, monitoring, restores and Coolify upgrades | Recurring, the largest driver |
What pushes the Fly.io bill up or down
Fly.io meters Machines, storage and transfer as they are used, while self-hosted Coolify costs the servers, storage and staff time you commit to each month. Six drivers move one side or the other, and each needs a check against your own usage data before you compare totals.
Always-on Machines and regions
Fly.io bills each Machine by usage, so every always-on Machine and every additional region adds recurring charges that grow with placement. On Coolify, the cost is the servers you rent, so extra apps share existing capacity until CPU or memory runs short. Count the processes that must run around the clock and whether each needs a second region. Check the host sizing against the Coolify minimum of 2 CPU cores and 2 GB RAM, which covers the platform itself, not your workloads.
Volume and snapshot count
Fly.io volumes and snapshots are metered storage that accumulates as apps, environments and retention windows multiply. On Coolify, persistent data sits on the server disk and in the S3-compatible bucket that receives your scheduled backups, so storage cost moves to the host and the bucket provider. Coolify's PostgreSQL backups run on cron schedules with retention by count, days or size, so retention settings set the bill. Confirm the disk size your databases need and the bucket price with each provider.
Outbound data transfer
Egress is the charge teams most often underestimate on usage billing, because it follows user traffic, file downloads and API responses rather than app count. On a self-hosted server, outbound transfer is usually covered by the host's bandwidth allowance, which has its own terms and overage rules. Measure monthly outbound volume from your current invoice and compare it with the transfer allowance on the server plan. Get any overage rates in writing before you move traffic.
Apps and environments
Each app, staging environment and branch preview adds to the count of workloads that Fly.io bills. Coolify has no per-app fee, so the count matters only for the CPU, memory and disk the containers consume on the host. Preview deployments build from pull or merge requests at a default {{pr_id}}.{{domain}} address, need wildcard DNS, and are deleted when the request closes or merges. Decide which environments stay permanent and which should be short-lived to keep host load predictable.
Multi-server failover
Availability often doubles the bill, because a second server is a fixed cost whether or not it takes traffic. Coolify Cloud charges a fee for each server beyond the first two, while the self-hosted edition carries no license cost. Coolify's multi-server documentation describes deploying across servers, but failover is not automatic for every component. Confirm how traffic is balanced, how databases recover after a node failure, and how certificates renew on each node for your topology.
Team Linux and Docker skills
Staff time is the cost that self-hosting adds, and it recurs for patching, monitoring, backups and incident response. Coolify installs with a single script on supported Linux distributions, but your team owns OS updates, Docker upkeep and recovery testing. Coolify's migration guide notes that a rollback can redeploy a retained application image but does not restore databases or persistent files, so restore tests belong in your plan. Estimate the monthly hours with your own on-call rota before comparing totals.
How to build the Fly.io versus Coolify model with your own numbers
This sequence turns your current Fly.io bill and footprint into a like-for-like cost model for self-hosted Coolify over a period you choose, so the comparison rests on your workloads rather than on list prices.
Export three months of Fly.io billing
Finance or the account owner downloads the billing history from the Fly.io dashboard and splits it by line item: Machine compute, volumes, snapshots, egress, dedicated IPv4 addresses, certificates and any support plan. Keep three months so that usage spikes and seasonal peaks show up. The step is done when every charge on the bill maps to a named line item and the monthly totals reconcile with invoices.
Inventory Machines, volumes and regions
An engineer lists every app, its Machines, their sizes and counts, the regions they run in, attached volumes with their sizes, snapshot retention and the IPv4 addresses allocated. Record which Machines are always on and which scale to zero, because that changes both the bill and the server load. The output is a single inventory sheet with one row per app and per resource, checked against the Fly.io dashboard and the output of your own CLI queries.
Measure actual resource use per workload
Pull CPU, memory, disk and network figures for each app over the same three-month window from your monitoring or Fly.io metrics. Identify peak load and the memory each process needs. Coolify's installation docs give minimum requirements of at least 2 CPU cores, 2 GB RAM and 10 GB of free disk for the Coolify host itself, so these figures are separate from app workloads. The check is a table of peak and typical usage per app that you can defend in a review.
Size target servers with headroom
Using the usage table, an engineer sizes the servers that will run the apps on Coolify, adding headroom for deployments, build jobs, database growth and failover needs. Coolify manages servers over SSH and runs its own proxy and build processes on each host, so budget for those overheads. Confirm that the chosen Linux distributions and amd64 or arm64 architectures are on Coolify's supported list. The output is a server plan with CPU, memory, disk and count per server.
Price servers and backup storage from your provider
Procurement collects quotes from your cloud or hosting provider for the server plan, plus block storage, network transfer allowances, and S3-compatible object storage for PostgreSQL dumps that Coolify can upload on cron schedules. Ask whether backup storage is billed per gigabyte, per request or as a flat allowance, and how retention settings change the stored volume. Coolify software itself is free for self-hosted use, so the recurring costs sit with infrastructure. The step closes with an infrastructure line for each month.
Estimate operating hours for the platform
Engineering estimates hours for initial installation, Coolify upgrades, security patching of the host, backup restore tests and incident response, and records who carries each task. Coolify's own release history shows that the v4 line has moved through several versions, so plan for upgrade work. Treat these hours as an internal estimate built from your team's rates, not a figure from Coolify or DeployOpen. The output is a monthly labor table with a named owner for each activity.
Compare totals over a stated period
Finance places the Fly.io totals and the self-hosted totals side by side over the same period, separating one-time costs such as migration work and initial setup from recurring costs such as compute, storage, transfer and labor. Add a sensitivity line for growth in each driver, such as Machine count or stored data. Label the result as an illustrative model until your own quotes and hour estimates are final. The step is complete when the decision owner can see which assumptions move the answer most.
What stops being billed and what starts
The first change is that Fly.io's metered charges stop, and the bill that replaces them is mostly fixed. On Fly.io, the charges that move with activity are Machine time, volume storage, snapshots, egress, dedicated IPv4 addresses, certificates and any support plan. Coolify itself costs nothing under its Apache-2.0 license, so the new spend is the servers that run it, the bandwidth those servers draw from their provider, off-server backup storage, and the operator time to keep everything running. Server prices are usually set per month and change in steps when you add capacity, so a traffic spike does not automatically raise the invoice. Confirm the bandwidth allowance and overage rules with each hosting provider before you size the fleet, because egress is the line item most likely to remain variable. Ask Coolify's own pricing page for the current self-hosted terms, since the Coolify Cloud subscription is a separate option you may or may not choose.
The second change is labor, and it is where teams most often underestimate cost. Someone must patch the host operating system, renew and monitor TLS through the coolify-proxy container, watch disk space, and upgrade Coolify across releases. Backups are the largest of these tasks. 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. That means the database dumps you schedule, the S3-compatible storage you pay for, and the restore tests you run are recurring costs that Fly.io volumes and snapshots previously covered in part. Decide the retention policy, the restore target and who performs a restore before go-live, and ask any implementation partner to price those steps as separate line items in the written scope.
How server sizing changes the comparison
A small team with a handful of apps and one database usually pays for Fly.io mostly through Machine runtime, then volumes for the database and any persistent files. Self-hosting on Coolify replaces those usage lines with the fixed cost of one or more servers you rent or own, plus your own time to patch the host, watch disk and keep backups running. Coolify is free to self-host under Apache-2.0, so the recurring cost is infrastructure and operator time. Coolify needs at least 2 CPU cores, 2 GB RAM and 10 GB of free disk, so the smallest viable host is set by those minimums, not by a server size recommendation from DeployOpen.
- Machine runtime: Fly.io bills running time per Machine, so idle apps still cost money unless you stop them.
- Volumes and backups: Database volumes on Fly.io are one line; on Coolify, scheduled PostgreSQL backups to S3-compatible storage are a separate storage cost you control.
- Operator time: A single host means one place to patch and one place to restore from, which is manageable but still recurring work.
- Database coverage: Coolify's scheduled backups cover PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse, but not Redis, Dragonfly or KeyDB, so confirm how cache data is handled.
- Egress: Confirm your outbound traffic on the host provider's terms, since Fly.io egress is a separate usage charge.
Confirm the current Fly.io bill line by line and ask your host provider for the monthly price of a server that meets the Coolify minimums.
A team running staging and production alongside preview deployments for every pull request sees costs move from Machine count to environment count. On Fly.io, each extra environment or preview app adds Machine runtime, volumes and often IPv4 addresses and certificates. On Coolify, previews run on the same servers as your other apps, so the cost driver becomes CPU, memory and disk headroom on the existing hosts. Preview deployments are built from GitHub, GitLab, Gitea or Bitbucket pull or merge requests and are deleted when the request closes or merges, which limits how long they consume resources.
- Shared host capacity: Several environments on one host compete for the same CPU, memory and disk, so size headroom for peak builds.
- Preview DNS: The default preview URL is {{pr_id}}.{{domain}}, which requires wildcard DNS; confirm your DNS provider and certificate handling before relying on previews.
- Build load: Builds run on the server, so frequent pull request builds can slow production apps unless you separate environments.
- Cleanup: Preview deletion on close or merge keeps resource use bounded, but confirm that abandoned branches are closed in your Git host.
- Credential scope: Separate environments may need separate server access and API tokens, which adds administration time.
Confirm the preview URL pattern, wildcard DNS and the build capacity your host needs before you move any preview workflow.
A team that needs apps spread across several servers or regions faces the largest change from Fly.io. Fly.io places Machines across its regions and bills by usage, so multi-region placement is a configuration choice. Coolify manages multiple servers over SSH, and its multi-server deployment documentation sets the scope of what it does and does not place automatically. Each added server adds a fixed host cost, plus the time to keep every server patched, monitored and backed up. Regional spread also changes who handles failover, since Coolify does not replace the high availability design you would build yourself.
- Server count: Each additional server is a recurring host cost on top of the base setup, so the cost grows in steps.
- Placement limits: Confirm which Coolify multi-server features cover your placement, scheduling and failover needs before assuming parity with Fly.io regions.
- Load balancing and TLS: Traefik or Caddy handles HTTPS per server, so confirm how traffic is routed across hosts and how certificates are issued.
- Database topology: A database on one host is a single point of failure; replication and failover are operator work to design and test.
- Data locality: Choosing your own regions gives control, but you must verify each provider's location and compliance terms.
Confirm the Coolify multi-server limits in the current documentation and get a written plan for failover before committing to a regional layout.
Questions buyers ask before comparing costs
Is Coolify free to self-host, and what does it cost to run?
Yes. The self-hosted edition of 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. What you pay for is the infrastructure underneath it: the servers Coolify manages, their storage, bandwidth, backups and any managed database or object storage you choose to use. Coolify Cloud is a separate paid option. It costs $5 per month for 2 connected servers plus $3 per month for each additional server, with a 20% discount for annual billing, and it runs the Coolify instance on Coolify's infrastructure while you bring your own servers. Confirm current plan terms on the pricing page before you model costs.
How much staff time does self-hosting add, and what drives it?
The main cost is operating time, not software fees. Someone must patch the host operating system, keep Docker and Coolify updated, watch disk and memory, manage DNS and certificates, and respond when a deployment fails. Coolify requires at least 2 CPU cores, 2 GB RAM and 10 GB of free disk on a supported Linux distribution, and it installs with a single script. The hours depend on how many servers and applications you run, how often you deploy, how many stateful services you host, and whether you already run Linux operations. Ask your team to estimate these drivers in its own environment, because no supplied figure gives a reliable number of hours.
Can our team do the work itself, or do we need outside help?
A team with Linux, Docker and DNS experience can usually run a single Coolify server with its own staff, provided someone owns patching and on-call response. Outside help is most useful for the parts that are easy to get wrong the first time: translating Fly.io configuration, moving volumes and database data, setting up backups and restore tests, and writing the runbook that the team will follow later. DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted platforms in your own infrastructure, typically under a fixed-scope agreement or an ongoing retainer. Decide which parts your team keeps before you ask for a quote.
How long does a migration take, and what sets the duration?
No supplied figure gives a reliable migration duration, so treat any number from a vendor or consultant as unverified until it is scoped. The duration is set by the number of applications and environments, how much Fly.io configuration must be translated, the volume of data to move, whether multi-region placement must be replaced with a different design, how many preview or staging workflows exist, and how much testing and cutover planning your organization requires. Ask for a written plan that lists each application, its builder, its stateful services and the acceptance test for each cutover step.
What do backups and restores require when we leave Fly.io?
On Fly.io, the platform helps with volumes and snapshots, but on Coolify the backup and recovery responsibility moves to you. Coolify's scheduled backups cover PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse, using cron schedules, retention rules and optional upload to S3-compatible storage. PostgreSQL backups use the pg_dump custom format. 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. Plan separate backups for persistent files, and test restores on a schedule. Restore procedures are documented by Coolify, but confirm that your database and file layout fits them.
Does Coolify cover every database that Fly.io users run?
Not necessarily. Coolify deploys PostgreSQL, MySQL, MariaDB, MongoDB, Redis, Dragonfly, KeyDB and ClickHouse, so PostgreSQL and Redis-compatible services are covered for deployment. Scheduled backups, however, cover PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse, but not Redis, Dragonfly or KeyDB. If your Fly.io apps use other databases, Redis data that must persist, or managed features such as failover, check each one against the Coolify documentation and your own recovery requirements. Where Coolify does not fit, you may need a separate database service on your own infrastructure.
What should we ask for in a fixed-scope quote?
Ask for a written scope that names each deliverable, the environments in scope and the exact systems covered. Request the translation plan for each Fly.io application, the server design with capacity, the network and TLS approach, the backup schedule and restore test method, the cutover and rollback steps, the handover documentation and the support period after go-live. Also ask what is excluded, such as application code changes, new features, or ongoing upgrades, and whether those are available as a retainer. DeployOpen does not publish a price list, and a quote follows from the written scope.
How DeployOpen scopes the cost of a self-hosted move
DeployOpen plans, implements, backs up, upgrades and documents Coolify inside your own infrastructure, whether that is your cloud accounts, your data center or an air-gapped network. For a move off Fly.io, the scope turns on which of your Machines, volumes, Postgres databases and certificates come across, which servers Coolify will manage over SSH, and who owns the proxy, TLS and backup decisions after handover. Those choices change the cost more than the Coolify license does, because the license is free for the self-hosted edition. Before any quote, confirm with your own team how many apps and databases are in scope, which regions and traffic patterns they run today, and whether you need Coolify's multi-server deployments or a single host.
Most DeployOpen engagements are fixed-scope. The scope, deliverables and timelines are agreed in writing before work starts, so the cost of each component (server capacity, migration of volumes and database data, backup configuration, restore testing, and documentation) is visible up front. Ask for each of these to be listed separately in the written scope, along with which items recur. Server and storage charges from your own cloud or data center recur and are paid to that provider, not to DeployOpen. Ongoing support, upgrades and continuous testing are offered as retainers and are a separate decision from the one-time migration.
DeployOpen does not publish a price list. A quote follows from the written scope, so the useful preparation is an inventory of what runs on Fly.io today and what must keep running after cutover. Ask for the quote to state its assumptions, including which tasks are your team's responsibility, which need your cloud or network access, and how restore testing is verified. Ask how the scope will be validated before cutover, and what you will receive as documentation. DeployOpen prepares systems and evidence for compliance assessments, but it does not issue audit reports or certifications. If your readiness work supports an assessment, confirm with the independent auditor what evidence they will expect.
How DeployOpen scopes a fixed-price Coolify implementation
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure. For a move from Fly.io to Coolify, we start from a written scope that separates the Coolify setup from the application, data and operating work that your team still owns.
How we scope
- Inventory every Fly.io app, Machine, volume, certificate and Postgres database you currently pay for each month.
- Agree which target servers, cloud accounts or data centers will host Coolify and the migrated workloads.
- Write down which regions, backups, TLS responsibilities and monitoring tasks move to your operators and which stay with you.
How we build
- Install Coolify on Linux servers you control, checking the documented minimum of 2 CPU cores, 2 GB RAM and 10 GB free disk.
- Configure the reverse proxy choice, Traefik or Caddy, and test HTTPS and domain routing before cutover.
- Set up database backups to S3-compatible storage and run a restore test before any production data moves.
How we hand over
- Document each application's build pack, environment variables, domains, scheduled backups and rollback steps in a runbook.
- Walk your platform and security staff through deployments, restores and preview deployment cleanup.
- Deliver written test results and configuration records so your auditors or internal reviewers can check the setup.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped separately in writing.
- Plan Coolify upgrades and server patching with your change windows, since you own the servers after handover.
- Ask for a quote built from the written scope, with server, storage and labor components itemized for your environment.
