HeroCtl vs Dokploy: an honest comparison

In DevOps sub-Reddits in 2026, among the self-hosted tools that appeared after the Coolify wave, the most-discussed name is Dokploy. Clean panel. Fast install. A community that grew at a speed most orchestration projects of the last decade haven't seen.

And a technical decision that defines everything else: Dokploy runs Docker Swarm as the cluster engine. It's not a detail — it's the foundation. Everything good it delivers comes from that choice, and so does everything that limits it.

This text is the honest reading of that choice, and the point-by-point comparison with the path HeroCtl took. No attack on Dokploy, no rose-tinting of HeroCtl. Both products solve similar problems with different philosophies, and the decision between them is more than panel preference.

Where Dokploy got it right

Before the contrast, the credit. Teams evaluating Dokploy today find a product that does five things right and does them well.

The UX is cohesive. The panel has its own visual identity, linear flows, and the buttons do what they promise. For those coming from Heroku or the old commercial panel that got expensive in recent years, Dokploy gives off the familiar feel of "open, click, deploy". It's the kind of polish that only appears after many iterations on top of real user feedback.

Installation is fast. One command, five minutes, panel up. For individual projects and small teams, that minimum friction is what separates "I'll try" from "I'll give up and stick with the expensive cloud".

Multi-server is out of the box. You add a second and a third server through the panel and Swarm underneath takes care of distributing containers. For someone who had never thought about high availability, becoming HA by configuration is a big advance over panels that run on a single server only.

The integrated router works. There's an embedded router that terminates TLS, issues Let's Encrypt certificates automatically, and forwards traffic to containers. You don't need to set up and maintain a separate reverse proxy, write virtual host configuration by hand, or memorize certificate renewal flags.

Good support for common stacks. Node, Django, Rails apps, projects with a direct Dockerfile, projects via docker compose — everything spins without adjustments. The community publishes one-click plugins for the most common databases, queue tools, basic observability.

That list is honest. Whoever says Dokploy is "just another wrapper" isn't looking carefully. It's a serious product, with traction, made by people who listened to users.

The fundamental technical choice — Docker Swarm

The point that changes the conversation is the engine. Dokploy didn't invent its own cluster control plane — it consumes the Swarm that already comes inside Docker. The panel talks to the Swarm API, which coordinates the agents on each server. When you add a server through the panel, it's a swarm join underneath.

That decision has real virtues. Swarm has been stable for nearly a decade. The API is consistent with the docker compose that most teams already know — declaring services has the same shape in both. Leader election is embedded, comes free with swarm init. And because it's part of Docker, any server already with Docker installed can join the cluster with one command.

The problem is what happened to Swarm since 2019. Docker Inc. decided that year to focus almost all orchestration engineering on other products of the company, and Swarm entered what internal communications at the time described as "maintenance mode". Practical translation: security fixes continue, bug-fix releases continue, but new features stopped. There's no public roadmap of evolution. No one from the Docker team has presented at a conference, in the last five years, scheduling improvements, network improvements, encryption between services, integration with new runtimes.

The community reaction was immediate. In a few weeks, a Terraform fork — OpenTofu — came off the page, with Linux Foundation governance. Months later, Vault gained OpenBao with similar governance. Nomad and Consul were left without an equivalent strong community fork. There were discussions, halted contributions, some maintainer departures — but nothing the size of what happened with Terraform.

Swarm isn't abandoned — it's in stasis. And stasis has a compound cost.

When an overlay network between nodes has an edge case on specific cloud providers, that case sits waiting for someone outside to propose a patch. When a new container runtime pattern emerges — lightweight runtimes, confidential containers, isolation improvements — Swarm doesn't absorb it. When you want encryption between services that goes beyond Swarm's optional encrypted overlay, the answer is "set up a separate product on top".

Dokploy inherits this profile. Each Swarm limitation becomes a Dokploy limitation with no own evolution path. It's not Dokploy's fault — it's the mathematical consequence of building on top of an engine that stopped evolving.

