Coolify Shipped an Audit Log. It Still Wouldn't Survive a SOC 2 Review.

Coolify's v4.1.0 release added something no self-hosted PaaS had shipped as a first-class feature before: structured audit logging for API mutations, webhook events, and authentication failures, written as daily-rotated, 90-day-retained JSON. It shipped in the same release as an instance-level MCP server and a Railpack buildpack beta, but the audit log is the one that matters for a different reason — it's the first signal from the leading self-hosted PaaS that "can a compliance team actually approve this" is now a design requirement, not an afterthought bolted on when an enterprise deal demands it.

Here's the part that doesn't show up in the changelog: what the log actually covers, read against what a SOC 2 auditor actually checks for, leaves four specific gaps — and at least one of them gets worse, not better, the moment the caller making deploy requests is an AI agent instead of a human clicking a button.

What v4.1's Audit Log Actually Captures​

The implementation, in PR #9842, instruments a specific set of write paths across the API:

• API mutations — create, update, delete, deploy, start, stop, and restart calls across applications, services, databases, servers, projects, environments, scheduled tasks, private keys, GitHub apps, cloud provider tokens, and Hetzner provisioning.
• Webhook events — signature verification outcomes for GitHub, GitLab, Bitbucket, Gitea, and Stripe, plus the Sentinel push endpoint.
• Auth/authz failures — unauthenticated requests, ability mismatches, and policy denials, captured at single chokepoints in the ApiAbility middleware and exception handler.

Each entry carries request metadata — IP, user agent, user/team/token ID, HTTP method, path — but deliberately skips request-body inspection, so a payload containing a secret never ends up copied into the log by accident. Retention defaults to 90 days via a dedicated audit log channel, tunable with LOG_AUDIT_DAYS; verbosity defaults to info for successful mutations and warning for denied or suspicious requests.

That's a real, useful log — and it's a competitive first. Neither Dokploy nor CapRover, the two other self-hosted PaaS projects most often named in the same breath as Coolify, ships anything comparable: both log deployment status for their own operational purposes, but neither writes a structured, retained, queryable record of API mutations and auth events the way Coolify's audit channel now does. For a team evaluating self-hosted options against a compliance checklist, that gap alone moves Coolify to the front of the list.

But it's also a log built around one specific event shape — an authenticated API call that changes state — and everything outside that shape is where the gaps start.

The Four Things It Doesn't Log​

Read Coolify's own implementation notes closely and four omissions are explicit, not accidental:

1. UI-triggered actions aren't instrumented. Only the API and webhook paths get audit entries. A deploy, restart, or environment-variable change made by clicking through the dashboard — which is how most Coolify users operate day to day — produces no audit record at all, only the API-driven equivalent does.
2. Terminal and SSH access is out of scope. Coolify ships a browser-based terminal into running containers and the host. None of that session activity — connection, commands run, disconnection — is written to the audit channel.
3. Secrets access isn't tracked. The log records that an environment-variable mutation happened (create/update/delete), but reading a secret's value — which is the action that actually matters for a credential-exposure investigation — isn't a logged event at all, and the body-inspection skip means even mutation payloads aren't recoverable from the log itself.
4. Successful authentication isn't logged, only failures. You get a record when someone fails to log in or gets denied by policy. You get no record of who successfully authenticated, when, from where — the baseline session log an auditor asks for first.

None of these are bugs. They're reasonable scoping calls for a v1 of a feature that didn't exist in Coolify at all before May 2026. But "reasonable scoping call for v1" and "sufficient for a SOC 2 review" are different bars, and the gap between them is exactly what a compliance-minded team hits the moment they go looking.

Why the Gap Fails a Real Compliance Review​

SOC 2's system-monitoring criteria (CC7.1–CC7.2) expect an auditor to be able to reconstruct who did what, when, and from where for every privileged action — not just the subset of privileged actions that happen to arrive over one specific interface. Three of Coolify's four gaps map directly onto that expectation:

