This would require the main proxy running as root or with some other sort of elevated privileges to allow cross-user network access though, right? If so, wouldn’t that essentially make the user-specific reverse proxy unnecessary in most cases?

I think this is what OP was originally trying, but this approach breaks when each service’s Podman service runs on its own localhost user.

I didn’t see the logs when I originally posted. However, I’m not sure what the logs indicate. It could be that nginx successfully received the request and received an authorization error from Podman’s networking stack then returned a 503 error to the client (or logged the 503 response that was returned to nginx).

I’m not trying to convince you of this solution (I personally don’t like it), but I am curious what didn’t work for you. Were you unable to get the reverse proxy to serve each service? Were you unable to have the services behind the reverse proxy to talk to each other?

This is due to a security design deicison of Podman. Each user’s network(s) is only available to that user. This is great for most services, but can cause issues for some services - especially reverse proxies. Unfortunately, I’m not aware of an ideal solution. The only solution I’ve seen is moving the reverse proxy to another host and exposing the services’ ports on the localhost. I hope someone can provide a better solution!

I generally agree with this. Unless OpenAI has a track record of being poor stewards of open source projects, then right now the concern is mostly FUD.

However, this is a bit aggressive. It is appropriate to be skeptical about the intent of a controversial company acquiring another company that made a few popular open source projects or of the future state of those open source projects.

Just because a popular open source project is well liked today doesn’t mean the community will be happy with the project in the future or even that the project will forever remain open source. Some notable recent examples include Redis, Terraform, and CentOS.