Multiple ports with public URL? exposes port 80 with a static public URL:

I have services which use multiple ports. For example, a simple static web app served on port 80 which communicates to an API over another port.

How can I accomplish this with

Hi, that’s currently not possible though the Public URL to expose more than one ports.

In your particular case, I’d probably assemble your app such, that both the web app and the API are on the same port, but the API is namespaced with e.g. an /api/ path. Many setups do this readily (e.g. Python/Flask apps that I’ve used combined dynamic APIs and static web apps readily). This of course works easier if the whole app is the same framework. If not, then might need a server in front of the status app and the API to do the redirects (caddy or nginx, for example).

1 Like

Thank you for your prompt reply!

This is unfortunate. Using the same port with nginx routing requests to different namespaces (e.g. /api/ path) is a good idea. However, in some cases I do not have control over this. For example, the Deluge BitTorrent server uses a port for the web app, and separate ports for the APIs: I do not think I have control to configure the clients to send requests to :80/api/ and instead only can change the port number.

Is this a feature planned in the future, or something does not expect to support?

As I’ve quickly tried deluge-web, I think it’s connecting to the server through the localhost. So I’m guessing in this particular case you don’t actually need to expose any other port, but move the default deluge-web port from 8112 to 80. Might be wrong about it, but the web interface didn’t seem to connect to any other port. Might worth a bit more checking out. :mag:

It is not currently planned, but will be discussing this possibility!

Yup, I have deluge-web port serving on 80. However, deluge itself uses other ports for connecting with the a “thin client” remotely, such as the “daemon_port”:

So far deluge-web has been great and works flawlessly – it’s API is over port 80 as well using an endpoint /json. The thin clients are the only feature I lack when I am away from home.

Thanks for looking into it! Hopefully something team can consider :slight_smile:.

1 Like

Ah, so if I understand now, you are using both deluge-web and the thin clients, that’s why you need two ports accessible? deluge-web uses that port too, but it can do it within the localhost, so wouldn’t need any extra ports.

Yeah, will keep you posted if there’s any development regarding this feature.

Is this still actively being discussed? I could really use multiple ports exposed publicly as well.

Hi @aafrey at the moment this is not actively discussed, but I’ll add a +1 from you in our internal feature tracker for this item. I’ll also link this thread with the feature, so once we implement this, we can notify you in this thread.

1 Like

@afitzek appreciate the reply. i could also make due with more flexibility in URL structuring :slight_smile: been playing with a reverse proxy setup with multicontainer deployments, but using subdomains would provide more flexibility than just routing on paths. it looks like the device ID is used as an initial subdomain, but can it be broken down further i.e. foo.<device id> i think having that would solve all my use cases.

@aafrey Cool, I’ll add this suggestion to our feature tracke. I’ll note it like this, start forwarding basically all subdomains to the devices. So *.<device id> would be forwarded to the device, in which case you can use a reverse proxy to route to all other containers and expose multiple services.

1 Like

:metal: appreciate it!

also have the same request:
im my case: Grafana on Port 3000, Node-Red on 1880, and a Webserver entry point on 80.

Hi @echteler, currently its not possible, but we are hoping to enable this kind of thing later this year. For now the way to do it would be to use something like HAproxy (as done in ) to route traffic to specific container ports via the public URL.

1 Like

Thanks for the info. looking forward to the new feature :slight_smile:
i managed in the meantime to do it via nginx reverse proxy :slight_smile: