Skip to content

Allow binding published ports to 127.0.0.1 only (loopback), not just 0.0.0.0 #4715

Description

@stopalovic1

What problem will this feature address?

When publishing a port for a service (e.g. Postgres on 5432), Dokploy always binds it to 0.0.0.0 (or the server's public IP), so the port is reachable from the internet. There's no way to publish it as loopback-only (127.0.0.1:5432:5432), which is the standard way to allow host-local access (e.g. via an SSH tunnel) while keeping the port closed to the network.
Currently the only workarounds are:

  • Managing an external firewall (extra moving parts, easy to misconfigure or forget)
  • Manually editing the Swarm service after deploy (gets reverted on redeploy)
  • Not publishing the port at all and relying only on container-to-container access — which breaks host-side tooling (psql, GUI clients, SSH-tunneled debugging, etc.)

Describe the solution you'd like

Add a "Bind to localhost only" toggle (or a host-IP field, blank = current behavior) next to the Published Port setting for applications/databases. When enabled, Dokploy should publish the port as 127.0.0.1:: instead of 0.0.0.0::, so:

  • The port remains reachable from the host itself (e.g. via SSH tunnel)
  • It is not reachable from the LAN or public internet
  • Container-to-container access via service name is unaffected (this already bypasses host port publishing entirely)

Describe alternatives you've considered

  • External firewall rules (UFW/cloud security groups) — works but is an extra layer to keep in sync with Dokploy's own config, and it's easy to forget after redeploys
  • VPN/Tailscale for the whole box — solves it but is heavier than needed for just DB access
  • Manual docker service update — not idempotent, gets clobbered on the next deploy from Dokploy

Additional context

Related to #2915, which requests binding to an arbitrary host IP (e.g. a VPN interface). This request is the simpler subset of that — just loopback-only — which covers the common "I want to psql/tunnel in for debugging but never expose this to the internet" case, and might be easier to ship first since it doesn't require IP auto-detection across interfaces.

Will you send a PR to implement it?

No

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions