HeroCtl vs Coolify: when a single-server panel isn't enough

The question was never "is Coolify good?". It is good. The question is "until when is Coolify enough?".

This post isn't about taking anything down. It's about drawing a line — where the panel on a single server stops being the right answer and starts being a silent trap that shows up at the worst possible moment: in the first meeting with the first customer who asks the SLA number.

Why Coolify won the segment

Worth starting by acknowledging what Coolify got right, without irony.

Five-minute installation on a US$10/month VPS. Clean panel, with vocabulary familiar to anyone who has touched Heroku or Vercel. Active plugin ecosystem, engaged community, frequent releases. The free contract for self-hosting never changed.

For an indie hacker in April 2026, with a 4 GB RAM server running a US$5k MRR SaaS, Coolify is the best option that exists in the market. Better than Dokku, better than Caprover, better than Dokploy in maturity — and infinitely better than orchestrating the same workload on managed Kubernetes, which would charge US$73 per month just for the control plane, before NAT, load balancer, and anything that delivers value — a topic we unpack in Kubernetes is overkill: when you don't need it.

The category "simple self-hosted Heroku" was invented by this generation of tools. Coolify, Dokploy, Caprover share that podium. Coolify leads in adoption, in community, and in release pace. It's not by chance.

The point of this article is specific: there is a wall that appears when your product grows, and that wall has no elegant solution within Coolify. It's an architectural limit, not a bug to be fixed.

The invisible wall: the single server

Coolify was designed around a central server. The panel lives there. The configuration database lives there. Deploy decisions originate there.

That's a coherent design choice — for someone on a single VPS, that centralization is exactly what makes the product so simple. There's no cluster network to debug, no certificate between nodes, no state replication to understand. You spin up a machine, install, deploy. Five minutes.

The question is what happens in the scenarios below:

• The VPS disk starts showing I/O errors. The provider schedules maintenance to "remediate". The machine becomes unavailable for three hours on a Wednesday morning. Everything that was running on it is down.
• A kernel update is pushed by the provider and the machine reboots itself. The Coolify panel comes back — but three containers enter a restart loop because they depend on a volume mount still being remounted. You discover this forty minutes later, via a customer's tweet.
• The provider's entire datacenter has a regional network incident. It happened in January 2024 with a major European provider, in October 2024 with an American one, in February 2026 with a Latin American one. Your machine isn't even broken — it just became unreachable.
• A bad deploy consumes all the machine's memory, the OOM killer starts taking down processes, and the Coolify panel itself enters a loop. You have nowhere to click to revert because the interface controlling the cluster is inside the machine that needs to be controlled.

In all these scenarios, the operational answer is the same: hope the machine comes back, or open a ticket, or bring up a new machine and restore backup. There's no automatic failover. There's no other panel replica to take over. There's no leader election among surviving servers — because there's only one server.

When your first serious customer asks "what's the SLA?", the honest answer is "best-effort, our main machine has three nines of historical uptime from the provider". It's an answer that works for some customers. It doesn't work for customers who have their own SLA to honor. And those are exactly the customers who pay annual contracts.

Coolify multi-server isn't real high availability

The most common confusion in this conversation is Coolify's "remote servers" feature.

Coolify does allow you to connect additional machines as deploy targets. You register an IP, configure an SSH key, and the panel knows it can bring containers up on that remote machine. For those who need to separate staging from production, or to put workers on a cheaper machine, it's genuinely useful.

But it isn't high availability. It's load distribution.

The difference is in where the system's brain lives. In Coolify, the brain is the main machine — where the panel runs, where Coolify's SQLite or Postgres database lives, where the internal queues are. The remote machines are arms. If the brain falls, the arms keep holding what they had in their hands at the moment of the fall — already-running containers don't die. But you lose:

• The web panel, entirely.
• The ability to deploy, revert, change environment variable, read centralized log.
• The ability to redirect traffic between replicas if one falls.
• Automatic certificate renewal (if the main machine was the one responding to the ACME challenge).
• Health checks that would restart problem containers.

You're left in a zombie state: the customer's site might keep responding for a few hours, but you've lost control of the orchestrator. Restarting the main machine becomes the only useful operation — and if the reason for the fall was a corrupted disk, you're restoring backup at four in the morning.

This isn't Coolify's fault. It's a direct consequence of the architectural design — a design that makes total sense for someone who will never need anything beyond it. The problem is when your company grows and customer expectations change. The tool doesn't grow along.

The natural next step

HeroCtl starts exactly where Coolify stops. Same simple-installation promise — one command, five minutes, web panel ready. But the brain of the system is replicated across three or more servers from the very first moment.

In practical terms: you install the same binary on three Linux machines with Docker. The three servers combine state with each other through consensus between servers. Important decisions (which container goes to which node, which version is active, which certificate has been renewed) are written to the replicated log and confirmed only after the majority agreed. If one of the three falls — kill -9, power outage, network partition — the remaining two elect a new leader in about seven seconds and continue serving traffic.

