When self-hosted Coolify or Coolify Cloud fits your team
Choose self-hosted Coolify if your team wants to run the dashboard itself and keep the control plane inside your own infrastructure; choose Coolify Cloud if nobody on your team should carry the job of keeping the dashboard running. In both models, your application servers stay on your own infrastructure, because Coolify connects to each one over SSH and deploys onto it. The decision is only about where the Coolify instance that manages those servers lives and who patches and backs it up. Self-hosting fits teams with data residency or internal control requirements that extend to the deployment tooling, and teams that already run Linux, Docker and reverse proxies well enough to operate one more service. The self-hosted edition is free, so the cost of that choice is staff time and the availability you engineer for the dashboard host, not a subscription.
Coolify Cloud fits teams with a small number of servers and no spare operator to own the dashboard. Its pricing page lists $5 per month for 2 connected servers plus $3 per month for each additional server, with a 20% discount for annual billing, and the Coolify instance runs on Coolify's managed infrastructure while you bring the servers. Before you commit, confirm with Coolify which data the hosted instance stores, where backups of the control plane go, how upgrades are scheduled, and what happens to your connection to each server during an outage of the hosted dashboard. Ask the same questions of your own team if you self-host, including who holds the SSH keys Coolify uses and how the instance is restored if its host fails.
Run a short test before you decide: count your servers, list the people who would take the pager for the dashboard, and write down the recovery steps for a lost dashboard host. If the list is short and nobody can name an owner, Coolify Cloud is the simpler start. If you already have an owner, a documented backup of the Coolify instance, and a reason to keep control in-house, self-hosting is the better fit. Teams that expect to add servers over time should model the per-server fee against the staff time of running the instance, and revisit the choice as the server count changes.
How the two models compare on cost, control and features
This table sets Coolify Cloud against a self-hosted Coolify dashboard on the factors that change between them: price, where the control plane runs, who upgrades it, and what you must back up and support yourself. Read the rows as the checklist to take into a vendor conversation, since your application servers stay on your own infrastructure in both models.
| Factor | Coolify Cloud | Self-hosted Coolify |
|---|---|---|
| License and price | Paid per month: $5 for 2 connected servers plus $3 for each additional server, with a 20% discount for annual billing (Coolify pricing page) | Free. The pricing page describes the self-hosted edition as free forever with all features and no limitations, and the code is Apache-2.0 |
| Where the dashboard runs | On Coolify's managed infrastructure. Your servers still run your workloads | On a host you choose and manage, such as a VM in your own cloud account or data center |
| Who applies upgrades | Coolify's side maintains the instance. Confirm the upgrade schedule, rollback path and maintenance windows with the vendor | You do. Current release is v4.4.6 (October 9, 2026); v4.0.0 was the first stable release on April 27, 2026. Plan your own update and test process |
| Backups of the Coolify instance | Confirm with the vendor whether the control plane database and configuration are backed up, how often, and how you would restore them | Your responsibility. Back up the Coolify configuration and its database as part of your host backup plan, and test restores |
| Availability of the control plane | Depends on Coolify's managed service. Ask for its stated availability target and what happens to deployments if the dashboard is unreachable | Depends on your host. A single dashboard host is a single point of failure unless you design for it. Your deployed apps keep running on their servers if the dashboard is down, so confirm this in your own tests |
| Support | Vendor-provided support tied to the paid plan. Ask which channels and response targets are included | Community and documentation, plus any support arrangement you contract separately, such as a DeployOpen retainer |
| Feature parity | Confirm with the vendor whether every feature in the self-hosted edition is available in Cloud, including SSO, team roles, API access and preview deployments | All features in the self-hosted edition are listed as included with no limitations on the pricing page |
| Cost as servers grow | Each additional server adds $3 per month on top of the base fee, so cost rises in a straight line with server count | No per-server fee from Coolify. Your costs are the hosts, storage, backups and the staff time to run the dashboard |
What data and access stay with you in each model
Both models run your applications on your own servers, so the questions that differ are where the Coolify instance and its configuration live, who can administer it, and what evidence each model gives an auditor. The cards below separate those layers so you can check each one against your own data handling and compliance requirements.
Application workloads stay on your servers
In both models Coolify connects to your servers over SSH and deploys containers there, so application containers, their volumes and their database data run on hardware you provision. Coolify Cloud changes where the dashboard runs, not where your workloads run. Check which network paths the managed instance needs to reach your servers, and confirm that your firewall rules, SSH key handling and server locations match your policy.
Where the instance and its configuration live
Self-hosted Coolify keeps its database of projects, environment variables, server records and deployment history on a host you run, so backup and restore of that host is your responsibility. Coolify Cloud keeps that control plane on Coolify's managed infrastructure. Ask Coolify where that data is stored, which regions are used, how it is encrypted at rest, and what happens to it if you cancel.
Administrative access and API tokens
Whoever holds the administrator account on a self-hosted instance controls every server it manages, and API tokens grant the same reach. With Coolify Cloud, a Coolify-side staff path to your instance exists and must be described in writing. Inventory who has root on the instance host, who holds admin roles in the dashboard, and how API tokens are issued, scoped and revoked in each model.
Upgrade and patch responsibility
A self-hosted instance is patched on your schedule, which gives you control of change windows but makes you responsible for staying on a supported release. Coolify Cloud moves that patching to the vendor. Confirm which Coolify release line the managed service runs, how it notifies you of maintenance, and how you can test a change before it reaches production on your servers.
Compliance evidence in each model
DeployOpen prepares controls, configuration records and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that. Ask Coolify directly which reports, certifications and data processing terms it can provide for its managed service, and confirm the data handling terms in writing before you rely on them. For self-hosted Coolify, the evidence is what your own team records about the host and its configuration.
What moves to Coolify's side when you pay for the cloud
When you pay for Coolify Cloud, the Coolify dashboard and its instance move to Coolify's managed infrastructure, while your applications, databases and Docker hosts stay on the servers you connect. The pricing page lists the fee as $5 per month for 2 connected servers plus $3 per month for each additional server, with a 20% discount for annual billing. Those are the only recurring Coolify charges you should expect for the control plane, but confirm with Coolify whether the fee covers anything beyond the instance itself, such as backup storage or support response. The tasks that transfer are the ones tied to running the dashboard: hosting the instance, applying Coolify updates to it, and keeping the control plane reachable. In self-hosted Coolify, you own those tasks. If the instance on your own host goes down, you cannot deploy, redeploy or change configuration until you restore it, although workloads already running on your servers keep running. Ask Coolify what availability target applies to the managed instance and whether it is written into a contract, because the pricing page does not state one.
The tasks that stay with you are the ones on the servers Coolify connects to over SSH. Coolify prepares each server to run Docker workloads, but you still patch the operating system, manage Docker hosts, size disks and decide how application data is stored. Database backups are the part most likely to be misread: Coolify's scheduled backups for PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse run against databases on your servers, and they can be sent to S3-compatible storage. Before relying on Coolify Cloud, check that the backup destination, retention settings and restore steps are under your control, and test a restore on a second server. Also confirm that Redis, Dragonfly and KeyDB, which are not covered by scheduled backups, have a separate plan. The decision to make is whether losing dashboard control for a period is acceptable, and whether the SSH access Coolify holds to each server fits your access policy. Review which keys and users Coolify uses, where those credentials are stored, and who can reach the dashboard. Costs grow with server count: each server beyond the first two adds $3 per month on the cloud plan, so a fleet of many small hosts changes the comparison more than a few large ones.
What your team runs in each model
In the self-hosted model, your team installs the Coolify dashboard on a Linux host of its own. Coolify's installation docs state a minimum of 2 CPU cores, 2 GB RAM and 10 GB of free disk, and the host must run a supported Linux distribution on amd64 or arm64. The installer is a single script, but everything after that is yours: the dashboard host, its access controls, its backups and its availability.
- Host sizing: Size the dashboard host against the minimum in the Coolify installation docs and plan for growth in your own environment.
- Upgrades: Apply upgrades within the v4.x line. v4.0.0 was the first stable release after a long beta, and the release notes preview a v5 aimed at scalability in the core while v4 stays supported.
- Availability: Monitor the dashboard host and its reachability yourself, since no vendor component is watching it for you.
- Dashboard backups: Back up the dashboard host and its configuration, because restoring it is your responsibility.
- Licensing: Coolify is Apache-2.0 and the self-hosted edition carries no feature limits, so the cost here is your own infrastructure and staff time.
Before you commit, confirm your internal on-call expectations for a dashboard outage and where its recovery runbook will live.
With Coolify Cloud, the Coolify instance runs on Coolify's managed infrastructure, while you still connect and pay for the servers that host your workloads. Your team keeps the application-level work: creating projects, connecting servers over SSH, choosing build packs, configuring databases and setting up backups for the data you own. The pricing page lists $5 per month for 2 connected servers and $3 per month for each additional server, with a 20% discount for annual billing.
- Account and access: Your team manages a Coolify Cloud account and its user roles rather than a dashboard host.
- Server connection: Servers still need SSH access from the Coolify instance, so network paths and key handling remain on your side.
- Application work: Build packs, Docker Compose files, databases and preview deployments are configured by your team in the same way as self-hosted.
- Data location: Your applications and data stay on your own servers, but confirm where the control plane metadata is stored and processed.
- Commitments: Ask Coolify in writing for its upgrade schedule, availability target and incident process for Coolify Cloud, since these are not stated in the facts available to this page.
Check these commitments against your change-management and continuity requirements before choosing this model.
Upgrades differ by model. In the self-hosted model, your team plans and applies each release to the dashboard, while in Coolify Cloud the vendor operates the instance and you verify the outcome for your servers. Coolify's current GitHub release is v4.4.6, released on October 9, 2026, and v4.0.0 was released on April 27, 2026 as the first stable release.
- Current line: v4.x is the line your team would run if self-hosting, with v4.4.6 as the latest GitHub release at the time of writing.
- Next major: The v4.0.0 release notes preview a v5 aimed at scalability in the core, and v4 stays supported.
- Testing: Stage the dashboard upgrade on a non-production host before applying it, and keep a rollback plan.
- Cloud timing: Confirm with Coolify when Coolify Cloud moves to new releases and whether you can defer an upgrade.
- Server agents: Check whether connected servers need changes when the dashboard moves to a new major line.
Ask Coolify to put its v5 migration expectations and Cloud upgrade notice periods in writing before you rely on either model.
The cost components differ between the two models. Self-hosting has no per-server Coolify fee, so the recurring cost is the dashboard host, your staff time for upgrades and monitoring, and your backup storage. Coolify Cloud adds a recurring subscription on top of the servers you already pay for. Based on the published pricing, a Cloud plan with 2 connected servers costs $5 per month, and each extra server adds $3 per month.
- Self-hosted costs: The dashboard host, its backups and the time your team spends on upgrades and monitoring.
- Cloud costs: The monthly fee from the pricing page, with the annual discount, plus the servers that run your workloads.
- Growth: In Coolify Cloud the fee rises with each connected server, while in the self-hosted model growth mainly affects your own infrastructure and staffing.
- One-time work: Initial setup, server onboarding and backup configuration apply to both models.
- Quote request: Ask for the Cloud fee at your expected server count, the annual discount terms and any charges that apply beyond the published plan.
Run the numbers for your expected server count in five years, not only for today.
How costs change as your server count grows
Start with the published figures. Coolify Cloud costs $5 per month for 2 connected servers and $3 per month for each additional server. In an illustrative case with 5 servers, the bill is $5 plus three extra servers at $3 each, or $14 per month. At 10 servers, it is $5 plus eight extra at $3, or $29 per month. Annual billing carries a 20% discount, so the 5-server plan would come to about $134.40 per year, against $168 billed monthly, if the discount applies to the full rate. Confirm that on the Coolify pricing page. The pattern is linear: each added server adds $3 per month, and the platform fee never falls to zero.
Self-hosting removes that per-server line item. The Apache-2.0 dashboard is free to run, and the self-hosted edition is described as free forever with all features. The costs move to your side and recur. The Coolify host itself needs at least 2 CPU cores, 2 GB RAM and 10 GB of free disk, so you pay for a machine that runs the dashboard. Backup storage is a second recurring cost, because scheduled PostgreSQL backups can be uploaded to S3-compatible storage with retention by count, days or size. The largest recurring cost is usually staff time for upgrades, patching, DNS and certificate work, and restore tests, and it grows as you add servers and databases.
Two points belong in every model. Your application servers cost the same under both options, because Coolify Cloud manages the dashboard but not your hosts, so those bills do not change the comparison. What changes is the number of people you need as the fleet grows, and that depends on your environment, not on the price list. Ask Coolify to confirm current pricing, currency, tax treatment and whether the annual discount applies to every server tier. DeployOpen does not publish prices. A quote follows from a written scope that lists your servers, backup targets, upgrade cadence and support hours, so build your own model with your host and staff rates.
How to move between self-hosted Coolify and Coolify Cloud
This sequence moves applications, databases, servers and webhooks between a self-hosted Coolify instance and Coolify Cloud, in either direction. It produces a destination instance that deploys from the same sources, restores data from verified backups and receives deployment triggers only from the new webhooks. Confirm any instance-to-instance migration tooling with Coolify before you begin.
Record apps, databases and environment variables
Record every application, database and environment variable on the source instance before anything moves. For each app, note its source (Git repository, Dockerfile, Docker Compose file or prebuilt Docker image), build pack, domains, assigned server and backup schedule. Store environment variable values in a secrets store your team controls, because this inventory becomes the only record you work from. Confirm with Coolify whether it offers any export or migration tooling between instances, and do not assume one exists. Done when a written inventory covers every app and database and each service owner has reviewed their entries.
Prepare the destination Coolify instance
Create the destination instance in the direction you need. On a self-hosted target, run the single installation script on a supported Linux distribution with at least 2 CPU cores, 2 GB RAM and 10 GB of free disk, on amd64 or arm64. On Coolify Cloud, the instance runs on Coolify's managed infrastructure, and the plan costs $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. Create the administrator account and apply the access controls your security policy requires. Done when the empty instance loads and the administrator can sign in.
Reconnect each server over SSH
Add every server to the destination instance so Coolify can connect over SSH and prepare it to run Docker workloads. Coolify runs one coolify-proxy container on each server, with Traefik as the default and Caddy as the alternative, and both handle HTTPS automatically. If your team manages routing and certificates itself, choose the Custom (None) option and rebuild that configuration by hand. When the destination is Coolify Cloud, confirm with Coolify which source addresses its instance uses before you open SSH access in your firewall. Done when each server reports as reachable and its proxy container is running.
Redeploy applications from the inventory
Recreate each application from the inventory with the same source type, build pack and domains you recorded in the first step. Add the environment variables from your secrets store rather than copying them from old dashboards. Choose Nixpacks, Static, Dockerfile, Docker Compose or Docker Image to match the original setup, and note that Railpack is in beta according to Coolify's build pack documentation. Deploy services that other applications depend on first, then their consumers. Done when every application builds, starts and responds on its domain from the destination server.
Restore databases from supported backup formats
Coolify's scheduled backups cover PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse, and PostgreSQL backups use the pg_dump custom format and can be stored in S3-compatible storage. On the destination, use Import Backup, which accepts PostgreSQL SQL dumps, custom archives, tar archives and all-database dumps. Redis, Dragonfly and KeyDB are not covered by scheduled backups, so move their data with a method you verify separately and confirm it with Coolify before cutover. Done when row counts or checksums in each restored database match the source.
Validate wildcard DNS for preview deployments
The default preview URL follows the pattern {{pr_id}}.{{domain}}, which requires a wildcard DNS record pointing at the server that handles previews on the destination. Create or update that record, then check which Git provider you use: GitHub (through a GitHub App or webhook), GitLab, Gitea or Bitbucket. Open a test pull or merge request, confirm the preview builds and resolves, then close the request to confirm Coolify deletes the preview. Done when the test preview loads at its generated URL and disappears after the request closes.
Cut over webhooks and API access
Point each Git provider webhook or GitHub App at the destination instance. Regenerate any API tokens needed on the destination and update the scripts and CI jobs that call the Coolify API, following Coolify's API authorization documentation. Push a test commit to confirm exactly one deployment starts on the new instance. Then disable the old webhooks so the same commit does not deploy twice. Done when a push deploys only on the destination and the old instance shows no new deployment activity. Keep the old instance and its backups until your rollback plan closes.
Questions buyers ask before choosing a Coolify hosting model
Is self-hosting Coolify free, and what does the staff time cost?
The Coolify software itself costs nothing to self-host: the self-hosted edition is free forever with all features and no limitations, according to Coolify's pricing page. The cash cost sits underneath it. You pay for the servers that run the dashboard and your workloads, plus the staff time to install, patch, back up and monitor the platform. 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, and your apps still run on your servers. To compare fairly, estimate the monthly hours for host patching, backup checks, certificate and DNS issues and on-call, then price those hours at your own loaded rate.
How long does moving from Coolify Cloud to self-hosted Coolify take?
The timeline depends on what you move, and no fixed duration is supplied for it. The main drivers are how many servers are connected, how many applications and databases must be re-pointed, how much data each database holds and how many DNS records and webhooks must change. Your apps run on your own servers in both models, so the cutover centers on the control plane, DNS and any database data you carry over. Preview deployments add work because they depend on wildcard DNS and Git provider webhooks. Ask Coolify in writing which settings and resources transfer and which must be recreated, then rehearse the move in staging before you set a date.
What skills does a team need to run self-hosted Coolify?
Your team needs working knowledge of Linux, Docker, SSH, DNS and backups. Coolify connects to each server over SSH, prepares it to run Docker workloads and deploys from a Git repository, Dockerfile, Docker Compose file or prebuilt image. It runs only on Linux, including Debian, Ubuntu, the Red Hat family, SUSE, Arch, Alpine and 64-bit Raspberry Pi OS, on amd64 or arm64. The minimum host is 2 CPU cores, 2 GB RAM and 10 GB of free disk, and it installs with a single script. Operators must also manage DNS for applications and wildcard preview domains, and set up database backups to S3-compatible storage if they use it. Confirm that your host images, firewall rules and SSH key policy let Coolify reach every managed server.
Can one non-expert run self-hosted Coolify alone?
One capable generalist can run a small Coolify instance, but the risk stays with that person. The dashboard, the proxy on each server, the databases and their backups all depend on hosts you patch and restore yourself. Scheduled database backups cover PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse, but not Redis, Dragonfly or KeyDB, so a small team must handle those separately. Plan for absence with written runbooks, a tested restore of each database and a clear owner for TLS and DNS failures. If nobody on the team can troubleshoot Linux networking, Docker logs or certificate issues, a retainer with an implementation partner can cover that gap, and a managed control plane may reduce the operational load, though you should confirm what it includes.
Does moving between Coolify hosting models cause downtime?
It can, and the downtime usually comes from DNS changes and the data cutover rather than from the applications themselves being moved. Applications keep running on your servers in both models, so you can schedule the switch for a low-traffic window. Database cutovers need a consistent copy of the data. Coolify's PostgreSQL backups use the pg_dump custom format, and Import Backup accepts custom archives, so test a restore in staging before relying on it. Lower DNS TTL values ahead of the change, reconnect servers in a planned order and confirm with Coolify whether dashboard state transfers automatically. No migration tool is described in the supplied facts, so verify any claim of zero downtime against your own environment.
How do upgrades differ between Coolify Cloud and self-hosted Coolify?
Self-hosted Coolify gives you control over upgrade timing, while Coolify Cloud runs the instance on Coolify's managed infrastructure. Coolify v4.4.6, released on October 9, 2026, is the current version on GitHub, and v4.0.0, released on April 27, 2026, was the first stable release after a long beta. Its release notes preview a v5 aimed at scalability in the core, and v4 stays supported. Self-hosted operators schedule upgrades, take a backup first and test the new version against their servers. Ask Coolify for the notice period and rollback approach for its managed service, because those details decide how much change control your team must run.
What does a fixed-scope DeployOpen engagement cover for Coolify?
A DeployOpen engagement plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, including Coolify on your servers. Scope, deliverables and timelines are agreed in writing before work starts. Illustrative scope items include host layout planning, the Coolify installation, server hardening, backup configuration with restore tests, integration with your identity and logging tools and handover documentation. DeployOpen does not publish a price list. A quote follows from the written scope, so list your servers, applications, databases and compliance requirements to get a comparable estimate. Ongoing support, upgrades and continuous testing are available as retainers, and DeployOpen prepares evidence for compliance assessments without issuing audit reports or certifications.
Who is responsible when the dashboard goes down
Availability has two layers, and the responsibility split differs between the two models. The Coolify dashboard and its API are the control plane: they hold your deployment definitions and trigger builds and rollouts. The applications and databases run on your servers, which Coolify reaches over SSH. In both models, if a customer server is down, overloaded or misconfigured, the apps on it are down, because the dashboard was never the thing serving your traffic. Plan your uptime targets for the servers and the coolify-proxy container on each of them, then decide how much the control plane matters on top of that.
In the self-hosted model, your team owns the Coolify instance end to end: the host it runs on, its operating system patches, its redundancy, its backups and its restore process. Coolify's installation requires only a single script on a supported Linux host, so the install is simple, but keeping that host available is still your job. Before you go live, confirm how you would rebuild the instance, where its configuration and database backups live, and how long a restore takes in your environment. Test that restore rather than assuming it works. Also decide who gets paged when the dashboard is unreachable and who can still deploy through the API while it is down.
With Coolify Cloud, Coolify operates the instance on its managed infrastructure, so host patching and instance recovery move to the vendor, while your servers stay in your hands. The pricing page does not, in the material available here, state an uptime commitment, so ask Coolify in writing for the availability target, the maintenance policy, the incident communication process and the recovery approach. Ask specifically what happens to a deployment that is mid-build or mid-rollout if the control plane fails, and whether a partially completed deployment can be retried safely. Your own runbook should cover both cases, because a dashboard outage in either model can stall releases even while production traffic keeps flowing.
How DeployOpen scopes and supports self-hosted Coolify
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For Coolify, that means installing and configuring the dashboard on servers you control, so the control plane sits under your change process rather than a vendor's managed instance.
How we scope
- We agree scope, deliverables and timelines in writing before any work starts.
- The written scope names which servers, networks and cloud accounts Coolify will manage over SSH.
- We list which databases, backup targets and S3-compatible storage the engagement covers, and which stay with your team.
How we build
- We install Coolify on hosts that meet the documented minimum CPU, memory and disk requirements, then prepare each managed server.
- We configure the reverse proxy choice, HTTPS handling and wildcard DNS needed for preview deployments.
- We set up scheduled database backups and test a restore before handing the environment over.
How we hand over
- You receive documentation of the server layout, access paths, backup schedules and retention settings.
- We walk your operators through upgrades, adding servers and rotating credentials so the environment stays yours to run.
- We record which control-plane availability and upgrade responsibilities remain with your team after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the build.
- Retainers can cover Coolify version upgrades and review of changes to the managed servers.
- Ask for the support scope in the quote, including response expectations, which we confirm in writing before work starts.
