Canine's MCP Server Can Deploy — Coolify's Still Can't: A Tool-by-Tool Audit

Coolify's official MCP server ships ten tools. All ten are reads. Dokploy's ships sixty-plus, full create-deploy-restart-stop, each one tagged read-only, destructive, or idempotent before an agent ever calls it. Canine — a newer, Kubernetes-native entrant to the same self-hosted-PaaS category — ships eight tools. Seven are reads. One, DeployProject, is a write. That's the whole story in one sentence: Canine's MCP server can do something Coolify's still can't, but it isn't close to what Dokploy already ships, and it comes with no safety net at all.

That's worth fifteen minutes, because "self-hosted PaaS ships an MCP server" is about to become the least differentiating sentence in this whole category. What actually matters is the tool list underneath it — and Canine, Coolify, and Dokploy have each landed somewhere different.

What Canine actually ships​

Canine (canine.sh, GitHub) is a self-hosted PaaS that brings Heroku-style git-push deploys to a Kubernetes cluster you already have — connect a GitHub or GitLab repo, it builds a Docker image, and pushes it to your cluster as a Deployment, Service, and Ingress. It's built as a Rails app (not a Kubernetes Operator with CRDs — more on that distinction below), installable via Helm, a Docker Compose script, or Homebrew, and it attaches to an existing cluster rather than provisioning one itself. It's sponsored by Portainer, which funds the founder's work full-time and sells optional paid support around it — a real answer to "what's the business model" that came up directly on the project's Hacker News launch thread, and one worth knowing before betting production infrastructure on a young project.

One correction worth making plainly: Canine's own marketing site describes the self-hosted edition as "MIT licensed." It isn't. The LICENSE file in the actual repository is Apache License 2.0 — permissive either way for a self-hoster's purposes, but not the license the project's own copy claims. It's a small discrepancy, but it's the kind of thing worth checking yourself rather than repeating from a landing page, on Canine or anyone else's.

The rest of the pitch holds up: "no per-seat pricing," multi-cluster management from one UI, roughly 2.9k GitHub stars as of this writing — a genuinely young project (its HN launch was seven months ago) growing inside an already-crowded field of Coolify, Dokploy, CapRover, and Kubero.

Worth flagging, too: "no per-seat fees" isn't actually a differentiator inside this category — Coolify and Dokploy are both self-hosted and free of per-user pricing already. What Canine is really selling against isn't Coolify or Dokploy's pricing; it's the managed, per-seat-billed PaaS tier above all three (Render, Railway, Heroku), the same target every tool in this comparison is aimed at. The interesting question for a team picking between Canine, Coolify, and Dokploy was never "which one charges per seat" — none of them do — it's the architecture and tooling questions below.

The MCP tool audit​

Here's the tool-by-tool comparison, because "has an MCP server" tells you nothing about what an agent connected to it can actually do.

Canine's full list: ListAccounts, ListProjects, GetProjectDetails, GetProjectLogs, CheckBuildStatus, ListAddOns, and GetAddOnLogs are reads — an agent can inspect projects, pull logs, check a build's status, and list databases and caches attached as add-ons. DeployProject is the one exception: it deploys a project to its Kubernetes cluster, full stop. There's no RollbackProject, no RestartService, no StopProject anywhere in the list. The server also requires OAuth 2.0 authentication against a discovery endpoint — a more production-shaped auth story than a static API key, at least.

Coolify's ten tools, shipped in v4.1.0 (May 2026), are all reads by design — the project's own changelog calls out "read-only tools" explicitly, with write operations "planned for a future release." Dokploy shipped its write-capable server about a month earlier, in v0.29.0, and it's the only one of the three that pairs write access with machine-readable safety metadata an agent (or the human reviewing its tool calls) can check before anything runs.

So the honest one-line summary: Canine is the only one of the three where an agent can trigger a real production deploy through the platform's own official MCP server today outside of Dokploy. That's a genuine point in Canine's favor over Coolify. It's also a much smaller step than Dokploy already took.

