Dokploy's large title-and-body count needs a permission boundary review
Dokploy is a self-hosted deployment platform that manages applications, databases, servers, domains, certificates, and environment variables. Exposing its login page is therefore more consequential than exposing a read-only dashboard. The control plane can change what runs in production and which infrastructure credentials are available to a deployment.
On November 2, 2026, a ZoomEye SDK count-only probe returned 0 matches for app="Dokploy" and 55,075 for title="Dokploy" using sub_type=all, page 1, and page size 1. A body query returned 55,514, and the combined title="Dokploy" && http.body="Dokploy" query returned 54,819. The large result is not automatically a deployment count. It shows that separate title and body matching do not provide a verified application fingerprint.
The documentation describes Owner, Admin, and Member roles. It also exposes permissions for projects, environments, services, Git providers, servers, Docker, Traefik files, SSH keys, and API/CLI access. An access token is generated from a user's profile, and the API exposes permission assignment and user administration. A token with broad API access can reach the same control plane as the web session.
The review should not begin with the ZoomEye count. It should begin with the users who can reach the instance. Enumerate owners and admins, then inspect each user's project and environment scope. Check whether members can create services, delete environments, access Docker, read Traefik files, or use SSH keys. Confirm whether API access is enabled for users who do not need it.
Tokens need their own lifecycle. Identify the owner, creation time, scope, storage location, and revocation path. A token stored in a CI system may be readable by every job in a repository. A token in a shell history or deployment script may outlive the project it was created for. Revoking the user session alone does not necessarily revoke an API token.
The deployment path has additional high-value objects. Git provider credentials can pull private source. SSH keys can reach remote servers. Environment variables can contain database passwords and third-party API keys. Database services can expose management ports. The permission model should show whether a user can read a secret without the ability to deploy it, and whether the same role can do both.
Test with a member account. Attempt to access a project outside its scope, send an API request with the member token, and try to read a server or Git provider that the role should not see. Verify the negative results through both the UI and API. If the two paths disagree, the API is an alternate control plane and needs explicit coverage.
The 54,819 title-and-body matches are a broad discovery signal, not evidence that all matched pages are Dokploy installations. Their value is in prioritizing broad crawling and ownership checks. The security decision comes from user roles, tokens, secrets, and the deployment actions those objects can perform.
Query evidence
app="Dokploy" returned 0 matches, title="Dokploy" returned 55,075, http.body="Dokploy" returned 55,514, and title="Dokploy" && http.body="Dokploy" returned 54,819. All queries used sub_type=all, page 1, and a page size of 1.
Top comments (0)