Dokploy Has an MCP Server Too — and It's Bigger Than Coolify's: An AI-Agent Operator's Comparison on a $5 Hetzner Box

Here is a claim you will find repeated across 2026's self-hosted PaaS discourse: Coolify v4 ships an MCP server and Dokploy doesn't, so if you want AI agents deploying your apps, the choice is already made. It is wrong — and wrong in the interesting direction. Dokploy's official MCP package exposes 508 tools across 49 categories with full deploy, redeploy, and lifecycle control, while Coolify's built-in instance-level MCP ships with read-only tools.

The real question was never who ships MCP. It is what each agent interface actually lets an agent do — and what the control plane behind it costs in RAM on the roughly-$5 Hetzner box both projects target.

The correction, with receipts​

Coolify v4.0.0 went stable in April 2026 with north of 55,000 GitHub stars, and v4.1 followed in May adding Railpack builds, structured audit logging, and instance-level MCP support. But read the release notes closely: the MCP support that landed (coollabsio/coolify#9862) is read-only tools over Coolify resources, with API and UI controls to enable it. An agent connected to stock Coolify can inspect your servers, applications, and deploy state. It cannot push the deploy button — not through that interface.

Full agent-driven management on Coolify comes from the community ecosystem: coolify-mcp with 42 tools, or coolify-enhanced with 148 tools wrapping the REST API, both speaking to any MCP-aware client like Claude Code, Cursor, or Cline.

Dokploy, meanwhile, ships Dokploy/mcp as an official package: 508 tools covering the entire Dokploy API across 49 categories, with tool presets (all, minimal, core, deploy, databases, git) so operators can scope what the model sees. Deploy, redeploy, start, stop, rebuild, environment and Traefik config, deployment history and queue management — the agent gets the same lifecycle verbs the dashboard has, over stdio or HTTP transport, authenticated with a Dokploy API key.

Two honest caveats before anyone screenshots the table. First, tool count is not capability: 508 thin wrappers over CRUD endpoints can be less useful than 42 well-designed tools, and a huge tool list costs context-window budget on every agent turn — which is exactly why Dokploy's presets matter.

Second, Coolify's read-only default is a defensible security posture, not a missing feature: giving every connected agent write access to production deploys by default would be the reckless choice. The point of the table is narrower: if your requirement is "an agent deploys without a human in the loop," Dokploy ships that natively and Coolify routes it through community servers. The discourse has the two backwards.

What "the agent is the deployer" looks like on each​

Make it concrete. The task: "redeploy the API app from main and confirm it is healthy." On Dokploy, the agent lists applications, triggers the deploy tool, polls deployment status and queue state, and reads back the result — one MCP connection, no side channels. On stock Coolify, the agent reads application and deployment state through MCP, then has to step outside MCP to cause anything: either call the REST API directly with its token or go through a community MCP server that wraps that API.

Both paths work — Coolify's API is the same one its dashboard uses — but they are two trust and configuration surfaces instead of one, and the community server is a dependency you now track for breaking changes against Coolify releases. (The wrediam/coolify-mcp-server README already documents exactly this churn: Coolify v4.2.0 made state-changing endpoints POST-only, and wrappers had to follow.)

There is one place Coolify's v4.1 release genuinely leads for agent operators: structured audit logging of API mutations, webhook events, and authentication outcomes (coollabsio/coolify#9842). When a non-human is deploying at 3am, "which principal triggered which mutation" stops being compliance theater and becomes your debugging interface. Dokploy authenticates its MCP with API keys through the same API layer as everything else, so the actions are attributable in principle — but Coolify made the audit trail a headline feature, and agent-driven fleets should demand that framing from whichever platform they pick.

The RAM bill on a $5 Hetzner box​

Both projects officially ask for a minimum of 2 GB of RAM, and both run their control plane plus Postgres/Redis-style dependencies resident even when nothing is deploying. The box in question is Hetzner's CX22 — about €3.79 a month, 2 shared vCPUs, 4 GB of RAM, 40 GB of SSD — the closest thing to a standard $5 unit of self-hosting compute. Here is what the control planes idle at, as reported across community measurements:

Take the Hetzner-measured pair — 0.8 GB vs 1.2 GB — as the headline and the ranges as the honesty: idle footprint moves with which services are enabled, whether Swarm is managing the stack, and how much Postgres and Redis are actually holding. Subtract from 4 GB and the shape of the answer is the same in every row: Dokploy leaves roughly 2.8–3.2 GB for your apps, Coolify roughly 2.4–2.8 GB, before the OS takes its share. For one to three small apps, both fit comfortably and the gap is academic. Past that — a fourth app, a database with real data, or anything resembling a local model — the extra 400 MB of headroom is the difference between "fits" and "time for a bigger box," and nextgrowth.ai's FAQ lands in the same place: Dokploy wins on a $5 VPS if RAM is the binding constraint; Coolify's 280-plus service catalog and agent workflow justify the extra footprint once the workload grows past a couple of containers.

One more cost rarely appears in these tables: build-time RAM. Idle numbers describe a box doing nothing. The moment an agent triggers a deploy, the builder — Nixpacks, Railpack, or a Dockerfile build — spikes memory well above either control plane's idle delta, and Coolify's own documentation tellingly recommends 2 GB as a floor while being "comfortable at 4 GB." Size the box for deploy-time peaks, not idle troughs, or the first concurrent build-and-serve moment will teach you the difference with an OOM kill.

Why idle RAM is the wrong metric once an agent deploys​

Here is the irony the original premise gets right: once the deployer is an agent, the 400 MB idle gap is the least interesting number on the page. Three agent-shaped costs swamp it.

First, observation traffic. A read-only MCP interface — Coolify's built-in posture — pushes agents toward poll loops: list applications, check deploy status, list again. Each poll is API and database work on the same small box, and an agent supervising a deploy easily polls dozens of times where a human glances at a dashboard twice. Interfaces that let the agent subscribe or act and wait are cheaper per deploy than interfaces that make it ask repeatedly whether anything changed yet.

Second, the audit surface. Agent-driven fleets generate far more API mutations than human-driven ones — more deploys, more retries, more environment tweaks — and every one of them lands in the audit log and the deployment history the platform retains. Coolify built the structured logging for this; whoever you pick, budget disk and retention policy for a mutation volume that looks nothing like a human team's.

Third, the model itself. The agent has to run somewhere, and the cheapest version of "somewhere" is increasingly on the same box: Coolify's service catalog includes one-click Ollama, and a local model serving the deploy agent turns the RAM conversation upside down — gigabytes for weights and context, against which a 400 MB control-plane delta is a rounding error. If your roadmap has any version of "the agent lives next to the apps," you are not shopping for the leanest control plane anymore. You are shopping for the control plane whose agent interface survives sharing a box with inference, and sizing the box for the model first.

None of this erases Dokploy's efficiency win. It reframes it: idle RAM decides which box you can start on; the agent interface decides what you can do once you are there. Starting cheap and hitting an interface wall costs a migration. Starting 400 MB heavier with room to grow costs four dollars.

Verdict: which box for which operator​

If your operator is an agent and your constraint is a single $5 box today: Dokploy. The official 508-tool MCP gives the agent full lifecycle control over one authenticated connection with scoped presets, and the ~300–800 MB idle footprint leaves the most headroom for apps on a 4 GB CX22. Swarm-native orchestration and a TypeScript codebase your agent can read and patch are supporting arguments, not the deciding ones.

If your operator is an agent and your constraint is auditability and ecosystem breadth: Coolify. The built-in MCP is deliberately read-only, full agent management rides on community servers you must track, and you pay roughly 400 MB more idle — but you get v4.1's structured audit logging as a first-class feature, a 280-plus service catalog including Ollama for the day the model moves onto the box, and the largest community in the single-box PaaS space at 55,000-plus stars.

And if your roadmap says "second box": neither, long-term. Both are single-server tools — that is the documented ceiling both communities acknowledge, and the moment your agent needs to place workloads across machines you have outgrown the category and want declarative multi-machine orchestration instead of a bigger VPS. But that is a post for another day. For the first box, with an agent holding the deploy keys: measure the interface, not just the idle line, and size for the deploy spike and the model — not the screenshot of free -m at rest.

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.