Komodo vs Coolify vs Dokploy: What GPL-3.0 With No Server Cap Actually Buys You

Your fourth server is where Portainer sends you the bill. Business Edition is free forever — for up to three nodes. Connect a fourth box and you are choosing between a Community Edition with the RBAC stripped out, a $155/year homelab license that forbids commercial use, or a Starter plan at $995/year.

Nothing about your workload changed. You just own one server more than the free tier allows.

Komodo's entire pitch is that this moment never arrives. The Rust-built deploy tool from moghtech/komodo manages Docker Compose stacks, image builds, and containers across an uncapped number of servers from one Core-plus-Periphery-agent control plane — entirely under GPL-3.0, with no paid tier gating any feature and no cloud edition waiting to meter you. The project's revenue is an OpenCollective donate button.

The 30-second verdict: if you already own the servers and want one pane of glass over all of them with RBAC, 2FA, and Swarm support included — not upsold — Komodo is the cleanest ownership story in self-hosted fleet tooling. If you want git-push PaaS ergonomics or you need the platform to provision the machines themselves, it is the wrong tool, and this post will show you exactly where that line is.

The head-to-head: license, cap, and gated features in one table​

This is the table the title promises. Four tools, four different answers to "what do you actually own":

Two honest caveats before anyone screenshots this table. First, Coolify and Dokploy are also $0 to self-host with no server cap, so Komodo's edge over them is not price — it is structure. A permissive license plus an open-core /proprietary directory is a business model that can gate features later; GPL-3.0 with no tiers anywhere is a license that cannot gate them without a relicense the community would have to accept.

Second, GPL-3.0 is not AGPL: copyleft triggers on distribution, so someone could in principle run a modified Komodo as a hosted service without sharing changes. The practical moat is the community, the trademark, and the maintainer's no-tiers posture — not a license that closes the SaaS loophole.

What Komodo actually is​

Komodo calls itself "a tool to build and deploy software on many servers," and the architecture matches the sentence. A central Core service (backed by MongoDB, FerretDB-friendly) holds state and serves the UI and API; a lightweight Periphery agent runs on every managed server and executes Docker operations locally. A dedicated CLI (km), a full OpenAPI spec, and typesafe Rust and TypeScript clients hang off the same API, so anything clickable is also scriptable.

The feature inventory, as of the v2 line, reads like Portainer plus a CI system plus a small Ansible:

• Unlimited servers with CPU, memory, and disk monitoring, threshold alerts, and browser-based shell sessions.
• Stacks and containers — Compose projects deployed and managed across all servers, with status, logs, container shells, and automations.
• Docker Swarm management — multiple swarms through one entrypoint: nodes, services, stacks, configs, and secrets.
• Image builds from git repos pushed to your registry, including AWS spot-instance builders for burst capacity.
• Procedures and Actions — chained multi-stage executions plus API scripts written in a built-in editor.
• Declarative resource sync — Komodo resources defined as TOML files in git and synced into Core.
• RBAC with user groups and per-resource access levels, passkey/TOTP two-factor auth, and linked OIDC/GitHub logins — all in the free and only edition.

Version 2.0.0, shipped in March 2026, is what makes Komodo 2026-relevant rather than a homelab curiosity. The headline changes: full Swarm support, outbound Periphery connections (agents dial out, so managed servers need no inbound firewall hole for the control plane), PKI authentication between Core and Periphery with automatic rotation, reusable onboarding keys, a terminals dashboard with km ssh, digest-based auto-updates, and semver image tags (:2) replacing latest so auto-updaters stop accidentally jumping major versions. One breaking note worth knowing: v2 binaries target Debian Bookworm with OpenSSL v3, so Periphery on Bullseye-era or Ubuntu 20.04-era hosts needs a self-compile or the containerized agent.

Adoption-wise, Komodo sits at 11,000+ GitHub stars — an order of magnitude below Coolify's ~60K and Dokploy's ~34K. Star counts are a rough proxy, but here they proxy something real: community size, tutorial depth, and the odds that someone has already hit your edge case. Komodo is also essentially a single-maintainer project under Mogh Technologies Inc. That concentrates bus-factor risk the Apache-licensed giants spread across larger contributor bases — though GPL-3.0 at least guarantees the community could fork the whole thing, tiers and all, since there are no proprietary parts to leave behind.

What "no server cap, ever" is worth in dollars​

Run the math for a concrete fleet: 12 VPSs running client staging environments, Compose stacks, and a small Swarm — the shape where a team graduates from "SSH and hope" to a control plane.

On Portainer, 12 commercial nodes need Business Edition past the 3-node free grant. Starter lists at $995/year, and the line item exists purely because of node count — the workloads are identical to the ones that were free at three nodes. The alternative is Community Edition with no RBAC, which for a team with interns, contractors, or clients is not a real option.

On Komodo, 12 servers cost the same as one: $0, with RBAC and 2FA included. The 13th server costs $0 too. There is no pricing page to consult because there is no pricing page.

