• 0 Posts
  • 5 Comments
Joined 1 year ago
cake
Cake day: September 1st, 2025

help-circle

  • You can use the per-user reverse proxies as a bridge between the host network and the user-specific internal network. So for a user coming from outside the path looks like this:

    User -> main reverse proxy on main IP and port 80/443 -> user-specific proxy listening on main IP with port 8080 and proxying to user-specific internal network -> destination container listening on user-specific internal network.

    And for a container running as a different user the path will be the same, but the user-specific reverse proxy will be listening on port 8081 and higher for example.


  • The solution to this can be multiple reverse proxies. Each user runs it’s own reverse proxy (if you actually need one, otherwise you let the container bind directly to a port on the host system). Then you run one main reverse proxy on port 80/443 that proxies to those other ports based on hostname.

    The upside of this construction is that containers running as different users can’t directly access each others internal networks, which is much better for security, as those networks often contain barely protected services, which is why you’re using a reverse proxy in the first place.

    Edit: there are different options with custom networks and such, but they’re even more complicated so I wouldn’t advise them.