HeroCtl's technical choice

HeroCtl made the opposite decision: build the control plane from scratch, without depending on Swarm or on the popular orchestration colossus. It's not "not invented here" purism. It's the realization that orchestration in the "1 to 500 server" range is a different problem from what both Swarm and the colossus solve, and neither is going to refocus on that niche.

The practical consequence is roadmap freedom. When the team decides that encryption between services needs to be native — not plugin, not optional overlay, not external operator — just implement it. When we decided that persistent metrics should run as an internal job of the cluster itself, without setting up three external products, it was an architecture decision without conditional. When we needed to optimize the deploy path so that a thousand containers enter rotation in a few minutes, there's no queue behind Docker Inc. or the foundation that maintains the colossus.

The honest counterpart: HeroCtl is newer. Has less mileage than Swarm. Has a smaller community. The one-click plugin pile is shorter. That's the trade-off of building the entire control plane instead of consuming a ready-made one. The first six months of closed production — four servers, five total vCPUs, ten gigabytes of RAM, sixteen active containers, five sites with automatic TLS — showed the core holds up. The panel is still in visual catch-up.

Operational comparison

Side by side, in matters that matter to whoever's going to operate.

Installation. Dokploy: five minutes to panel up — installs Docker if it's not there, does swarm init, brings up the panel. HeroCtl: five minutes too — downloads an executable file, registers the service, brings up the agent. Operational tie.

Real multi-server. Dokploy depends on Swarm's control plane — three coordinating servers or more so the loss of one doesn't bring down the cluster. HeroCtl has its own replicated control plane, also in three servers or more. Both deliver real HA. The difference is who you're depending on: the current state of Swarm or the current state of HeroCtl.

Panel. Both have one. In 2026, Dokploy's is more visually polished — more years of iteration and a larger community giving feedback. HeroCtl's covers the same use cases (deploy, metrics, logs, cluster topology, certificates, secrets, audit) but in aesthetic catch-up. Product honesty: if the panel's aesthetic is decisive in the decision and weighs more than architecture, Dokploy wins today.

Plugins and marketplace. Dokploy has more one-click plugins today — Postgres, Redis, MinIO, observability. HeroCtl runs any container as a job, with the same uniform interface; what's missing is the "click and have it" showcase. For those who prefer to describe a job in a configuration file and version it in the repository, HeroCtl gets to the same place. For those who prefer click and have, Dokploy gets there faster.

Metrics and logs. Dokploy: stack via external plugins — Prometheus, Grafana, Loki or similar set up separately. HeroCtl: metrics and logs as internal jobs of the cluster itself, with embedded single writer. The difference is less about who delivers better data, more about how many products you're maintaining. Small teams usually value the shorter pile; teams with SRE usually prefer the flexibility of plugging in the stack they already know.

Encryption between services. Dokploy doesn't bring it by default. Swarm has overlay network with optional encryption, but Dokploy doesn't promote that path as first-class. For real mutual encryption between all services, it's one more product on top. HeroCtl brings it embedded — all communication between cluster containers is encrypted by default, with automatic PKI, no external operator. It's the difference between "has option" and "comes turned on".

Control plane observability. Dokploy: you inspect Swarm state via docker commands on the server plus panel for the app. HeroCtl: uniform control plane API exposes job, agent, election, certificate state, in own endpoints — audited.

Comparative table

The honest version of the decision. As always, every orchestrator is a set of tradeoffs.

The column that drives the decision the most is the first. Everything else derives from it.

When Dokploy is the right choice

Honesty demands the section. There are scenarios where recommending Dokploy is the correct answer.

You like Docker Swarm and it meets what you need today. Typical web apps, database managed outside the cluster, low requirement of internal encryption, small team that prefers predictability over platform evolution. Swarm will hold this for years. Building on top of it means building on top of something tested and stable, even if stopped.

