Elestio's 400+ App Catalog Passes Coolify's: Why Catalog Size Is the Wrong Way to Rank a Self-Hosted PaaS

Five self-hosted PaaS platforms, ranked by app count: Elestio at 400+, CapRover at 346, Coolify at 280+, PikaPods at 200, Cloudron at 100–140. That leaderboard has been making the rounds in 2026 self-hosting comparisons, and it's treated as a maturity signal — the bigger the catalog, the more capable the platform.

It isn't. Catalog size measures how many pre-packaged copies of someone else's application a platform can spin up in one click. It says nothing about how well the platform builds, deploys, and rolls back your own application from a git repo — which is the actual job a deploy-from-git PaaS exists to do. Below is the real table, what it hides, and what a Cluster-API-based platform like bex should actually take from the catalog leaders instead of trying to out-count them.

The Catalog Numbers​

Here's the current standing, compiled from a 2026 platform-by-platform comparison of self-hosted app deployment tools:

Coolify's number is worth a second look because it shows how fast these catalogs move: it sat around 200 templates before the May 2026 v4.0 release and has since grown past 280 with additions like Activepieces, Windmill, Outerbase, and Pocketbase. Elestio ships catalog updates on a weekly cadence — the week of July 5–11, 2026 alone added 12 new services to its total, mostly security and observability tooling. This is a category where the number you read today is stale within a month.

That churn is also where the number starts lying to you. A growing count says nothing about the quality of what's in the catalog. CapRover's 346 templates make it the second-largest catalog in the category, but reviewers now describe the platform's own development pace as having slowed since late 2025, and its one-click apps as frequently outdated or unmaintained. A catalog can grow in raw count while the median template inside it drifts further from a current, patched image — the two numbers move independently, and only one of them is on the leaderboard.

Two Different Products Wearing the Same Word "Deploy"​

The reason catalog size doesn't rank these platforms against each other is that "deploy" means two structurally different things depending on which side of this list you're standing on.

Catalog deploy means: pick a known application — Ghost, Plausible, n8n, Uptime Kuma — from a list, and the platform stands up a pre-built container image with a database, environment variables, and TLS already wired together. You never see a Dockerfile. You never push a commit. The platform's job is to have already solved the packaging problem for that specific app, once, and let you clone the result. Elestio, CapRover's app store, Coolify's service templates, PikaPods, and Cloudron all compete on this axis: more known-good packaged apps, more coverage of the long tail of self-hostable open source software.

Git-push deploy means: you have your own repository — code nobody has packaged before, because it's yours — and the platform's job is to detect a language or Dockerfile, build an image, run it, wire up TLS and a domain, and give you a rollback path when the build you just shipped breaks something. There is no template for your app, because your app isn't in anyone's catalog. This is the loop Dokku pioneered with Heroku buildpacks and git push, and it's the loop CapRover, Coolify, Dokploy, and bex all also ship (Coolify and CapRover happen to do both — templates and git push — which is exactly why their catalog numbers get quoted as if they were the whole product).

A concrete way to see the split: if what you want today is "Ghost running in five minutes," a 400-app catalog is the correct thing to be shopping for, and Elestio's breadth is a genuine, well-earned advantage — you should pick it over a git-push PaaS with zero templates. If what you want is "my own repo, built and deployed, with a rollback button when I ship a bad commit," the catalog count of every platform on that list is irrelevant, because none of those 400 templates is your code.

Why Chasing the Catalog Count Is the Wrong Race for a Git-Push PaaS​

It's tempting to read the leaderboard and conclude that a git-push platform is behind by however many templates separate it from Elestio. That's the wrong lesson, for two reasons.

First, template count and template quality trade off against each other, and a catalog vendor's actual competitive pressure is maintaining that trade-off — not extending it. Every template is a promise to track that upstream project's releases, rebuild the image, patch the CVEs, and keep the Compose file working as the app's own configuration surface evolves. CapRover's slowdown is what happens when that promise stops scaling with the catalog: the count keeps the marketing page impressive while the median template quietly rots. Racing to add templates without racing to maintain them is exactly the trap that already caught the platform sitting at #2 on this list.

