Dora NodaYour platform team finished the evaluation in an afternoon. Coolify deploys from git in minutes, Dokploy's UI is the friendliest of the bunch, Dokku is a single script, and CapRover has been humming along since 2018. The demo goes great — and then the security review kills it in one meeting. No SSO. No audit trail. No demo of either on the roadmap. The tool that won on every engineering criterion loses on the two criteria nobody benchmarked.
That is the 2026 split in deploy platforms, stated bluntly: the managed clouds ship governance and keep your data on their multi-tenant infrastructure, while the self-hosted favorites hand you the box with no governance at all. Here it is in one table.
| Capability | Coolify | Dokploy | Dokku | CapRover | Managed clouds (Replit / Lovable / Retool / Superblocks) | appCrane |
|---|---|---|---|---|---|---|
| Enterprise SSO (SAML / OIDC) | No — social OAuth only | No | No — SSH keys only | No — one shared password | Yes (Enterprise tier) | Yes, incl. SSO-only mode |
| SCIM / lifecycle provisioning | No | No | No | No | Yes | Yes |
| RBAC beyond admin/everyone | Teams + invites, coarse | Limited | None | None | Yes | Yes, role matrix |
| Audit trail on deploys/rollbacks | Limited | Basic | No | No | Yes | Yes, per-user, agents distinguished from humans |
| Approval gates | No | No | No | No | Varies | Yes — gated promote/rollback |
If your team cannot adopt infrastructure without compliance sign-off, that table is the whole article. Everything below is the evidence: what each tool actually ships, what "No" concretely costs, why the managed side proves governance is the priced moat, the one self-hosted counterexample proving the gap is closable, and the build checklist for a platform that wants to close it.
What the self-hosted four actually ship today
Start with the facts, because the marketing pages blur them. None of these tools is badly built — they are built for an audience that never had to answer an auditor.
Coolify has the most complete story of the four and it still stops short. Authentication is social OAuth via GitHub, GitLab, Google, Azure, or Bitbucket, plus teams with member invites. There is no SAML, LDAP, or generic OIDC against a corporate identity provider, and audit logging in the v4 line is limited. The gap is not theoretical: CVE-2026-86117, affecting Coolify through 4.3.17, let an attacker register a victim's email on any enabled OAuth provider and get signed into the victim's account — the OAuth callback matched on unverified email without binding the OAuth identity, bypassing passwords and two-factor authentication entirely. That is precisely the class of bug a SAML/OIDC integration with a real identity provider makes structurally harder, because the identity proof comes from the IdP, not from a self-asserted email string. Coolify's outgoing deployment webhooks are likewise unsigned — no HMAC, no timestamp — so downstream automation cannot even verify an event came from the platform.
Dokploy is widely praised as the easiest first production PaaS on one machine, and its own comparison coverage concedes limited RBAC. Its 2026 authorization CVE is the more alarming of the two: CVE-2026-72863 found that Dokploy's WebSocket handlers for in-app terminals and log streaming authenticated the session but never authorized it, so a low-privilege member could reach root on the Docker host. Authentication without authorization is the governance gap in miniature — the platform knows who you are and still cannot answer what you are allowed to do.
Dokku and CapRover are simpler to describe because there is less to describe. Dokku's access model is SSH keys to a shared user: whoever can push can do everything, and "revoking access" means editing authorized_keys on the box by hand. CapRover runs on a single shared password for the whole dashboard. Neither has teams, roles, an audit trail, or any notion of an identity provider. For a side project or a three-person team, that is a feature — zero administrative surface. For a team with a joiner/mover/leaver process, it is a non-starter, and no configuration changes that.
What "No" costs: the gap, the rejection, and the bill
The title of this post promises a cost, so here it is as a concrete mapping. Each row starts from the tool's gap, states the auditor's objection in the language auditors use, and ends with what the team actually pays.
| Tool gap | Auditor's objection | What the team pays |
|---|---|---|
| No SAML/OIDC against the corporate IdP | "Show me IdP-integration evidence forOperator access" — a SOC 2 Type 2 auditor expects continuous SSO/MFA logs, not a list of static passwords and social logins | Blocked adoption, or a formal exception the CISO has to sign and re-justify every audit cycle |
| No SCIM / lifecycle provisioning | "Prove a terminated employee loses access within 24 hours" | Manual deprovisioning checklists, screenshots-as-evidence, and the residual risk of a forgotten key surviving a departure |
| Coarse or missing RBAC | "Demonstrate least privilege on production deploys" | Everyone is effectively admin (Dokku, CapRover) or "member" means more than it should (Dokploy's CVE); the access review becomes fiction |
| No audit trail on deploys and rollbacks | "Who shipped this change, who approved it, and can the log be tampered with?" | Change-management evidence assembled by hand from git history and chat logs — if it can be assembled at all |
| Unsigned platform events | "How do you know this deployment record is authentic?" | Downstream compliance automation cannot trust the platform's own events, so the trail stops at the platform boundary |
Two clarifications matter here. First, "login with GitHub" is not SSO in the sense auditors mean. It is federated convenience login: your company cannot enforce its MFA policy through it, cannot see the session in its IdP logs, and cannot revoke it from the IdP when someone leaves. Real SSO means the identity provider is the system of record for who works here, and the platform defers to it. Second, the cost is not just the failed review — it is the team that quietly routes around it. Engineers who cannot get the self-hosted tool approved do not stop deploying; they deploy on the managed cloud with a personal credit card, and governance gets less visibility than if the compliant self-hosted option had existed.
What the managed side proves is table stakes
The other half of the split is that governance is exactly what the managed platforms charge for — which tells you what the market thinks it is worth.
Replit gates SSO/SAML, single-tenant environments, and audit controls at its Enterprise tier; below that, a business team gets a fast prototyping tool and nothing an auditor accepts. Lovable follows the same shape, with SSO and SAML arriving on its custom Enterprise tier. Retool and Superblocks both ship SSO/SAML/SCIM plus audit logging, and Superblocks' own comparison framing puts governance — RBAC, SSO integration, audit logging, secret-manager integration — first among its advantages. Retool's docs walk through SAML and OIDC configuration against Okta, Google, and ADFS as a standard deployment step, not an exotic add-on.
Notice the pattern: nobody's Enterprise tier leads with "more templates" or "faster builds." The priced moat is identity, audit, and isolation. The managed vendors learned that the buyer who pays real money is not the developer who loves the deploy UX — it is the organization that needs to answer "who touched production" without a forensics project. The self-hosted four compete furiously on the developer's criteria and cede the buyer's criteria by default.
The counterexample: self-hosted with governance
The gap is closable without surrendering the box, and the proof is appCrane, a self-hosted, agent-first deploy platform whose README carries an explicit comparison table against Coolify and Dokploy — with an "Enterprise SSO (SAML/OIDC/SCIM)" row the incumbents cannot match.
What appCrane actually ships reads like a direct response to the cost table above. SSO-only login mode hides password and API-key authentication once an identity provider is configured, with a lockout guard so admins cannot strand themselves. A configurable role matrix gates capabilities like app creation and production deploys instead of hardcoding admin-versus-everyone. Promote and rollback are restricted to the app owner or a global admin, production is promoted from the exact tested sandbox commit with health checks and auto-revert, and the audit trail is per-user — distinguishing agent actions from human ones, which matters enormously now that deploy operations arrive over MCP from Claude Code, Cursor, and their cousins. The project even closed the exact class of hole Dokploy's CVE represents: an MCP deploy path that skipped the production gate was shut in a subsequent release.
You do not have to adopt appCrane to learn from it. The lesson is architectural: governance is not a coat of paint applied after the deploy flow works. SSO-only mode, a permission matrix, gated promotions, and agent-aware audit are load-bearing design decisions — they have to shape the API, the MCP tools, and the deploy lifecycle from the start, because every unauthenticated-or-unauthorized path (a WebSocket terminal, an MCP tool, an unsigned webhook) is a hole in the story the auditor hears.
The build checklist for a Cluster-API PaaS
For a self-hosted platform that wants compliance-bound teams as customers — the bet Bex.co is making with a Cluster-API-based PaaS on machines you own — the TODO spec names the non-negotiables, and each maps to one auditor question:
- SSO-backed operator identity (SAML/OIDC, with SSO-only enforcement). Answers: "who accessed the platform, authenticated by whom?" Social OAuth can stay as an onboarding path, but the enterprise story requires deferring to the customer's IdP — including its MFA policy and session lifetimes — and an SSO-only mode so the IdP cannot be bypassed.
- An audit trail on every deploy and rollback. Answers: "who shipped what, when, and who approved it?" Every mutation — deploy, rollback, env change, scale event, permission change — needs an actor, a timestamp, and tamper-evidence. Agent-initiated actions must be attributed to the agent and the human who authorized the session.
- Approval gates agents cannot skip. Answers: "how do you prevent unauthorized production changes?" As agents operate the platform over MCP, every tool path needs the same permission checks as the dashboard. The Dokploy CVE pattern — a secondary interface (WebSocket, MCP, API) that authenticates but never authorizes — is the failure mode to design against from day one.
- Lifecycle provisioning (SCIM) and least-privilege roles. Answers: "how fast does a departure revoke access, and who can touch production?" Joiner/mover/leaver must flow from the IdP automatically, and production deploy rights must be a grantable role, not a side effect of having an account.
- Signed, verifiable platform events. Answers: "can we trust the deployment record?" Webhooks and event streams need HMAC signatures and delivery identity so compliance automation downstream can treat platform events as evidence.
None of these is exotic technology. SAML, OIDC, SCIM, and append-only audit logs are solved problems with mature libraries. What makes them rare in self-hosted PaaS is sequencing: every one of them is cheapest on day one and most expensive as a retrofit, and the incumbents sequenced templates first.
Governance is the moat
The 2026 deploy-platform market has sorted itself into two unsatisfying options: managed clouds with real governance on infrastructure you do not own, and self-hosted tools on infrastructure you own with governance your auditor will not accept. The first vendor to hold both halves — your machines, their audit story — does not win on features. It wins every evaluation that reaches the security review, because it is the only tool still standing in the room.
Template counts never closed an enterprise deal. SSO, audit trails, and approval gates do. The self-hosted PaaS that learns that lesson first owns the compliance-bound half of the market unopposed.
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.