The most polished panel in the self-hosted segment matters a lot to your team. If the visual interface is part of the internal sale to the rest of the company, if your CTO will show it to the CEO and the impression matters, Dokploy comes out ahead in 2026. HeroCtl is closing this distance, but hasn't closed it yet.

You already deploy via docker compose and want minimum migration path. Dokploy accepts compose with little friction. Bringing an entire team accustomed to compose to a new job spec model is an organizational cost that not every project justifies.

You want an active community of one-click plugins. If your flow is "I need Postgres with replication, click, done", Dokploy delivers that today. HeroCtl delivers the same Postgres, but you describe the job and version it in the repository.

You don't have formal requirements for native encryption between services or detailed audit. For a five-person team with a SaaS that hasn't yet sold to the first Enterprise customer, Dokploy is enough answer. Leaving it later is work — but it's work you may never need to do.

When HeroCtl is the right choice

The symmetric profiles.

You want a control plane that evolves with its own decisions. For projects where the execution platform is part of the product — not just incidental infra — depending on an engine in maintenance is a strategic risk. Building on something that evolves is different from building on something that maintains.

Encryption between services needs to be native. If your architecture has dozens of services talking to each other, sensitive data trafficking between them, and you don't want to set up a separate service mesh nor trust "cloud provider private network" as the only layer, it makes a difference to have encryption by default.

You need detailed audit. Whoever signed Business knows who did what and when — who promoted a job version, who ran which administrative command, who rotated which secret. For teams with growing compliance requirements, this isn't optional.

You want source-code escrow as a continuity insurance. Enterprise includes a contract with a third-party custodian: if the company behind HeroCtl ceases operations, the code is delivered to paying customers with internal continuity license. For organizations that can't afford "what if the company breaks", that structure is what unlocks procurement approval.

Application range 3 to 500 servers with formal requirements. It's the range where neither Swarm in maintenance nor the colossus designed for tens of thousands of machines serves well. It's exactly where HeroCtl aims.

The Swarm in production question

Worth being fair here — and being specific.

Swarm remains stable. For the absolute majority of use cases, it will deliver what it promises for a few more years. Typical web apps, microservices of medium complexity, rolling deploys, healthchecks, basic service discovery — all this runs. Stories of Swarm cluster in production for five or six years without a serious incident exist in volume.

The point isn't "Swarm will break". It's "Swarm won't improve". Building on top of it in 2026 is tacitly signing that the set of capabilities it has today is the set you'll have forever. For projects where this is an acceptable trade-off, no problem. For projects where encryption between services, native observability, integration with new runtimes, or scheduler extensibility will matter in the next three years, it's worth considering a stack that keeps evolving.

There's another angle. When Swarm has an edge case — overlay network with intermittent loss on specific cloud providers, strange scheduling when a node returns after a long partition, unexpected health check behavior on slow-starting containers — these cases are now debugged by the outside community. Docker Inc. isn't on call. Solving becomes your team's project. In HeroCtl, these cases are handled by the team that wrote the code — you open a report, we ship a fix. It's a different support model because engineering investment continues to happen.

It isn't an ideological argument of "new code is better". Swarm is stable precisely because it's old. The argument is practical: the evolution of the product you'll use in the next five years depends on who's investing. In Dokploy, part of the evolution depends on people who stopped touching Swarm in 2019. In HeroCtl, it depends on people touching the control plane today.

Migration between them

Conceptual path, not recipe. Each project has its own details — write to us if you want specific help.

Docker images serve in both. The Dockerfile you use in Dokploy is the same one you use in HeroCtl. There's no special build, no customized runtime.

Environment variables migrate with the same keys. Where you have an env vars block in Dokploy, you have an equivalent block in the HeroCtl job spec. The names don't change.

Named volumes are kept. Volume mounted in /var/lib/postgresql/data continues mounted there. The concept of persistent volume between restarts is the same.

The compose that Dokploy accepts doesn't convert 1:1 to the HeroCtl job spec, but the mapping is direct. Service becomes task. Network becomes network policy. Deploy strategy becomes rolling update strategy. The first migration takes an afternoon per application; after that, copy and paste with substitutions.