• The UI blind spot breaks the "every deploy" requirement outright. Deploy and rollback events are exactly the kind of change-management action SOC 2 auditors ask for first, and for most Coolify installs, most deploys are triggered from the dashboard, not the API. A log that only catches the API-driven minority of deploys doesn't satisfy "every deployment," it satisfies "every deployment that happened to go through this one code path."
• No secrets-access logging fails the credential-exposure test. When an auditor — or an incident responder — asks "who read this database password in the 30 days before it turned up in a breach," a mutation-only log has no answer. Secrets are the asset that credential-exposure controls exist to protect, and they're the one category the current log can't speak to at all.
• 90-day retention is short for the norm auditors actually apply. SOC 2 evidence windows commonly expect security-relevant logs retained on the order of 12 months, with 90 days as the hot-storage tier for active investigation, not the full record. Coolify's default is tunable, so this one is fixable by an operator flipping LOG_AUDIT_DAYS and shipping logs to external storage — but it's a gap the platform leaves for the operator to notice and close, not one it closes by default.

The terminal/SSH gap is a different kind of problem — not a coverage hole in the same log, but a missing log entirely. A debug shell into a running production container is one of the highest-privilege actions a PaaS exposes, and it currently produces zero audit trail on Coolify. Session-level recording (what was typed, not just that a session opened) is table stakes for privileged-access tooling built for exactly this purpose — SSH bastions and PAM tools solve it with command-level capture tied to identity — and it's the piece missing entirely, not incompletely covered, from a general-purpose PaaS's compliance story.

The Checklist a Self-Hosted PaaS Needs Before It Can Say "Audit-Ready"​

Put together, here's the concrete bar — the one Coolify's v4.1.0 gets partway to, and the one bex's own control plane has to clear before "compliance-ready" is a claim rather than a hope:

• Every deploy and rollback logged regardless of trigger — dashboard click, API call, webhook, or agent tool call all write to the same audit trail with the same fields. No code path is exempt because it wasn't the one instrumented first.
• Secrets access logged as a read event, not just a mutation event. Who fetched which secret's value, when, matters as much as who changed it — arguably more, for a credential-exposure investigation.
• Debug-shell and SSH sessions produce a session-level record — connection, identity, and command history, not just "a terminal was opened."
• Successful authentication is logged alongside failures, so "who was logged in during this window" is answerable without inference from an absence of denial records.
• Retention defaults to what auditors actually ask for (12 months, or an out-of-the-box path to ship logs to external, longer-retention storage) instead of a short default an operator has to know to extend.
• Every entry ties back to an accountable identity, not just a token ID — a distinction that matters more, not less, once the caller isn't always a human.

Why This Gets Sharper for an Agent-First Platform​

That last item is the one worth sitting with. bex's whole pitch is that an AI agent is a first-class caller of the deploy API — the same MCP surface a human uses to push a git repo is the one an agent uses to deploy, roll back, or read logs on its own initiative. That means every gap in this checklist gets exercised by a caller that doesn't stop to ask permission the way a human hesitates before clicking "deploy to production." An agent that can read environment variables, restart services, and open a debug shell — all in the course of routine operation, not an edge case — is precisely the caller a secrets-access log and a session-recorded shell exist to hold accountable. Shipping an audit log that only catches the API-mutation slice of that surface would mean the platform's most distinctive feature is also its least-audited one. Closing this checklist isn't optional groundwork before an enterprise sale — it's the same infrastructure that makes "an agent can safely operate your production deploys" a claim worth trusting in the first place.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with a deploy API built for AI agents and humans alike as first-class callers. Star the repo on GitHub or deploy your first app today.

Sources​

• Coolify v4.1.0 release.
• PR #9842 — structured audit log channel for API and webhook events.
• PR #9841 — v4.1.0 aggregate changes.
• Coolify changelog.
• SOC 2 Audit Log Requirements: Lessons From Our Own Audit — Bytebase.
• SOC 2 Compliance for Deployment Workflows: What Auditors Look For — DeployHQ.
• The Ultimate Guide to SOC 2 Audit Logs for Tech Teams — Maruti Techlabs.