If you’re worried about that possibility, then you should mitigate against it. I’m not saying everybody should do it… all I’m saying is that rejecting the idea out of hand is not necessary.

I don’t feel like I’m risking anything… I feel like I have an understanding of the attack vectors and I’ve mitigated those to a level that’s acceptable to me.

Risk tolerance is something we all have to judge for ourselves.

Yup… HUGE difference between human curated machine learning and generative AI. AI sure is a buzzword these days, which is why it gets used in marketing, but I think doing so is confusing people who don’t know enough to distinguish between the different flavors of “AI”.

I actually started on a VPS… I moved off because I was pegging the RAM and adding more to my plan was quite expensive. Performance is MUCH better on my home server with plenty of RAM.

The point of the reverse proxy is that it simplifies your firewall configuration… you open one port (443) to one endpoint (your reverse proxy), and that’s it. The more complex your firewall configuration, the more likely you are to get something wrong and accidentally expose what you might not want to expose.

I do not use my reverse proxy for access control.

If you’re using containerized applications, then the worst-case scenario is somebody gets root permissions inside the container. Under those circumstances, they can destroy that instance of your application and access any data stored within the container. The thing is, they can ALSO do that if you’re on a VPS.

If there happens to be a Docker vulnerability that allows file system access to the host AND AT THE SAME TIME an application vulnerability, then you might be in trouble. The confluence of those two events, especially if you keep things updated, is unlikely enough that I have no reservations about hosting public services on my home network.

But that said… we all have our own level of risk tolerance. If it’s not right for you, then you shouldn’t do it.

edit: just reading up on huntarr and ooooh boy. Vibe coded app that asked you to provide API keys so it could talk to and control other services. No wonder it caused problems. It’s probably worth saying out loud: if the container you want to install is used to talk to and control other containers, you need to be EXTRA SURE that it’s reputable.

I don’t know enough about Apache to say one way or the other, but based on what you described, you SHOULD be able to get rid of the internal proxy. Since both the inner and outer are both NGINX, getting the settings right shouldn’t be a problem.

But, on the other hand, if it works it works!

Not sure what your solution was, but I eliminated the reverse proxy from the official compose stack and configured my existing reverse proxy to point directly at the lemmy containers. It works well for me.

I don’t get this perspective. A reverse proxy pointing at containerized applications gives you plenty of buffer between the scary internet and your personal files. Don’t bind mount your entire host file system to the container, and only open/forward the ports you need.

There are things you have to get right, but there’s no reason to discard the idea altogether.