Add managed, restricted Docker API access for Traefik without exposing container secrets

I’m running self-hosted Dokploy v0.30.6 and would like to propose a safer way for Traefik to access Docker while keeping automatic domain routing.

Traefik currently mounts /var/run/docker.sock directly. If Traefik is compromised, an attacker could use that socket to control Docker and potentially the host.

A restricted socket proxy helps, but read-only access still exposes sensitive information. Container inspection and Swarm service/task responses can include environment variables containing database passwords or API keys. Allowing entire groups of GET endpoints can also expose container files or logs.

Proposed solution

Add an optional Docker API proxy managed by Dokploy that filters both requests and responses:

• Allow only the API operations required by Traefik’s Docker and Swarm providers.
• Reject mutations, exec, filesystem downloads, logs, and unrelated endpoints.
• Return only the discovery fields Traefik needs, such as identifiers, routing labels, network addresses, ports, and health information.
• Omit environment variables and other unnecessary sensitive metadata.
• Run on a private network with no published host port, and remove Traefik’s direct socket mount.

Traefik’s Docker, Swarm, and file providers would remain enabled. Compose domains would still use label discovery, and Application domains would continue using generated configuration files. Dokploy itself would retain the Docker access it needs to manage deployments.

Response filtering needs validation against Traefik’s actual API usage. Sensitive values can also appear in labels, including authentication configuration, so we would need to document which information Traefik must receive and avoid claiming that every secret can be removed.

Preserve protection when recreating Traefik

The Traefik setup code hardcodes the raw socket mount. Manually replacing it does not survive recreation through that code.

When this option is enabled, Dokploy should preserve the proxy endpoint, mount restrictions, and private network through Traefik recreation and upgrades, including port or environment changes. Existing isolated project networks should also be reconnected.

Validation

Before enabling this for production, I’d expect tests covering:

• Application domains, HTTPS, and file configuration reloads.
• Compose and Swarm stack domains discovered through labels.
• Redeployments, scaling, and isolated project networks.
• Traefik restarts, recreation, and upgrades.
• Rejection of forbidden requests.
• Absence of environment secrets from every allowed discovery response.

I have request filtering working locally with Docker and Swarm discovery. Response filtering and the full compatibility checks above have not been implemented.

Would you be open to this approach? I’d like to agree on the proxy implementation and compatibility requirements before contributing a PR.

Start with packages/server/src/setup/traefik-setup.ts, where the raw Docker socket mount is hardcoded, then document Traefik’s actual Docker and Swarm API usage needed for discovery. Define the optional proxy’s request and response filtering and validate it against the listed application, Compose, Swarm, recreation, upgrade, and forbidden-request cases. Done means Traefik retains routing while allowed responses omit environment secrets and protection survives recreation.