It's not magic. It's a technique known for twenty years, used in production by banks, by messaging systems, by distributed databases. HeroCtl's novelty is wrapping this in a package you install in five minutes, with embedded web panel and without requiring a specialized operator.

The integrated router distributes incoming traffic among healthy replicas automatically. If a server is down, it stops receiving requests — without you needing to touch DNS, without you needing to wake up at dawn. Let's Encrypt certificates live in the replicated log, so any surviving server can renew and serve them; there's no "main machine" responsible for TLS.

The chaos test battery covers real scenarios: kill -9 on the leader (election in seven seconds, no read-request loss), 30-second network partition (cluster reconverges on its own), momentary quorum loss (system enters read-only mode preserving existing traffic, resumes writes when quorum returns), disk wipe on a node (rejoins the cluster and downloads state from the replicated log), forced drain (workloads migrate to surviving nodes in seconds). All five scenarios survived in the public cluster that serves this blog.

Side by side, no flourishes

The table below is the honest version. There's no column without caveats — every orchestration tool is a set of tradeoffs, and HeroCtl is too.

The line that matters most for this conversation is the fifth — real high availability. The others are consequences of it. Without consensus between servers, you can't have a resilient panel. Without a resilient panel, you can't promise an SLA. Without an SLA, some customers don't sign a contract.

The last line also deserves attention. Coolify is amazing with one server. HeroCtl is amazing with three to five hundred. They aren't products in the same range — they are products that cover adjacent ranges of the same problem.

When to stay on Coolify

This section exists because honesty is the defense mechanism of a new tool. If we said "everyone should use HeroCtl", we'd be wrong. There are five profiles where we firmly recommend staying on Coolify.

You have one server and don't plan to have more. If your architecture fits entirely on a 4 or 8 GB RAM VPS, and your business model doesn't require a contractual SLA, Coolify is the right answer. HeroCtl running on a single server works, but you're paying the overhead of a coordination layer that will never need to coordinate with anyone. It's like buying a five-seater car to make only solo trips — it's not wrong, it's just unnecessary.

You're running internal or development applications. Staging environments, internal dashboards, tools that only your team uses, experimental side-projects — none of these cases justify multiplying servers. A two-hour staging outage costs nothing beyond annoyance. Coolify delivers the best cost-benefit for that kind of workload, and we openly recommend it.

You're a hobby developer. Personal projects, blogs, portfolios, experiments with new APIs — stay on Coolify. The mental cost of operating a three-server cluster is bigger than the perceived gain. You want to ship, not administrate infrastructure. Coolify was designed for this profile. We won't try to push a tool with more operational ceremony than the case calls for.

You have strong dependence on plugins from the Coolify ecosystem. If your flow depends on three specific Coolify plugins to integrate with third-party services for which we don't yet have native integration, migrating now is premature. Wait for HeroCtl to mature those integrations or assess whether the specific integration is worth the work to rewrite. We'd rather you wait for the integration to exist than migrate and discover a hole mid-path.

You're not feeling pain. This is the most important and most underestimated criterion. If Coolify never failed for you, if your main machine has three years of uptime, if no customer has ever charged you on SLA — don't migrate out of fashion. Migrating an orchestration tool has real cost (one to two weeks of a senior engineer, plus adjustments). Pay that cost only when the pain justifies it. Migrating before feeling pain is an elegant way to burn engineering time that could be turning into product.

The simple mental rule: if the phrase "if this machine falls at three a.m., I have a serious problem with a customer" describes your situation, it's time to assess. If the phrase "if this machine falls at three a.m., I wake up tomorrow, restart it, and everything goes on" describes it, stay where you are.

How to migrate when it makes sense

The migration doesn't need to be a big bang. The path we recommend is gradual, in four steps, and keeps Coolify running the whole time.

Step 1 — Bring up the HeroCtl cluster in parallel. Three new servers, in the same region, without touching the existing Coolify. Run the installer on each, join the cluster, open the panel. Basic validation: panel responds at the three IPs, test certificate is issued, a "hello world" container comes up and responds. Average time: an afternoon.

Step 2 — Migrate a low-risk application. Choose an internal or very low-traffic application. Something that, if down for ten minutes, doesn't cause panic. Rewrite the configuration file in the HeroCtl format (in general, fifty lines replace what was a set of fields in the Coolify panel). Bring it up on the new cluster. Point a test subdomain. Validate for a week.

Step 3 — Migrate workloads with real traffic, one at a time. For each migrated app, do blue-green: bring up the version in HeroCtl, point DNS to HeroCtl, keep Coolify running the old version for 24 to 72 hours as fallback. If something goes wrong, rollback is swapping DNS back. When everything stabilizes, shut down the application on Coolify.

