Of the many useful things I could do with my spare time instead I'm setting up a Lemmy instance because why not. The scope of this is definitely greater than any self-hosting I've ever attempted, so please feel free to tell me just how much trouble I'm in. I'm just giving the broad strokes to see if I've made any crucial errors (other than deciding to do this at all).
And if this is a completely wrong place for a post like this or I'm missing data I'm supposed to include I apologize, I probably need a sanity check, in more ways than one.
First limitation, I'll be hosting it on an existing Linux Mint box acting as a file share mostly and occasional gaming PC/movie streaming box. Its hardware is overkill for this, I do not anticipate issues when it is in use. It receives regular updates and weekly reboots, instance will be set to automatically restart. NVMe with loads of space for local storage, RAID SSDs for data offload/backup.
Second limitation, I hate Cloudfare and Oracle. I do not want to use either of them.
Third limitation, money. Cheaper is better. I have a URL picked out and a registrar which will give me the cheapest long term option, in case I actually keep this thing going.
Last limitation, I'm already in over my head so I'll be relying on a lot of googling and probably some chat bots to figure things out as I go through the actual deployment process. What could go wrong?
So, Lemmy hosted on Linux Mint box using Docker containers. ISP is a good one for this I'm told, no CGNAT, largely stable public IP but I'll have a script running in case it does change. Confirmed ports 80/443 are open. Using Caddy for the HTTPS. Closed registration to start, if by some miracle I make it to actually wanting to allow additional users it will not be fully open, and I'll use Brevo for the email SMTP. Security wise I know I'm making it harder for myself by exposing my IP, I'm going to have UFW running and Crowdsec to help keep incoming bad traffic out.
Down the line I'll get Lemmy updates, backups, retention rules in place/automated, and make decisions on federation, etc. Thoughts?
You should not host anything that's going to be public facing on your home network in 2026, period. Get a cheap German VPS and go nuts with it. There's simply too much at stake opening up your home router/firewall for such little gain. Plus, being a residential IP behind NAT might just make it straight up impossible.
I host my own email and a matrix server. I would never think of exposing my home network to the internet. I use tailscale to get into the homelab, anything exposed to the net lives somewhere far, far away.
I use netcup for my email and matrix. It's extremely reasonable.
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.
It's not about the container escape so much as the potential for someone to do a DNS lookup on your domain name and use that to locate you physically. Yes, it's coarse location data, but someone on 4chan was able to locate Shia LaBoeuf from a single picture of a flagpole. It doesn't take much.
For the record the domain provider I selected masks my info at no extra charge.
It masks the registration info, but it can't mask the IP by definition, and that can still be traced back to you.
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’m somewhere in the middle, because comments like yours actually reinforce my concerns. A reverse proxy isn’t really doing anything to make you more secure, unless you’re using it for some sort of access control. It hides which ports you’re using, and allows you to encrypt your traffic with TLS… But it doesn’t add any additional security to the services you are exposing.
Maybe if you use it for access control, to add a secondary username/password to the services. But that breaks most legitimate things (apps, mostly) that try to reach the double-password-protected service. Because a user on a web browser may be able to type in two passwords, (one for the reverse proxy, and then one for the service itself) but an app will try to pass that info automatically using headers.
Any vulnerabilities in the services will still become potential attack vectors. Anyone who remembers the Huntarr debacle will know exactly what I’m talking about, because a single service being vulnerable can do a lot of damage. Yes, containerization does a lot to help mitigate damage by excluding access to everything except what you give it. But it won’t completely stop things from going wrong.
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 use mTLS and vlans whenever I expose things to the internet.
Those devices should most certainly be on two separate networks. Internet facing devices should be on a DMZ and not be allowed to talk to your internal network. You can then allow your internal network reach your DMZ devices, but only allow return traffic from the DMZ.
In the words of that one guy from Casino: Why take a chance? A VPS is peace of mind for a cup of coffee a month. I like to be sure the things I need to keep safe have as many opportunities to remain that way as possible.
I get it, but the whole point of this is for me to utilize hardware I already have. If I get to a point where it's not working out I can always go that route but I want to learn on my local machine and I can always switch later.
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.
I'm glad that works for you.
I also don't get this fear. Assuming you aren't blindly exposing your entire filesystem or opening tons of ports what is the risk?