Problem: Easypanel-Managed Services Cannot Access Host-Accessible Private Subnets

In a Docker Swarm environment, services deployed by Easypanel are attached to overlay networks (e.g. easypanel-alonso-apps). Overlay networks, by design, are isolated from the host’s underlying network interfaces and routing table. As a result, these services cannot reach private subnets that the host machine has access to (e.g. 10.2.5.0/24, where an internal SQL Server may reside).

Even though the Docker host itself can reach these private resources, containers within overlay networks cannot unless they are granted some form of access to the host network. This limitation is fundamental to Docker Swarm’s overlay architecture and is not specific to Easypanel.

Workaround: Deploying a Global Port-Forward Proxy

To bridge this gap, users must manually deploy a “forwarding” service using socat or similar tooling. This service:

• Runs in deploy_mode: global to ensure it exists on every node

• Publishes the relevant port in mode: host so that it can bind to the real host network

• Is connected to a user-created overlay network (e.g. fwd-host)

• Forwards traffic from a stable service name (e.g. db-proxy:1433) to a host-accessible private subnet (e.g. 10.2.5.1:1433)

Then, Easypanel-managed services must also be manually attached to that overlay (fwd-host) to access the proxy. How I accomplished this: A python script that runs on a cron every 3 seconds checks for easypanel services and attaches services to this network (very awkward)

This pattern is stable, but it introduces a multi-step manual deployment and orchestration process, which can be difficult to automate cleanly inside the Easypanel deployment lifecycle.

Feature Request

It would be valuable if Easypanel supported the ability to:

1. Attach services to additional user-defined overlay networks, such as fwd-host, during deployment.

2. Optionally deploy a host-networked global forwarding service as part of the stack configuration (or expose a plug-in point for it).

3. Provide documentation or native support for common access patterns to private infrastructure (such as databases on VPN interfaces, internal subnets, etc.).

Why It Matters

This limitation blocks access to internal infrastructure that cannot be publicly exposed and is only available from inside the Docker host or its associated network interfaces. Supporting this natively would allow Easypanel users to interact with internal services (e.g., database clusters, private APIs) in a secure, Swarm-compliant, and manageable way without introducing out-of-band infrastructure.