On Coolify and Dokploy self-hosted, the same fleet is also $0 — this is the representative comparison the previous section's caveat demands. The honest price story is therefore not "Komodo is cheaper" but "Komodo's $0 is load-bearing." Coolify monetizes through managed Cloud (from $5/mo) and premium add-ons, and Dokploy's /proprietary directory explicitly reserves SSO, RBAC, audit logs, and white-labeling as future paid features under a source-available license.

Neither gates anything you need today. But both can move a feature across the paywall tomorrow with nothing but a changelog entry. Komodo's GPL-3.0 codebase has no second directory, no BE binary, and no license key — moving a feature behind a paywall would require relicensing work the community holds a copy of. That is the difference between a pricing decision and a structural guarantee.

The copyleft side of the trade deserves its own beat, because it cuts both ways. GPL-3.0 means any team that modifies Komodo and distributes the result must share source — which is precisely why a vendor cannot quietly close it. But it also means a company that wants to embed Komodo's Core into a proprietary product, or fork it into a commercial platform without sharing changes, cannot.

Apache-2.0 lets Coolify's and Dokploy's code travel into closed products; GPL-3.0 keeps Komodo's code open at the cost of keeping it out of closed products. If you are using the tool rather than building on it, the copyleft costs you nothing and buys you permanence. If you are building a business on top of someone else's control plane, the licenses point opposite ways.

Where Komodo stops: it manages servers, it never provisions them​

Here is that boundary, stated as plainly as possible: Komodo assumes the servers already exist. You buy the VPSs, install an OS, get Docker running, and point a Periphery agent at Core. Everything downstream of "there is a reachable Docker daemon" is Komodo's world — builds, deploys, stacks, Swarm services, monitoring, procedures. Everything upstream is yours.

Concretely, Komodo never does any of the following:

• Provision machines. No cloud API calls, no "add a node" that creates a VM. Compare Cluster API, where a MachineDeployment replica bump creates real infrastructure through a provider like CAPH.
• Own OS and image lifecycle. When Ubuntu 24.04.3 ships a kernel you need, or the v2 Bookworm/OpenSSL break above bites an old host, the upgrade path is your runbook, not a rolling machine rollout.
• Autoscale. There is no cluster-autoscaler equivalent, no declarative replica count for servers — only for the containers on servers you already have.
• Remediate dead nodes. No MachineHealthCheck equivalent: if a host dies, Komodo shows it red; it does not replace it.

Do not let the declarative resource sync confuse this picture. TOML-in-git synced into Core is GitOps for Komodo resources — stacks, builds, procedures — which is genuinely good practice. But syncing a stack definition is not reconciling a machine.

The day your fleet needs "declare 6 nodes, wake up to 6 healthy nodes" — provisioning, health-checking, and replacement as a control loop — you have outgrown the manage-the-boxes category entirely, and no control plane that starts from reachable Docker daemons can get you there. That is the seam a Cluster-API-based platform is built to not have: machines as declarative API objects with the same reconcile-and-repair semantics as Deployments.

This is also why "no server cap, ever" and "provisions the servers themselves" are different ownership promises, not competing versions of one. Komodo promises the control plane will never tax your growth. A provisioning platform promises growth itself is an API call.

A team running 12 stable VPSs should want the first promise. A team whose server count changes weekly should want the second — and should budget for the operational weight that comes with it.

Who should pick which​

• Homelab to ~50 stable servers, Docker/Compose/Swarm: Komodo. The no-cap, no-tiers, RBAC-included combination has no equal at this shape, and v2's outbound agents plus PKI auth remove the two historical objections (inbound firewall rules, shared passkeys).
• Git-push PaaS ergonomics (preview deploys, buildpacks, one-click databases): Coolify or Dokploy. Komodo deploys your Compose files; it does not turn a git push into a URL with the managed-platform feel. Pick the panel whose UX matches your developers, and accept the open-core structure with eyes open.
• Fleet size changes often, or uptime needs machine-level self-healing: a provisioning platform — Cluster API on Hetzner-class hardware, or a managed Kubernetes control plane. None of the three panels replace node lifecycle; budget for the real thing instead of scripting around its absence.
• Embedding fleet management into a proprietary product: look hard at the licenses before the features. Apache-2.0 cores travel into closed products; Komodo's GPL-3.0 does not.

Komodo's bet, in one sentence: the control plane over your servers should be infrastructure you own outright — copyleft-guaranteed, untiered, and unmetered — even if the servers themselves remain your problem. For the large middle of self-hosting, where the fleet is stable and the pain is operational sprawl, that is exactly the right bet. And when the fleet stops being stable, the honest next step is not a bigger panel — it is a platform that provisions.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. When your fleet outgrows "manage the boxes" and needs declarative provisioning with an agent-operable API, star the repo on GitHub or deploy your first app today.