Put concretely: point an MCP-aware client like Claude Code at a Coolify instance today and ask it to "redeploy the API service," and the honest answer is that it can tell you the service's current status and logs, then stop — the write path doesn't exist yet. Ask the same question against Canine, and DeployProject actually fires; the agent gets to complete the task, not just describe it. Ask it against Dokploy, and the agent can do that plus stop, restart, or scale the service, with the tool call itself carrying a tag telling the client whether the action is safe to retry if the connection drops mid-call. Three platforms, three different answers to the same one-sentence request.

One write tool, no safety net​

The gap that matters isn't tool count — it's what's missing around the one write tool Canine does expose. DeployProject has no annotation telling a calling agent (or a human approving the call) whether it's safe to retry, whether it's destructive to in-flight requests, or what happens if it's called twice in a row. Dokploy's tool-safety tagging exists specifically to answer that question before an agent acts, not after. Canine's doesn't have it yet.

More concretely: nothing in Canine's current MCP surface lets an agent undo a deploy it just triggered. There's no rollback tool, no restart, no stop. An agent can push a bad deploy through DeployProject; recovering from it means a human going back to Canine's own dashboard, not asking the same agent to fix what it broke. For a chat-driven "let the agent operate my infrastructure" workflow, that's the actual ceiling right now — not whether the deploy button exists, but whether the undo button does.

Attach-to-a-cluster vs provision-the-cluster​

Where Canine's architecture genuinely differs from Coolify's is worth naming plainly, separate from the MCP question. Coolify manages Docker containers on a single host (or a small fleet it SSHes into) — there's no Kubernetes anywhere in its own model. Canine is Kubernetes-native from the ground up: it talks to the Kubernetes API directly from its Rails backend, with no Operator or CRDs mediating that state (Kubero, by contrast, defines KuberoApp and KuberoPipeline custom resources and reconciles them the way a proper Operator does). Both Canine and Kubero share the same starting assumption, though: bring a cluster, and the tool layers a developer experience on top of it. Neither provisions the machines underneath.

That's the specific gap a Cluster-API-based platform closes that none of the three above do — it provisions the cluster itself, on owned hardware, rather than assuming one already exists for the PaaS layer to attach to. A team evaluating Canine still needs an EKS, GKE, or self-managed cluster in hand before helm install does anything: nodes provisioned, a container network plugin installed, an ingress controller running, cert-manager configured for TLS — all of it done and healthy before Canine's own install script has anything to attach to. A team evaluating a Cluster-API-based platform gets that fleet lifecycle as part of the same tool, from bare Hetzner machines to a running cluster to the first deployed app, instead of treating "have a working Kubernetes cluster" as a precondition someone else's runbook already solved.

Where this actually leaves the category​

None of this makes Canine a bad bet — a Portainer-sponsored, Kubernetes-native, Apache-licensed PaaS with an MCP server that can already trigger real deploys is a credible entrant seven months into its public life, and being the only one of the three with an actual write tool beyond Dokploy is a real result, not a marketing line. But it's worth being precise about what "ships an MCP server" has come to mean across this category in 2026: three different projects landed on three different points on the read/write axis, and only one of them (Dokploy) has bothered to tell an agent, in the tool call itself, which of its actions are safe to retry.

The pattern across all three: nobody yet answers "is my fleet healthy, across every node, right now" from inside their MCP server — the question a multi-node operator actually needs answered before trusting an agent with deploy authority at all. That's not a gap any of these three will close with a point release; it's a different kind of tool than "list my projects" or "deploy this one."

Bex.co is the open-source, AI-native Render alternative — Cluster API provisions the machines, not just the app layer on top of them, and the same MCP surface an agent calls to deploy is built to answer fleet-wide questions, not just single-project ones. Star the repo on GitHub or deploy your first app today.