Second, and more fundamentally, it's not the same competitive surface a git-push PaaS is on. The thing a team evaluating "will this platform build and ship my own application reliably" actually checks is build detection accuracy across languages, build cache behavior, deploy speed, zero-downtime rollout, and how fast a rollback recovers from a bad deploy — none of which a bigger catalog touches. A platform that spent its 2026 roadmap adding template #347 instead of shaving build time or hardening its rollback path would be optimizing a metric that has nothing to do with why a team picked deploy-from-git in the first place.

The maintenance side of that trade-off has a name, too: OWASP lists "vulnerable and outdated components" as its own top-ten category (A06) precisely because an unpatched base image is one of the more common ways a production container gets compromised, independent of anything the application code does wrong. A one-click template is a base image someone else chose on your behalf, and every day it sits unrebuilt after an upstream CVE lands is a day that choice is quietly aging out from under the person who clicked "deploy" once and moved on. A git-push PaaS doesn't inherit that liability the same way — the base image is the one you specified in your own Dockerfile, rebuilt on every push you make, not a shared template drifting between someone else's release cycles.

What a Git-Push PaaS Should Actually Borrow​

None of this means the catalog leaders have nothing to teach a Cluster-API-based platform. The genuinely useful idea underneath "400+ one-click apps" isn't the count — it's that a huge fraction of self-hosted deployments are a known application, not custom code, and a platform that makes the reader write their own Dockerfile for Ghost every time is making them redo work that's already been solved publicly.

The part worth borrowing is the packaging, not the managed-instance model: a curated set of starter repositories — a bex.yml and Dockerfile for a handful of the most commonly self-hosted apps (Ghost, Plausible, Uptime Kuma, n8n) — that a user forks and git-pushes through the platform's normal build path, rather than a hidden managed container the platform provisions on their behalf. That keeps every deployment inside the same git-push loop, the same build logs, the same rollback mechanism a custom app gets — instead of standing up a second, parallel deployment system just to special-case popular apps. It's catalog convenience without a catalog maintenance team, and it doesn't cost the platform an "agent lane" retrofit either — a forked starter repo pushed to bex is the identical event as any other git push, whether a human or an AI agent triggered it.

Concretely, that looks like a starter-templates/ directory in bex's own repo — ghost/bex.yml + Dockerfile, plausible/bex.yml + Dockerfile, and so on — each one a normal git repository a user forks, not a managed instance a control plane provisions. Forking one and pushing it produces exactly the same deploy event, the same build log, and the same rollback button as pushing a from-scratch app, because it is a from-scratch app as far as the build pipeline is concerned; the only difference is that someone already wrote the Dockerfile. That's the opposite of PikaPods' model, where the per-app fee buys a fully managed instance the user never sees the internals of at all — closer to renting a template than owning one.

What doesn't transfer, and shouldn't: managed database provisioning behind those templates, or a closed marketplace UI that hides the underlying Dockerfile from the user. Both are explicit non-goals for a platform built around owning the machines and seeing the actual build, not renting a managed instance of someone else's packaging decisions.

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.

Sources​

• I Compared 6 Platforms for Deploying Self-Hosted Apps in 2026 — DEV Community
• Elestio Catalog Updates: 12 New Releases This Week (July 5–11, 2026)
• Coolify Docs — Services Overview
• Coolify vs CapRover: Which Self-Hosted PaaS Wins in 2026? — Contabo Blog
• CapRover: A Self-Hosted Heroku Alternative in 2026 — Sliplane
• Best Self-Hosted PaaS Platforms in 2026: Coolify vs CapRover vs Dokploy vs Server Compass

All figures cited above are drawn directly from the linked sources.