I pointed Claude Code at my Coolify box. Deploying by sentence is a bit too easy.
This blog runs on Coolify, on a single OVH VPS, and I've been happy with that setup for months. So when Coolify shipped a first-party MCP server, my first instinct was delight: I could wire Claude Code straight to my instance and just ask it to deploy. My second instinct, about four minutes later, was that this is a little too easy, and that's the part worth writing down.
What actually shipped
Coolify added a built-in MCP (Model Context Protocol) server in v4.1.0, released in May 2026 — the work of Andras Bacsai, Coolify's creator, so this is genuinely first-party, not a community bolt-on. It's served straight off your instance at /mcp and authenticates with the same Bearer API token Coolify already uses. There's nothing to install; if you're on a recent version, it's there.
It exposes something like forty tools. The ones that matter for this conversation are the lifecycle actions:
deploy— queue a deployment for an application (with aforceoption, and optionally a specific pull request)control— start, stop, or restart an application, database, or service (stopping requiresconfirm=true)cancel_deployment— cancel a queued or in-progress deploy
One correction to the excitable version of this story that's going around: there is no rollback tool. If a deploy goes bad, recovering is still a manual job. Keep that in mind — it matters below.
Wiring it up
You create a token under Security > API Tokens, pick a scope, set an expiry (you can go as short as seven days — do), and point your MCP client at the instance:
claude mcp add coolify \
--transport http https://your-instance.example/mcp \
--header "Authorization: Bearer 12|your-token-secret"Then you talk to it. "What's deployed on the blog project?" "Why did the last build fail?" "Redeploy the blog." The read questions are the ones that genuinely earned their place in my workflow within a day — I stopped SSHing in to check container status because asking was faster. The write ones work exactly as advertised, which is the problem.
The honest security read
Coolify's selling point for the MCP server is that it queries your instance "without exposing sensitive credentials" to the assistant. That's true and worth having — the agent never sees your env vars. But it quietly sidesteps the real question, which is what the token can do, not what the agent can see.
The token carries whatever scope you grant it: read, read:sensitive, write, deploy, or root (which bypasses every check). A deploy-scoped token lets the agent redeploy, restart, and stop your services. The only guardrail I could find is that stop wants confirm=true — and that's an argument the model sets on its own call, not a human clicking "yes." There is no human-in-the-loop approval step in the box.
An agent with a deploy token on a one-box VPS can restart production off a misread sentence, and there is no rollback tool to undo it. That's not a bug. It's just the honest cost of the convenience.
One more thing to flag: as of the version I looked at, the docs still describe the server as "read-only, with write operations planned" while simultaneously documenting the write tools. The label lags the reality. Don't trust the wording — check what your token's scope actually permits, because that's what governs.
How I actually use it
I split it in two. For letting an agent answer questions about my infrastructure — what's running, what broke, what the build log said — I use a token scoped to read / read:sensitive. That's most of the value and almost none of the risk, and it's genuinely great. For anything that mutates state, I grant deploy only when I specifically mean to, with a short expiry, and I still push the actual deploy button myself rather than handing the whole loop to the model. root tokens don't go anywhere near an MCP client. Ever.
Treat a read token like a dashboard and a write token like your production shell — because that's what each one is. Used that way, the Coolify MCP server is one of the nicer additions to my setup this year. Used carelessly, it's a very fast way to find out your VPS has no undo.