Coolify v4 Shipped an MCP Server. Dokploy Didn't. The Self-Hosted PaaS Race Just Split in Two

In a single three-month window this year, the two most popular self-hosted PaaS projects made opposite bets. Coolify pushed v4.0.0 stable on April 27, 2026 after a beta series that ran past build 474, then made a native MCP (Model Context Protocol) server the headline of v4.1.0 on May 18, and added a per-team MCP toggle in v4.2.0 on July 21. Dokploy, over the same stretch of its v0.29.x releases, shipped SCIM 2.0 provisioning, environment-variable encryption at rest, and open-sourced concurrent builds — and zero MCP anything.

One platform is chasing "ask an agent to deploy it." The other is staying deliberately minimal. If you're picking a self-hosted PaaS in 2026, you're not just choosing a dashboard — you're choosing which of these bets you believe.

Here's the split in one table, and then the argument for why it's less of a dilemma than it looks:

The thesis, stated up front so you don't have to dig for it: agent-operability and radical simplicity are not fundamentally in tension. An MCP server is a thin layer over an API you already have. The real cost of agent-operability isn't the ~0.4 GB of idle RAM between these two platforms — it's API discipline: scoped tokens, audit trails, mutations that can't be triggered by a stray GET. That's a maturity cost, not a footprint cost. And Coolify's own release notes prove it, because the MCP server didn't ship alone.

What Coolify Actually Shipped — and What "Read-Only MCP" Really Means​

The timeline matters, because the MCP server was the culmination of a cleanup, not a bolt-on:

• April 27, 2026 — v4.0.0 stable. The end of a beta series stretching back years (the last beta was v4.0.0-beta.474, six days earlier). The betas leading up to it focused on security hardening and API token expiration.
• May 18, 2026 — v4.1.0. The headline: "instance-level MCP support with read-only tools for Coolify resources," with enablement controls in both the API and the UI. Shipped in the same release: structured audit logging covering API mutations, webhook events, and auth outcomes — and a breaking change converting MCP enable/disable endpoints from GET to POST.
• July 21, 2026 — v4.2.0. A per-team toggle for the MCP server, so an admin can turn the agent surface on for the platform team and off for everyone else.

Note the honest scoping: the tools are read-only. Per the release notes, an agent connected to a Coolify instance today can enumerate and inspect — applications, deployments, resources — but cannot mutate. A concrete session looks like this: you ask Claude (or any MCP client) "which of my apps failed their last deployment and why?", and the agent answers by querying the MCP tools directly against your instance — no dashboard tab, no copy-pasted logs. But if you follow up with "restart the broken one," the agent can't do it through MCP. That's still a REST API call with a scoped, expiring token, outside the MCP surface.

Some will read that as a half-measure. It's better understood as sequencing. Read-only agent access delivers most of the day-one value (state inspection, debugging, "what's running where?") at a fraction of the risk, while the scary part — writes — waits until the guardrails around it (audit logs, POST-only mutations, per-team enablement) have shipped. Which, in v4.1.0 and v4.2.0, is exactly what happened alongside it.

Dokploy's Counter-Bet: AI as Authoring Aid, Not Operator​

Dokploy — the open-source Heroku/Vercel/Netlify alternative built on Docker and Traefik — has not shipped a first-party MCP server in any v0.29.x release as of this writing. (Third-party community wrappers may exist; the claim here is about native, supported surface.) Its AI story is deliberately different: an AI Assistant that helps generate deployment templates, plus org-level custom AI provider presets added in v0.29.13. AI helps you author configuration; it does not operate your platform.

What did Dokploy spend those releases on instead? The unglamorous things a small team self-hosting for real wants: AES-256-GCM encryption of environment variables at rest (v0.29.12), SCIM 2.0 user provisioning (v0.29.11), concurrent builds per server moved into the open-source tier, and a steady drumbeat of security fixes for command-injection and authorization-bypass classes of bugs (v0.29.13).

And the minimalism is measurable. Both platforms document essentially the same floor — 2 GB RAM and 30 GB disk — but community reports consistently place Dokploy's idle footprint around 0.8 GB against Coolify's ~1.2 GB. Treat those numbers as anecdata, not spec: Coolify's idle draw depends heavily on which bundled services (proxy, Redis, Postgres) are running, so the delta varies by configuration. The install is a single curl script that its docs say completes "within minutes" — the widely-quoted "3-minute install" is Dokploy's own marketing number, but it's directionally honest.

For a team deploying one Next.js app and a Postgres container to a single VPS, that profile is exactly right. Nothing about that team's life is improved by an MCP endpoint they'll never enable.

One important nuance: Dokploy is not un-automatable. It exposes a REST/tRPC API, and an agent can drive it the way agents drove infrastructure before MCP existed — with hand-written glue code. The gap is agent-native discoverability: MCP gives an agent a self-describing tool catalog, so "connect and operate" replaces "read the API docs and write a client." The capability gap is small. The friction gap is the whole point.

