can we fix port conflicts?

[cyberhck]

One way to solve would be not to expose ports from individual apps, but rather have a proxy which listens on any subdomain: *.umbrel.local, and the proxy forwards to the service internally reducing the need for port forwarding. Also gives more control to umbrel itself.

[cyberhck]

I'm just thinking it aloud, does anyone think it's a good idea? Or maybe there's something wrong with above (not saying we should do it, just curious)

[PlebeiusGaragicus]

I was also wondering the same - that if the ports are not managed there will be countless conflicts as more apps are written. As I'm writing my app I'm wondering which port number to choose and knew that I'd have to cross reference every other app in order to ensure that number wasn't already taken and then cross my fingers that a future app won't use that same number.

[mayankchhabra]

It's a good point, the main issue is some systems do not support *.local name resolution. Plus, people also run Umbrel on VPS sometimes. In both those instances, they end up accessing their Umbrel and apps on it via an IP address, which is why we use ports.

On idea is that in the future, we can abstract pre-defining of port numbers at packaging time, and instead assign them on install-time based upon which ports are available.

[cyberhck]

I meant, you have a umbrell-proxy container. Then internally they route using either a path or something.

I could try getting a mvp proxy in a few hours if you're interested. Either by path or subdomain. Maybe path is better :)

[lukechilds]

There are a few different issues with this approach. It won't work for clients that can't access via domain names, some clients don't support mDNS so need to access locally via IP. Additionally, many apps will break when being served from a path that isn't the root. e.g they expect linking to / will resolve to their root, when actually it'll resolve to Umbrel's dashboard. Also, host and paths are HTTP specific, so proxying doesn't solve the issue for any non-HTTP port collisions.

The proxy solution will only fix the problem for HTTP services when accessed from mDNS enabled clients. All other scenarios will still be broken. The best approach we've thought of so far is to assign ports dynamically at runtime based on what's available, this will work for all clients, regardless of accessing via domain name or IP and all services, regardless of if they are HTTP or non-HTTP traffic.

[cyberhck]

the path issue I already thought of and I can fix that from proxy. I think we could create non http proxy as well maybe? what percentage of current apps have non http? We give this as an option to easy people's lives as well :)

The path issue we can tackle from the proxy itself.