Coolify, Dokploy, Rancher: the deploy controller is the keys to every app you run

There's a hierarchy of exposed panels, and at the top sits the thing that controls the other things. A leaked CMS admin owns one site's content. A leaked database console owns one app's data. A leaked deploy controller owns everything: every app on the box, the environment variables and secrets injected into each one, the build pipelines, and usually a container shell. Coolify and Dokploy are self-hosted Platform-as-a-Service controllers, the open-source Heroku you run yourself. Rancher manages whole Kubernetes clusters. Compromise one of these and you don't breach an app; you become the operator.

That's why these are the panels you least want answering an anonymous request, and why the scanner rates them high. The blast radius isn't one system. It's the platform.

Three controllers, one catastrophic shape

Different tools, same exposure: the control plane for your infrastructure, reachable without auth.

• Coolify - a self-hosted PaaS. From its dashboard you deploy and manage every application and database on the server, and crucially you read and edit the environment variables and secrets injected into each one. A logged-in attacker reads your every credential and can deploy arbitrary code. The scanner identifies it by the Coolify title plus its Livewire and theme markers.
• Dokploy - a newer self-hosted PaaS in the same category. Same powers: apps, databases, env, deploys, all from one panel.
• Rancher - Kubernetes cluster management. Not one host but a whole cluster: workloads, secrets, and the ability to schedule containers across nodes. The scanner anchors on Rancher's distinctive loading markup (the Ember wormhole div) so a generic loading page doesn't trip it.

The common thread is that "logged in" here means "operator." These tools exist to let you deploy code and read secrets, so an attacker who gets in inherits exactly those abilities, against every app the controller manages.

Why an exposed controller is the worst-case panel

Walk the chain. A reachable controller login invites credential-stuffing and brute force like any panel, but the payoff is total: env vars and secrets for all apps (so every downstream service, database, and API the platform manages falls at once), plus the ability to deploy, which is arbitrary code execution by design, plus, on most of these, a container shell or exec into running workloads. There's no lateral-movement puzzle to solve afterward; the controller already has the access an attacker would otherwise have to fight for. And these get exposed the same lazy way everything else does, stood up on a public host "to manage things remotely," with the admin on a quick password, and never walled off.

These should never face the open internet

A deploy controller is the definition of an operator-only tool. The fix is to make it unreachable from the public internet, full stop, and only then worry about the login.

# the deploy controller answers deploy.yoursite.com
# anyone on the internet reaches the login

Put the controller on an internal network or VPN and reach it through an SSH tunnel; the public should only ever touch the applications it deploys, never the controller itself. If remote access is unavoidable, lock it to your team's IPs at a reverse proxy. Behind that wall, use a strong unique admin password and two-factor, and keep the controller patched, these tools accumulate critical CVEs precisely because they're high-value, and an exposed-and-outdated controller is the single worst thing on this whole site.

Reading it from outside

Whether your deploy controller answers the public internet is something a stranger settles by loading its URL, which is exactly what SurfaceCheckr does, from outside, no credentials. Each probe requires the product's own distinctive markup to match, so it confirms the real controller and doesn't fire on an unrelated loading page or login. It reads only what the panel serves anonymously and stops, no login attempt, no deploy, nothing active. The reason this check earns its place: of everything a passive scan can find, an exposed control plane has the largest blast radius, one login from owning the platform, and it's exactly the kind of thing you only notice by checking from the outside, the way an attacker would. The closest cousins are the Kubernetes dashboard and infra consoles in the same situation, and the broader lesson in what an MVP leaves exposed when you ship fast.