Is the Tension Real? Pricing What Agent-Operability Actually Costs​

Start with the number everyone reaches for: RAM. The community-reported delta is roughly 0.4 GB idle. On Hetzner's entry VPS tiers in 2026, the step from a 4 GB machine to an 8 GB one costs on the order of €3–4/month — and 0.4 GB doesn't even force that step for most single-node setups. If agent-operability really cost only 0.4 GB, every platform would ship it tomorrow. Footprint is not the price.

The actual price list is what Coolify's v4.1.0 release notes read like:

1. Audit logging — an agent that can query (and eventually mutate) your platform is a compliance nonstarter without a trail of who/what/when.
2. No mutations on GET — the GET→POST breaking change matters precisely because agents follow links and retry aggressively; a state-changing GET plus an eager agent is an outage generator.
3. Scoped, expiring tokens — an agent's credential should be narrower and shorter-lived than a human's, or the agent is your biggest attack surface.
4. Blast-radius controls — the v4.2.0 per-team toggle exists because "the whole instance is agent-accessible" is not an acceptable default.

None of that is an agent feature. All of it is API discipline that makes a platform better for humans too — and all of it is work a project can't skip on the way to a trustworthy MCP surface. Which resolves the TODO-list framing of this question: at the feature level, simplicity vs. agent-operability is a false dichotomy — the MCP layer itself is thin, cheap, and off by default. At the maturity level, the tension is real: you can't responsibly expose an agent surface over an undisciplined API, and the discipline is the expensive part. Coolify shipping read-only first is the honest way to sequence exactly that.

That's also why Dokploy's position is coherent rather than backward. A platform that has spent its releases on env-var encryption, authz fixes, and SCIM is building the same prerequisites — it just hasn't put the MCP doorknob on the front of them yet.

The Checklist: What to Demand From an Agent-Operable PaaS​

Whether you run Coolify, Dokploy, or anything else, the split gives you an evaluation rubric. Before you let an agent near a platform that deploys production apps, it should offer:

1. Machine-readable state — an agent can enumerate apps, deployments, domains, and health without scraping a dashboard.
2. Scoped, expiring credentials — per-agent tokens with narrower permissions than any human operator's.
3. A complete audit trail — every agent-initiated read and write attributable and reviewable.
4. Idempotent, explicit writes — mutations behind POST/PUT with idempotency keys, so agent retries are safe.
5. Dry-run / plan surfaces — the agent can show what would change before it changes it.
6. Human-visible diffs — a person can review pending configuration changes (Coolify's v4.1.0 deployment-config diffs are this feature) before or after the agent acts.

Coolify currently scores well on 1, 2, 3, and 6, with writes deliberately deferred. Dokploy scores on 2 and 3 (enterprise) with 1 achievable via its API but not agent-native. Neither yet offers the full six.

This checklist is also, transparently, the design brief behind Bex.co — the open-source, AI-native Render alternative. Bex treats agents as first-class operators from the start: platform state lives in declarative App resources on a Kubernetes/Cluster API fleet you own, so "machine-readable state" isn't an API bolted onto a dashboard — it's the source of truth, and the MCP surface and the human CLI drive the same Render-compatible API. The bet is precisely that you don't have to choose between Dokploy's low-overhead posture and Coolify's agent surface, because agent-operability done as API discipline makes the platform simpler, not heavier.

What the Split Predicts for the 2026–27 Race​

Three predictions, explicitly framed as such:

Read/write MCP is the next frontier, and it will arrive gated. Coolify has built the guardrails (audit, POST-only mutations, per-team enablement); write-capable tools behind a dry-run/approval flow are the obvious next release headline. The platform that ships agent writes with a credible safety story first will set the pattern everyone copies.

Dokploy adds MCP eventually — because it's cheap once the API is disciplined. The work Dokploy is doing anyway (authz hardening, encryption, provisioning) is the expensive 90%. When agent-driven operation becomes a default expectation rather than a differentiator — and the pace of MCP adoption across developer tools in 2025–26 suggests that's quarters away, not years — bolting a read-only MCP catalog onto a clean API is a small release, not a pivot.

"Simplicity" gets redefined. In 2024, simple meant a 3-minute install and a low idle footprint. By 2027, for a growing share of teams, simple will mean "my agent can operate it without me writing glue code." The two definitions will coexist — single-app teams aren't going away — but the platforms that survive the race will refuse the dichotomy and offer both.

The real lesson of Coolify vs. Dokploy isn't that one of them is right. It's that the MCP server was never the hard part. The hard part is a platform API disciplined enough to deserve one — and that's worth demanding whether or not you ever connect an agent to it.

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