My comment, which you refer to, said nothing about NAT -or- firewalls. Rather, it’s a direct response to the second sentence in the article’s opening paragraph: “To the average computer user, the idea that someone could just… connect to your computer feels exotic, or even dangerous…”

You may be correct that nobody would recommend implementing IPv6 without a firewall. But this article avoids the subject of firewalls completely, which in combination with that opening paragraph leaves the distinct impression that we shouldn’t be concerned about it because that’s the way the internet was meant to be.

Of course this has nothing to do with NAT or IPv6, and the value of IPv6 can’t be overstated. But to ignore the security part of the equation is going to have one of two effects: 1) people who don’t know better will think they can use IPv6 without a firewall, or 2) people who understand the risks will be skeptical of the claims that IPv6 is better because you are leaving out an important part of the equation.

I read “Networking for Dummies” in 2005, and it gave me a GREAT baseline understanding. I don’t recall how much it discussed ipv6 at that time, but I imagine the newer editions cover it.

In the same way that the XKCD hand-waved FTP, this article hand-waves the idea that we shouldn’t be concerned about who can access our self-hosted services.

I’m not saying it’s wrong, but I’d like more of an explanation on why we shouldn’t be concerned about allowing anybody on the internet having direct communication with our computers.

Welcome fellow instance owner!

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.