Dora NodaEvery "AI agents can now deploy on Coolify" roundup this year points to the same fact: Coolify shipped a Model Context Protocol (MCP) server. That's true. What almost none of those roundups mention is that Coolify's own, built-in MCP server can't deploy anything. It can't restart a service, edit an environment variable, or touch a single running container. It can only look.
The tool that actually deploys, restarts, and reconfigures apps on a Coolify instance from a chat window isn't Coolify's. It's a community project, built by one developer, holding your API token, running outside the platform's own security model entirely. That distinction — official vs. third-party, read vs. write — is the whole story, and it's worth fifteen minutes because the same gap is about to show up in every "self-hosted PaaS + AI agent" claim you read this year, bex's included.
What Coolify's built-in MCP server actually ships
Coolify creator Andras Bacsai merged PR #9862 in May 2026, and it landed in v4.1.0 on May 18. The changelog is precise about what it adds: "instance-level MCP support with read-only tools for Coolify resources and API/UI enablement controls." Ten tools, all of them queries:
| Category | Tools |
|---|---|
| Overview | get_infrastructure_overview |
| Servers | list_servers, get_server |
| Projects | list_projects |
| Applications | list_applications, get_application |
| Databases | list_databases, get_database |
| Services | list_services, get_service |
Coolify's own docs are direct about the limitation: the MCP server is "currently read-only, with write operations planned for a future release." There's no deploy, no restart, no create, no update_env_var. An agent connected to the official server can tell you how many applications a team runs and what state they're in. It cannot change any of it.
The security model around those ten tools is genuinely solid, for what it does. A root-authenticated user has to explicitly flip a toggle (Settings → Advanced, or POST /api/v1/mcp/enable) before the instance serves anything at /mcp at all. Every response is scoped to the team tied to the caller's API token — no cross-tenant visibility. Sensitive fields (passwords, tokens, raw IDs) get scrubbed before they reach the model. That's a careful, minimal-blast-radius design. It's also, today, a read-only dashboard replacement — not the "AI agent deploys your app" feature the headlines describe.
Where "AI deploys on Coolify" actually comes from
The write-capable server people are actually describing is coolify-mcp, built by independent developer Stu Mason and published to npm as @masonator/coolify-mcp. It's a mature project — 485 GitHub stars, 66 forks, 34 releases, 98%+ test coverage — and it does everything the official server doesn't:
| Category | What it does |
|---|---|
| Deployment | Create apps from a public repo, private GitHub, SSH key, Docker image, or raw Dockerfile |
| Control | Start, stop, restart applications, databases, and services |
| Environment | CRUD on individual env vars plus bulk updates across resources |
| Batch operations | restart_project_apps, bulk_env_update, an emergency stop_all_apps |
| Provisioning | Hetzner Cloud / DigitalOcean server creation, SSH key management |
| Docs | Full-text search over Coolify's documentation |
That's 42 tools total, consolidated with action parameters to cut token usage roughly 85% versus a naive one-tool-per-operation design (6,600 tokens vs. 43,000, per the project's own benchmarking). It's a genuinely well-built piece of software. It's just not Coolify's software — it's a third party's REST client wearing an MCP wrapper, authenticating to your instance with whatever token you hand it, exercising the exact same public API a human could call from a terminal.
So when a comparison says "Coolify already lets an agent deploy without a dashboard," the accurate version is: a community-maintained client, unaffiliated with Coolify's own security review process, can drive Coolify's REST API on an agent's behalf, using your credentials. That's a materially different claim than "the platform vendor ships this."
Why the gap matters: the write path has no audit trail of its own
None of this makes coolify-mcp unsafe to use. It makes it a different trust boundary than the one Coolify's own docs describe for the official server. Walk through what each write actually does when an agent calls it:
- Token scope. The community server runs with whatever permissions your Coolify API token already has — team-wide, by default, since Coolify's tokens aren't scoped down to individual actions. There's no separate "deploy-only" or "restart-only" credential the MCP layer enforces; it inherits the token's full reach.
- No first-party audit trail. Coolify's official read-only tools sit behind the same middleware, logging, and access-control path as every other feature. The community server's write calls hit the public REST API directly — from Coolify's perspective, an agent-issued
restartlooks identical to a human clicking restart in the dashboard. There's no "an LLM decided to do this, here's the tool call and the prompt that produced it" record unless the wrapper itself logs one. - Single-maintainer dependency. The de facto standard for "AI deploys on Coolify" is one person's side project. That's not a knock on the code — it's a statement about what happens to a platform's most AI-forward feature if that one maintainer stops shipping releases.
None of these are reasons to avoid the tool. They're reasons the honest answer to "can an agent deploy unsupervised on Coolify" is "yes, if you're willing to hand a community client your full-scope token and accept that the audit trail is whatever that client chooses to keep."
Where bex's own MCP server sits on this same split
We build bex, a self-hosted, open-source Render alternative, so it's worth holding our own MCP server to the same test rather than only pointing it at a competitor. bex's MCP server is shipped, not planned — but it's honest to say exactly where it sits on the read/write line, because it isn't at "full deploy-from-chat" either yet:
| Coolify official | coolify-mcp (community) | bex | |
|---|---|---|---|
| Status | Shipped (v4.1.0) | Shipped (third-party) | Shipped |
| Read (list/get apps, servers, logs, metrics) | ✅ | ✅ | ✅ |
| Restart / suspend / resume a service | ❌ | ✅ | ✅ |
| Env var / API key writes | ❌ | ✅ | ✅ |
| Create a new app from a git repo | ❌ | ✅ | ❌ (planned) |
| First-party audit path (same core as REST/GraphQL) | ✅ | ❌ (bypasses platform) | ✅ |
bex's MCP tools — restart_service, suspend_service, resume_service, env var and API key CRUD, Postgres list/get/create — are thin adapters over the exact same Service methods the REST and GraphQL surfaces call, not a separate client hitting a public API from outside. A write over MCP gets the same logging and access path a write over REST does, because it's the same code underneath. What bex doesn't yet do is take a bare git repo and turn it into a running app over MCP — that's "deploy-from-chat," and it's roadmapped, not shipped, because it depends on the control-plane work landing first. We'd rather say that plainly than let a comparison table imply otherwise.
Parity stops being a differentiator once the leader ships it — here's what actually would be
Once every self-hosted PaaS in this category ships some MCP server, "we have an MCP server" stops telling a buyer anything. The real question moves one level down: is the write path built as a first-class part of the control plane, or bolted onto an existing dashboard-shaped API after the fact? Three concrete things separate the two:
- State as data, not a UI wrapped in JSON. An agent-first control plane exposes structured state —
phase,revision,url— that an agent can diff and reason about, the same fields a human dashboard reads, rather than tool calls that just mirror whatever endpoints the web UI happened to need. If the MCP tool list looks exactly like the dashboard's page list, the API was built for people first and adapted for agents second. - The audit trail is a property of the write path, not the adapter. If a restart issued by an agent and a restart issued by a human click the same code path, the audit log doesn't need special-casing for "was this an LLM." If the agent's write goes through a separate client hitting a public API from outside, whoever built that client decides whether a record exists at all.
- Verbs an agent can retry without guessing what happened. Declarative intent in, converged state out — an agent that calls
restarttwice because the first response timed out shouldn't have restarted the service twice. That's a property of the underlying API design, not something an MCP adapter can retrofit.
None of that is Coolify-specific — it's the bar any platform, including bex, has to keep clearing as "has an MCP server" turns into "has one that's actually safe to let an agent drive unsupervised."
Three questions worth asking before you trust the claim
Before you take any "self-hosted PaaS lets an AI agent deploy" claim at face value, ask:
- Official or community? Is this the platform vendor's own code, reviewed under their security process, or a third party's client holding your credentials?
- Read-only or write-capable, and which specific verbs? "Has an MCP server" and "can restart a production service from a chat prompt" are different claims. Ask for the tool list, not the marketing line.
- Does a write get audited through the platform's own core, or does it just run with your API token? If the answer is the latter, that's not automatically disqualifying — it just means the audit trail is only as good as whatever the community client chose to build.
Coolify's official server answers all three cleanly today: first-party, read-only, fully audited. The community server that everyone actually means when they say "Coolify + AI agent" answers them very differently. Knowing which one a given claim is describing is the whole difference between an informed decision and a marketing headline.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with an MCP server whose write path runs through the same audited core as everything else. Star the repo on GitHub or connect an agent to your own instance today.