Support multiple protocol and port mappings for a single proxy domain

[NeoPxl]

Before posting

• I searched existing discussions and issues for similar requests.
• I checked the documentation to confirm this is not already supported.
• This is a product idea or enhancement request, not a support question.
• I removed or anonymized sensitive details from examples and screenshots.

Product area

Management service / API

Problem or use case

Currently, when creating a Proxy Resource in Netbird, the domain name is used as a unique identifier. This enforces a strict 1:1 mapping between a domain, a single protocol (e.g., HTTPS), and a single target port.

It would be extremely powerful if we could define multiple port and protocol mappings (e.g., HTTPS, TCP, UDP) under the same proxy domain.

Use Case: Git Self-Hosting (Forgejo / Gitea)

When self-hosting a Git service inside an isolated Docker network behind Netbird, we typically want to expose two services under the same domain (e.g., git.company.net):

1. HTTPS (Port 443): For accessing the web interface and API.
2. TCP (Port 22): For Git SSH clones and deployment keys.

Currently, we are forced to create two separate domains (e.g., git.company.net for Web and git-ssh.company.net for SSH) because Netbird does not allow us to bind both HTTPS (Port 443) and TCP (Port 22) to the same proxy domain resource.

Proposed solution

In the Netbird Admin UI, instead of selecting one protocol and target port per resource, we should be able to define a list of "Service Mappings" for a single domain.

For example, when creating the resource git.company.net, we could add:

• Mapping 1: Protocol: HTTPS | Source Port: 443 | Target IP/Port: 172.22.0.10:3000
• Mapping 2: Protocol: TCP | Source Port: 22 | Target IP/Port: 172.22.0.10:22

Since Netbird uses Traefik under the hood, Traefik can easily multiplex these incoming connections on different entrypoints (ports) for the same domain name.

Alternatives or workarounds considered

1. Creating multiple subdomains (e.g., git-ssh.domain.com and git.domain.com). This works, but adds DNS/SSL overhead and is less intuitive for developers who expect SSH and HTTPS on the same domain.
2. Routing the whole subnet. This bypasses the security benefits of isolated container-proxying and opens up ports on the host.

Community impact and priority

Number of users/teams/peers affected: Hundreds of self-hosters, DevOps teams, and companies running multi-protocol services (like Git, SFTP, custom APIs, or database replicas) inside Netbird overlays.

Deployment type: Both (Cloud and Self-hosted)

Frequency: Daily (Git clones, pushes, automated CI/CD pipelines, webhook triggers, and web GUI interactions).

Blocking production adoption? No, but it significantly degrades user experience (UX) and forces administrators to manage multiple, redundant subdomains for the exact same physical service.

Examples from other tools or products

Cloudflare Tunnels (cloudflared): Cloudflare allows mapping multiple protocols/ports under a single public hostname using ingress rules. You can route HTTP/HTTPS traffic to a web server port and TCP traffic (like SSH) to port 22 on the same domain.

Traditional Reverse Proxies (Traefik / Nginx / Caddy): These proxies natively allow binding different protocol handlers (HTTP Routers vs. TCP Routers) to the same domain name, multiplexing the traffic purely based on the incoming entrypoint/port (e.g., port 443 vs. port 22).

Security, privacy, and compatibility considerations

Granular ACLs: Netbird’s core value is Zero-Trust. Therefore, the implementation should allow applying ACLs per service/port mapping if possible. For example, a developer might be allowed to access HTTPS (web UI) on git.company.com, but only administrators/pipelines should have access to TCP/22 (SSH) on the same domain. If port-level ACLs are too complex for a first iteration, falling back to resource-level (domain-level) ACLs would still be highly acceptable.

Backward Compatibility: The existing schema (where a resource has a single 1:1 mapping of protocol and port) can easily be migrated by treating the old config as a single-item list under the hood. There should be no breaking changes for current user setups.

Implementation ideas

API / Database Schema: Transition the Proxy Resource model from a flat structure to a 1:n relationship. Instead of having single fields for Type, Port, and TargetPort on the resource, introduce a Mappings array:

"mappings": [
  { "protocol": "https", "source_port": 443, "target": "172.22.0.10:3000" },
  { "protocol": "tcp", "source_port": 22, "target": "172.22.0.10:22" }
]

Agent Proxy Configuration (Traefik): The Netbird local agent, which dynamically configures the local proxy daemon, should generate Traefik routers/services for each defined port mapping under the same virtual domain name.

Are you willing to help?

Yes, I can test or validate a proposed implementation.

Additional context

No response