Dora Noda514 beats 354 beats 280 — and none of those numbers should decide which self-hosted PaaS panel you install. Dokploy's catalog lists 514 one-click blueprints, CapRover's holds 354 one-click apps, and Coolify's advertises 280+ services, and every 2026 roundup prints the scoreboard like it means something. Here is the scoreboard first, before a single paragraph of punditry — with the one column the roundups leave out: what each number actually counts.
| Panel | Catalog count (Aug–Sep 2026) | What one entry is |
|---|---|---|
| Dokploy | 514 blueprints | A docker-compose.yml plus template.toml metadata, an icon, and a manifest, in the Dokploy/templates repo |
| CapRover | 354 one-click apps | A YAML app definition in caprover/one-click-apps (public/v4/apps), deployed onto Docker Swarm |
| Coolify | 280+ services | A prebuilt service template (Postgres, Redis, Ghost, Supabase, ~two dozen developer tools, and hundreds more) selected from the New Resource list |
The counts come from an August 2026 three-way comparison and Coolify's own catalog as surveyed by Bitdoze and Pickuma. And here is the thesis before the evidence: a template count measures packaged Docker Compose files, not platform capability.
It keeps climbing precisely because a new template is the cheapest thing any of these projects can ship — one community pull request — while the features that would obsolete the single box are the most expensive. Count the templates if you enjoy scoreboards. But pick your panel on what no catalog entry provides.
What a template actually is
Open any Dokploy blueprint and the anatomy is the same every time: a docker-compose.yml doing the real work, a template.toml describing ports, domains, and mounts, an SVG icon, and a meta.json manifest. Community additions follow a fixed ritual — the PrivateBin template (PR #947) and the Gotify template (PR #946) each run the repo's validate-template and validate-docker-compose scripts and land as four files. CapRover's entries are the same idea in YAML: one app definition per directory under public/v4/apps, plus a third-party repo ecosystem (Eleventy-built catalogs you paste in as a repository URL) for everything the official list skips. Coolify's 280+ services are prebuilt templates for the usual suspects — Postgres, MySQL, MongoDB, Redis, MinIO, Plausible, Umami, Ghost, WordPress, self-hosted Supabase — chosen from a dropdown instead of written as Compose by hand.
None of that is a criticism. A packaged Compose file with sane defaults, persistent volumes pre-wired, and TLS routing filled in genuinely saves an afternoon. The point is ontological, not qualitative: a catalog entry is a starting configuration, not a platform primitive.
It does not schedule anything, replicate anything, provision any machine, or isolate any tenant. It is a recipe card in a box that can hold infinitely many recipe cards. Once you see the catalog that way, the arms race reads differently — and the first crack in the scoreboard is that the numbers themselves are squishy.
Coolify's count is quoted as 200+ by the Coolify Enhanced fork, 280+ by Bitdoze, Pickuma, NextGrowth, and most reviewers, and 362 by the same August comparison that gives Dokploy 514 and CapRover 354. All of them can be sincerely true at once: built-in templates versus community sources versus every compose file the dashboard can render are three different denominators, counted on three different dates, against catalogs that grow weekly. A metric with three simultaneous true values is not a measurement. It is marketing with a number attached.
Why the count keeps climbing
Because templates are the cheapest unit of progress in open source. Each one is a single community pull request, authored by someone who wanted that app, reviewed against a validator script, and merged without touching the panel's core. Dokploy's catalog grows the way a stamp collection grows: Velix API in July 2026 (PR #793), PrivateBin and Gotify within a day of each other, hundreds more the same way.
The maintainer cost per addition rounds to zero, the contributor gets their app one click away, and the headline count ticks up by one. Everybody wins, and the scoreboard gets a little more lopsided every month.
But the maintenance bill scales with the count, and it arrives as repo-wide toil. When Dokploy needed to normalize mount declarations across its catalog, the fix was a single pull request touching all 502 blueprints — 79 of them carrying a bare [[config.mounts]] header that TOML parsed as one empty array element.
That is the catalog's true shape: 500+ copies of the same conventions, each one a future migration when a convention changes, an image tag rots, or an upstream Compose file drifts. The count measures contributor throughput on the way in. It says nothing about freshness on the way out — which templates still deploy cleanly, which pin image tags from 2024, which nobody has clicked since the PR merged.
Compare that cost curve with the features the TODO list for every panel has carried for years: declarative machine provisioning, a control plane that survives losing its own host, database replication that is not "the volume on that one disk." Those are core-architecture projects measured in quarters, not community PRs measured in days.
Coolify's v5 rewrite — explicitly aimed at multi-server scalability, per the v4.0 release coverage — is the honest version of this tradeoff: the project shipped v4.0 stable in April 2026 after two years of beta, added an MCP server in May 2026 (the first native AI integration in a self-hosted PaaS), and still needs a rewrite to lift the architectural ceiling. Templates ship weekly. Ceilings lift yearly. Any metric that grows fastest where the work is cheapest will, left alone, become the whole marketing story — which is exactly what happened.
What no catalog entry gives you
To be fair to all three panels, the ceiling is not "you cannot add a server." All three have a second-machine story, and they differ honestly: Dokploy is Swarm-native with Traefik spreading stateless replicas across joined workers; CapRover has run Swarm behind nginx since 2017 (plus one mandatory extra piece, a shared registry the workers can pull from); Coolify attaches SSH remotes per workload with its dashboard as a single control-plane point of failure and Swarm still experimental. We worked out each mechanism with costs in September's second-machine showdown — about ~$12/month for a two-box pair on any of the three self-hosted — and the punchline stands: every panel solves stateless capacity on machine two, and none of them replicates your database.
That punchline is the shape of the whole ceiling. Multi-server in these panels is orchestration without provisioning: nothing in any catalog — not the 514th blueprint, not the 354th app — does any of the following:
- Provision a machine. Adding capacity starts with you renting a VPS, installing an OS, and joining it by hand (or pasting an SSH key). There is no "declare two more nodes" primitive, no machine lifecycle controller, no failed-node replacement that does not begin with a human opening a hosting dashboard.
- Reconcile drift. No controller compares the fleet's actual state with a declared desired state and converges them. Configuration lives in a dashboard database on one host; if reality diverges from it, nothing outside a human notices.
- Survive the control plane's own host. Coolify's dashboard server is a single point of failure for deploys, renewals, and backups. Swarm-based panels inherit Swarm's manager quorum, which is better — until you realize the quorum still runs on machines nobody provisions or heals declaratively.
- Replicate state. Postgres, Redis, uploads, volumes: one disk, one box, backups as the recovery strategy. Template #515 will happily deploy another stateful service onto the same unreplicated volume layout.
- Isolate past the container boundary. No catalog entry adds per-tenant network policy, noisy-neighbor QoS, or identity-aware access. The isolation model is Docker containers on shared Docker hosts, full stop.
This is the "Cluster-API-shaped features" gap the premise names: the missing layer is a declarative machine lifecycle — nodes as cattle described in manifests, reconciled by controllers, replaced rather than repaired. Swarm schedules containers across machines you procured. Cluster API procures the machines.
Only one of those survives contact with a dead disk at 3 a.m. without you.
How to actually evaluate a catalog
If the count is vanity, what replaces it? A ten-minute overlap test beats any scoreboard. Write down the five apps you will actually deploy in the next year — for most teams it is something like Postgres, Redis, an app runtime, an object store or uploads volume, and one oddball (n8n, Plausible, Outline, Matrix).
Then check each panel's catalog for exactly those five, and for each hit ask two questions: does the template deploy on the current panel version, and when did its definition last change? Five fresh hits beat 500 entries you will never click, because the catalog's job is to save you five afternoons, not to win a census.
Three questions generalize the test for any panel comparison:
- Is my oddball in there, and is it fresh? Every catalog has Postgres. The differentiator is your weirdest dependency — check its image tags and last commit, not the catalog's total.
- Who maintains the long tail? A catalog of community PRs with validator scripts (Dokploy's model) grows fast and rots unevenly; a smaller curated set rots slower. Either is fine if your five are covered; neither matters if they are not.
- What did the last ten releases ship — templates or primitives? A project whose changelog is all catalog additions is optimizing the scoreboard. One shipping control-plane HA, provisioning, or backup primitives is optimizing your second year.
Run that filter and the arms race inverts: the panel with the smallest catalog but the freshest overlap and the most primitive-shipping changelog is usually the better install. Counts are for roundups. Freshness and primitives are for operators.
The count will hit 1,000. The ceiling will still be there.
Somebody's catalog will pass a thousand templates in 2027 — the PR velocity all but guarantees it — and the announcement will read like a platform milestone. It will be a packaging milestone. Every template is a promise that deploying app N takes one click; none of them is a promise about what happens when the machine underneath needs replacing, the database outgrows its disk, or the second box joins the fleet. Those promises are architectural, they ship on a yearly cadence, and they are the entire evaluation once your first year ends.
So enjoy the catalogs — genuinely, they are useful — and then evaluate the panel underneath with the overlap test, the freshness check, and the changelog read. Pick the tool whose ceiling you can live under, not the one whose count impressed a roundup.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with declarative multi-machine fleet management instead of a single-box ceiling. Star the repo on GitHub or deploy your first app today.
