Dokploy Passed CapRover's GitHub Stars in Two Years, Not Nine

CapRover has been letting people self-host a Heroku-style PaaS since October 2017. Dokploy didn't exist until April 2024. As of this week, Dokploy sits at 36,124 GitHub stars. CapRover sits at 15,109. A project less than a quarter CapRover's age has more than double its stars — and pulled ahead without ever becoming the most-starred tool in its own category.

That last part matters, because it's tempting to read "Dokploy passed CapRover" as a story about Dokploy being the best self-hosted PaaS on GitHub. It isn't even close to that: Coolify, created in January 2021, leads the whole category at 59,698 stars. The real story is narrower and more useful than a leaderboard — it's about what CapRover's seven-year head start turned out not to protect against, and it comes down to one feature CapRover still doesn't fully have.

The Numbers, in Full​

Pulled directly from the GitHub API, not a marketing page:

Do the arithmetic the title promises: CapRover needed nearly nine years to reach 15,109 stars. Dokploy needed about two years to pass that number entirely, on its way to more than double it. Forks and contributor counts move the same direction — Dokploy has nearly five times CapRover's contributor base in roughly a quarter of the time window. None of these are vanity metrics in isolation, but stacked together (stars, forks, active contributors, and shipping cadence all pointing the same way) they describe a project that's absorbing an incumbent's mindshare, not just posting bigger star numbers.

Coolify's presence on that table is the detail worth not skipping past. It isn't a counterexample to "Dokploy's Compose-native model is why it grew" — it's corroborating evidence. Coolify is also Compose-native: from a project, you click "Add a new resource," pick a service, and paste a docker-compose.yml directly into the editor, no Git repo required. The two fastest-growing self-hosted PaaS projects on GitHub both made that same bet early. The one that didn't — CapRover — is the one whose growth stalled.

A star count is a lagging, easily-inflated signal on its own — a launch-day Hacker News post can move it more than a year of steady shipping. That's why it's worth triangulating against forks (a much stickier signal, since forking implies someone intends to actually run or modify the code) and contributor count (which requires clearing a PR review, not just clicking a button). All three move the same direction here, and the release cadence below adds a fourth, independent axis pointing the same way — which is what turns "Dokploy has more stars" from a curiosity into a real trend.

What Actually Broke: CapRover's Docker Compose Gap​

Here's the specific, citable reason, not a vibe. Docker Compose is a client-side CLI concept — the parsing and orchestration logic lives in docker compose itself, not in the Docker Engine API that a PaaS control plane talks to. A platform that wants to accept a Compose file has to either shell out to the Compose CLI or reimplement the parts of the spec it cares about by hand.

CapRover chose the second path, and did it narrowly. Its built-in Compose parser recognizes exactly six top-level keys — image, environment, ports, volumes, depends_on, and hostname — and silently ignores everything else in the file: build contexts, networks, healthcheck, secrets, profiles, resource limits, and more. Anything CapRover doesn't recognize doesn't error — it's just dropped, which means a file that "deploys" can still be missing half of what made it work locally, and the gap only surfaces once something's broken in production. A GitHub issue asking for real Compose support (caprover/caprover#768) has been open and discussed since 2020 — and an even earlier request against CapRover's predecessor project, captainduckduck, predates that — six-plus years into CapRover's history, and the gap is still not closed today. CapRover's actual deployment model is the captain-definition file: a single JSON pointer to one Dockerfile per app, closer in spirit to a buildpack than to Compose. Multi-container apps get bolted on through CapRover's "One-Click Apps" template gallery — which are themselves just pre-packaged Compose-like definitions someone else wrote for you, not a path for bringing your own.

Dokploy took the opposite bet from day one. Compose isn't a bolted-on app type — it's a first-class service alongside "Application" and "Database." Pick "Compose" as the source type, select "Raw," and paste a docker-compose.yml directly; Dokploy writes it straight to disk at {COMPOSE_PATH}/{appName}/code/docker-compose.yml with no repository clone required. It supports both plain docker-compose and Swarm stack modes as peer options in the same flow. Nothing about the file needs to be restructured to fit Dokploy's model, because Dokploy's model is the file.

Why Compose Specifically Is the Wedge​

The reason this particular gap mattered more than, say, a nicer color scheme: by 2024, a docker-compose.yml was already sitting in most self-hosters' repos before they ever went looking for a PaaS. Local dev on Compose has been the default for small teams and solo developers for years — a Postgres container, a Redis container, the app itself, wired together in one file that already works on a laptop.

Point that file at CapRover and it doesn't just work. Six supported keys means the volumes might carry over and the build: context and healthchecks won't — so the file needs to be picked apart, and pieces of it rebuilt as a captain-definition and manual environment config in CapRover's dashboard, before the app is even running. Point the same file at Dokploy or Coolify and the migration step is "paste it in." That's not a UI-polish difference; it's the difference between "bring what you already have" and "learn our format first." For a self-hoster evaluating four or five PaaS options in an afternoon before picking one to install on a VPS, that first five minutes decides a lot of the outcome — and GitHub stars are a reasonable proxy for how many afternoons ended in "installed this one."

Release Cadence Is the Other Signal​

Stars measure who showed up. Commits measure who's still there. Dokploy tagged five point releases in July 2026 alone — v0.29.9 through v0.29.13, landing roughly every three to five days. CapRover's last four releases stretch from December 2024 (v1.13.3) to May 2026 (v1.14.2), close to one every six months. Neither number is damning on its own; CapRover's core deployment flow is mature and stable, and a slower release cadence on a finished feature set isn't automatically a red flag. But paired with the Compose gap sitting open for six-plus years, it reads less like "stable" and more like "not the thing getting invested in anymore." A self-hoster comparing four tools on a Tuesday afternoon doesn't read commit logs, but they do notice "last release 8 months ago" against "five releases this month" on each project's GitHub landing page — and that sits right next to the star counts they're also skimming.

What It Means for the Category​

The lesson here isn't "add Docker Compose support" as an isolated checkbox — Coolify and Dokploy both prove that's necessary but the deeper pattern is bigger than one file format. The two projects that grew fastest are the two that let a self-hoster bring their existing infrastructure-as-code as-is, instead of asking them to re-describe their app in the platform's own vocabulary first. CapRover's captain-definition model was a reasonable design in 2017, when Compose itself was younger and less universal as the default local-dev format. By 2024, it had quietly become the tax a newcomer had to pay before their first deploy — and a newer entrant that skipped the tax collected the growth CapRover didn't.

That's a narrower, more durable lesson than "ship a Compose importer," too. A platform built on Cluster API and machine-provisioned Kubernetes fleets — rather than a single Docker host — doesn't get to reuse Dokploy's exact raw-paste flow; Compose was never designed to describe multi-node scheduling, ingress, or the machine lifecycle CAPI manages underneath it. But the underlying principle transfers directly: don't make the newcomer re-describe what they already have in your platform's private vocabulary before their first deploy succeeds. A Render-compatible API that already understands the shape of an app someone is migrating off Render, Heroku, or Railway is the same move in a different format — accept the artifact the user already has, instead of demanding a new one.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.