Step 4 — Shut down Coolify. When all applications have migrated and remained stable for a week or two, shut down the Coolify machine. Keep the Coolify database backup for another quarter, just in case. Then yes, terminate the VPS.

The high point of this path is that at no moment are you without a rollback option. Coolify keeps running until the last day. If migration goes wrong at any step, you take a step back, adjust, try again. There's no "point of no return" forced by architecture.

Typical total time, for a portfolio of ten to twenty applications: two to three weeks, with one engineer dedicating half their time. For larger portfolios, it scales linearly.

Questions we get

Coolify deploys to N servers too. What's the real difference? Coolify deploys containers to N servers. HeroCtl runs the orchestrator on N servers. The difference is where the brain lives. In Coolify, the brain lives on the main machine — remote machines are arms. In HeroCtl, the brain is distributed: three or more servers combine state by consensus, and any one of them can take on the leader role if the current one falls. It's the same difference between "having copies of a document on multiple computers" and "having a real-time collaborative document". Both have multiple machines; only the second survives the loss of one of them without losing control.

Can I use Coolify and HeroCtl together? Yes, and during a migration it's the recommendation. Both run Docker as runtime, so they don't compete for resources at the container level. What changes is which orchestrator looks at which set of machines. Technically, you can keep old applications on Coolify forever and use HeroCtl just for new workloads with HA requirements — some teams choose this approach and never get to shut down Coolify. There's no forced coupling.

How much does it cost to migrate? The direct cost is engineering time: two to three weeks of half-time for a typical portfolio. The indirect cost is the learning curve of the new configuration file — usually half a day for a senior engineer to get the hang of it. There's no license cost to migrate (HeroCtl Community is permanently free, with no server or job limit), nor an exit cost from Coolify (you simply stop using it). The opportunity cost is the engineer not doing something else during those two weeks.

What do I lose from Coolify? The Coolify visual interface is friendlier for someone who has never seen any orchestration before — it's a real trade. Some plugins from the Coolify ecosystem don't yet have an equivalent in HeroCtl, especially integrations with niche services. The Coolify community is larger in volume — forums have more answers for specific questions. And certain UI conveniences (preconfigured templates for famous applications) aren't yet at the same parity. These points are real and we acknowledge them.

And the Coolify plugins I use? Each becomes an individual analysis. For integrations with managed databases (Postgres, Redis), HeroCtl runs these services as ordinary jobs — without needing a specific plugin. For integrations with external services (email sending, SaaS observability), it's generally an environment variable pointing to the vendor's API — replicable in any orchestrator. For very specific plugins, write to us — in some cases, native equivalents are already on the roadmap.

I only have one server now. Is it worth starting with HeroCtl? Honestly: no. If you have one server and no intention of adding more in the next six months, Coolify is better for your case. HeroCtl running on a single server works, but you're paying the overhead of coordination that has nobody to coordinate with. The right time to start with HeroCtl is when you know you'll have three or more servers — whether because traffic grew, because the customer asked for an SLA, or because you want to sleep better. Before that, stay on Coolify.

When are Business and Enterprise prices coming out? They're already published on the plans page, with no "talk to sales". Business adds SSO/SAML, granular RBAC, detailed audit, managed backup, and SLA-backed support — for teams with formal platform requirements. Enterprise adds source-code escrow, continuity contract, and 24×7 support. The contract is frozen for existing customers — there's no retroactive change clause. Community remains permanently free, with no server limit, no job limit, no artificial feature gates. Individuals and small teams never need to leave Community.

What if I want to go back to Coolify after migrating? Possible. The containers run Docker in both cases — the images are the same. What changes is the configuration file and the panel. Going back means recreating the configurations on Coolify and repointing DNS. We never locked anyone in: the HeroCtl binary has no mandatory phone-home, there's no remote kill-switch, and the installed cluster keeps working offline forever. If your decision is to shut down and go back, just shut down and go back. Exit freedom is what makes trust honest.

Closing

The choice between Coolify and HeroCtl is not technical, it's situational.

Coolify is the right answer for a specific phase of a product's growth: solo dev, initial MRR, one server, no SLA pressure. HeroCtl is the right answer for the next phase: small team, growing MRR, three or more servers, first SLA contracts, first customers who charge on availability. Both tools serve adjacent profiles of the same problem.

If you're in the first phase, install Coolify and be happy. If you're entering the second phase and feel the wall coming, HeroCtl meets you on the other side.

To start, on any of three Linux servers with Docker:

curl -sSL https://get.heroctl.com/install.sh | sh

Installation runs in five minutes, the panel comes up on each of the servers, and the cluster is ready to receive jobs. For more on why HeroCtl exists and what problem it tries to solve, read the founding post.

The intent is simple: container orchestration, without ceremony — now with a cluster.