Ingress: Dokploy's router and HeroCtl's integrated router both end in configuration-as-code. You describe host, redirect, certificate in very few lines in either of the two. The translation is mechanical.

For teams with up to ten applications, manual migration in an afternoon. Above that, an experimental converter covers the common cases — write to us.

Questions we get

Is HeroCtl more mature than Dokploy? Not in all dimensions. Dokploy has more community time, more plugins, a more visually polished panel. HeroCtl has its own control plane with active evolution, real high availability tested in a documented chaos battery, and a roadmap independent of any other project. "Mature" depends on the axis. In panel aesthetics and marketplace, Dokploy. In platform architecture and explicit commercial contract, HeroCtl.

And the panel, is Dokploy's better? In 2026, yes — more visually polished, more years of iteration, more incorporated community feedback. HeroCtl's covers the same use cases and is in aesthetic catch-up. The important question is whether the visual difference is the decisive criterion for you. For some teams it is. For others, architecture weighs more.

Which consumes less resources? Dokploy adds the panel overhead plus the Swarm overhead inside Docker — Swarm itself is light, but the panel is a reasonably complete web app. HeroCtl has a control plane between 200 and 400 MB per server, including embedded web panel. In a small cluster, both fit comfortably on modest servers. The difference isn't decisive in the decision.

And the database backup? In both, the database is an explicit responsibility of whoever operates. Dokploy has one-click plugins for Postgres and similar, but automatic backup is additional configuration — you usually set up a cron job or a separate backup plugin. HeroCtl treats the database like any other job, with persistent volume; backup is a parallel job you define. Business includes managed backup with windows and retention. In neither is "set and forget" an honest answer — the database deserves attention in both.

Dokploy is open source, HeroCtl isn't, does this worry me? Fair question. HeroCtl has Community Edition free forever, with no server limit, no job limit, no artificial feature gates. The binary has no mandatory phone-home or remote kill-switch — once installed, the cluster works offline indefinitely. Enterprise includes source-code escrow with a third-party custodian, so if the company behind the product ceases operations, the code is delivered to paying customers with internal continuity license. It's not the same as open source, but it solves what open source solves in this context: guarantee against vendor disappearance. The commercial contract has been published since day one and is frozen for whoever signs today — there's no retroactive change clause.

Can I use both, one for dev and the other for prod? Technically yes, but rarely makes sense. Docker images are portable between both, so the path works. In practice, two different orchestrators in adjacent environments doubles the team's operational knowledge. We recommend choosing one and sticking with it. If the question is fundamentally which to choose, write to us — discussing case by case is more useful than generic advice.

Which scales higher? For above a thousand servers, neither is the obvious choice — that range is the territory of the colossus designed for tens of thousands of machines. In the 1 to 500 server range, HeroCtl was designed specifically. Dokploy scales well within what Swarm scales — typically up to a few dozen nodes in production without gymnastics. Above that, Swarm starts to require care that wasn't in the product's original proposal.

Closing

The choice between Dokploy and HeroCtl isn't between good product and bad product. Both are serious. The choice is between different platform philosophies.

Dokploy chose to build a UX and product layer on top of a mature but static engine. HeroCtl chose to build the entire control plane to control evolution. Real trade-offs in both directions.

If you're on Dokploy today and not feeling the limitations, stay. It's a good product. If you're evaluating both in greenfield, read the post on why we created HeroCtl to understand the motivation behind the decision to build the control plane from scratch. If you're coming from Heroku or commercial panels that got expensive, also worth the post Self-hosted Heroku in 2026 — the market context helps.

To try HeroCtl in three minutes:

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

One executable file, one server to start, two more when you want real HA. Embedded panel, automatic certificates, encryption between services by default. No phone-home, no kill-switch, frozen commercial contract.

The intent is simple: container orchestration, without ceremony.