A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
Be civil.
No spam.
Posts are to be related to self-hosting.
Don't duplicate the full text of your blog or readme if you're providing a link.
Submission headline should match the article title.
No trolling.
Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details. Tags [CBH] or [AIP] are required, see the links in Rule 8 for details.
AI-related discussions and AI-involved promotional posts have additional requirements for tagging, as noted in Rule 7 and the AI & Promotional Post Expanded Rules post, and find example disclosures here.
Resources:
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
What I did was setting up two routers. The outer one is a big filter, and the only packets coming in went through it.
If someone would have managed to take over this outer router, the next step would have been to probe the inner router. For this, they would send packets originating at the outer router to anything on the inside net.
This would trigger an alert on the inner router that switches a relay, cutting the power on the outer router.
Thank you all for your advice and tips. I am very overwhelmed by the sheer amount of information that's been given and I'm going to spend some time digesting and reading up on these things. Lots of terminology is over my head at this point and I have a lot of learning to do.
For monitoring, I'd start with alerts on changes you didn't make. Save a baseline of listening ports with ss -tlnp and of running containers with docker ps --format '{{.Names}} {{.Image}}', then have a daily cron job compare both against the baseline and push any difference to your phone with ntfy.
Keep the baseline files outside your Docker volumes.
Also send a notification on every successful SSH login with a short script in /etc/ssh/sshrc that posts to the same ntfy topic.
Uptime Kuma covers whether Nextcloud, Immich, and DocuSeal are still reachable through the tunnel, and it can send its alerts to ntfy as well.
Drafted with AI.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:
| Fewer Letters | More Letters |
|---|---|
| ICMP | Internet Control Message Protocol (ping, TTL exceeded, etc) |
| ISP | Internet Service Provider |
| IoT | Internet of Things for device controllers |
| LVM | (Linux) Logical Volume Manager for filesystem mapping |
| SSH | Secure Shell for remote terminal access |
| VPN | Virtual Private Network |
| VPS | Virtual Private Server (opposed to shared hosting) |
7 acronyms in this thread; the most compressed thread commented on today has 8 acronyms.
[Thread #139 for this comm, first seen 18th Oct 2026, 03:40] [FAQ] [Full list] [Contact] [Source code]
You're actually in a better starting position than most newcomers because the Cloudflare Tunnel setup means nothing on your box is directly reachable from the internet — that alone removes the biggest attack surface (port scanning, brute forcing, CVE-driven mass exploitation of exposed services). A few gaps worth closing:
Monitoring, since you asked: before installing anything fancy, get the boring fundamentals working: apt list --upgradable or unattended-upgrades for patch status, a cron that emails you ss -tlnp and docker ps diffs so you know when something new is listening, and disk/smart alerts — in my experience drives dying and cert renewals failing silently are far more likely to bite you than an attacker. Uptime Kuma is a low-effort next step for service-level checks, and with a Pi you already have around, a second machine doing checks of the first is more useful than monitoring from inside the box you're monitoring.
Duplicati-specific note: it has a history of bugs where restore jobs fail or repository checks go wrong and you only find out at restore time. Whatever your retention, do one actual restore of a few files each month — a backup you've never restored is a hypothesis, not a backup.
One thing to think about: E2EE in Nextcloud only protects files you've explicitly marked; the database, photos in Immich, etc. are plaintext on disk. That's fine, but be honest with yourself about what an attacker with the disk would get. Full-disk encryption plus a reboot-dropbear setup covers that gap if the data is sensitive.
Biggest real-world risk for your setup isn't hackers: it's misconfiguration during the next "quick change." Snapshot (even a LVM/zfs snapshot or a docker commit before major container updates) and you can roll back instead of rebuilding.
Wazuh and TOTP
My passwords for OS and all admin dashboards are extremely long, unique, random strings managed by Bitwarden.
If you are paying for Bitwarden, or using their free tier, stop and and start hosting vaultwarden. You can still use the Bitwarden app, with vaultwarden but with all the premium features.
Get a firewall you can either install OpenWRT or opnSense on, when making my decision I went with OpenWRT because opnSense has a webpage that tries to upsell you. vLAN the heck out of your place, and set up a VPN to access your services like vaultwarden out side of your home. On a vLAN that cannot access your WAN or anything else put your IoT things, on a vLAN that cannot access anything else setup crowdsec. On the topic of crowdsec it should be your only device that port 22 is ssh!
For your IoT things set up home assistant, which should be on a different vLAN that can reach out to the WAN and into the IoT vLAN to control stuff. I wish I could say I have completly degoogled and deappled, but I am waiting for a year for my iPhone to stop getting updates and whenever for my iPad to stop getting updates. I should probably replace my homepod minis sooner rather than later with the Naebu things for HA. The only thing I still have a Google account for is youtube but once I get a hand me down Mac mini I will install Debian and get a youtube replacement with sponsor block.
One of the things that finally got me off of cPanel was the host I was using decided to rape me over the coals without letting me have a wildcard email address so I got a business plan that I could have unlimited email addresses so if one got spammy I could just turn it off and if I still used the service I just changed the email, or if I wanted to extend a free trial I could just spin up a new address. So I recently moved to a new host that offers wild card addresses.
Get a whole LAN adblocker, let it be pihole or adguard home, there was recently that spyware ad pixel so expect more of those in the future. Me personally use pihole and have it very finally tuned to block a lot. I tried adguard once but liked pihole better, this was years ago even before I had pihole finaly tuned so don’t ask me why I liked pihole more.
Use authelia for 2fa
Disable root ssh
Disable password authentication for ssh. Keys only.
Set up Fail2ban
That's about all that's left; 2fa and brute force protection. Good job.
Sub fail2ban for wazuh. It does the same but so much more, and does everything with 0 config after fresh install.
And move SSH to a non-default port. Without that, my public-facing servers get thousands of SSH attacks a day, and it basically goes to zero after moving it to a random-looking high port.
Also, totally agree with using public key login and disable password login.
That's generally good advice but not actually security related.
Removing all the stress on your ressources by using a non-standard port is good for your ressources, But those automated scanners looking for unsecured devices and trying out password like admin/admin are not actually a risk. It's just a case of security by obscurity and never actually serves its purpose.
Very true. There are only ~65K ports. If someone decides they want to, trying all of them to see which one gives a valid response is trivial.
Literally a single nmap command will tell me where you "hid" your ssh port.
Like the poster you're responding to said, it is good advice but not for security. It takes you off the hacker spam list, essentially.
Rereading this it sounds like I am disagreeing with you sorry. Just trying to reiterate your point.
OpenSSH rate limits authentication attempts so it isn't a big deal. My public VPS gets pounded but it doesn't matter as it doesn't really use any system resources.
Timely updates do a lot of the heavy-lifting.
And I hope you picked a better admin dashboard this time or that's properly locked behind some tunnel. I myself try not to run admin dashboards. SSH with keys is more convenient and secure anyway.
A few tips off the top of my head, in no particular order:
do not allow public access to any of this. It's not trivial to set up a wireguard tunnel so that you can reach your home network from e.g. your phone or laptop when you're away, but it's also not highly complicated. Usually your home Internet router can already get you half way there.
if you must have some service available from the public net, it's better to e.g. host it on a cheap VPS. That way if your things get hacked again (via no fault of your own), your home network is safe.
set up automatics updates, at least for minor updates. If you're fine with waiting for a few days in case an update crashes one of your services, it's a good idea to just make it all auto update. Crash recovery from a backup is a simpler problem then setting up from scratch because your outdated service got hacked and now attackers own your home server, home router, TV, fridge, LEDs and whatever else is Internet capable at your home.
use 2fa for any service you expose to public internet. Minor inconvenience, mitigates or avoids a whole series of errors.
document what you're doing in a simple doc. Can be a simple doc on your next cloud instance, just at a little note/log entry every time you do something. "added robo vacuum cleaner integration to my home assistant. Had to use version 1.2.3 because my robot is an older gen. Password's on my phone." helps a lot when something goes wrong later and you forgot what you did.
test backup recovery. Just delete everything and see if and how you can get it back. If you're afraid to do that, you don't have a backup.
simple monitori
I'm looking for advice to maximize security.
The most important answers to this all live outside your server. What is your home network like? Do you control the gateway? Do you have a dedicated firewall? Do you have devices segregated into VLANs so they can't observe each other (especially IoT devices)? Do you have SNMP disabled?
If you want security, you block all inbound and outbound traffic by default at your network firewall (not the server OS firewall), and then you open only the ports that you actually need, one by one. You set all the closed external ports to do not respond ("stealth" mode), so that anybody trying to reach your network from outside just gets nothing back except on the ports you specifically need to use. You segregate your internal network into logical areas, and you put things that need to talk to each other on their own VLAN, which may or may not have access to the upstream WLAN trunk depending on what they're doing. You don't allow crosstalk between VLANs except in very specific cases. You set static IPs and document them, so that you never have to ping or traceroute internally to find something, so you don't need SNMP. Anybody trying to use SNMP is conducting surveillance on your network and should stick out from other traffic (some "smart"/IoT devices do this automatically - they are bad and should be treated as malicious and should not be allowed to phone home). And then you monitor your traffic at the firewall, and you deal with anything unexpected as it comes up (like once a week review the logs until you have a sense of what normal looks like on different days at various times, then maybe set a few automatic alerts for things that exceed normal-ish boundaries, then go to reviewing like once a month or so - you don't need to be checking your logs hourly unless you have some reason to be actively paranoid).
If you handle everything correctly at the router/firewall level, you're way way beyond the security of most residential and small business networks. You're not, you know, impenetrable, but you're at the point where somebody with experience and resources will have to be trying to break into your network specifically on purpose. If you're that kind of target then nothing short of an actual SOC is going to help you, and running self-managed servers on your home network is a bad idea.
I'm not sure you know what SNMP is
Also Iot devices aren't really much of a threat. It doesn't hurt much to put them on a separate vlan but the security issues are mostly unrelated to a local home network.
Also don't put things on the internet. That is generally a really bad idea and will bite you in the butt eventually.
I'm not sure you know what SNMP is
Oops, I was definitely confusing that with ICMP. Good point.
https://oneuptime.com/blog/post/2026-03-20-block-icmp-firewall-risks/view
Also Iot devices aren't really much of a threat.
I consider it a threat if a device maps my local network, identifies the other devices I have connected, and/or monitors my network traffic and then sends a report on that back to its control server.
Also don't put things on the internet. That is generally a really bad idea and will bite you in the butt eventually.
Ain't that the truth. We really should just not.
Containers are not a security barrier. They cannot be, they never will be.
Not entirely true. If you're hosting multiple game servers on one machine, for example, it's best to run each instance in a container. Game servers, by their nature, are required to have public IPs and ports, and some of them run on old engines that are vulnerable to various DoS methods. If your server is attacked, it might crash the container(s), but it can't bring the whole server down.
Grab OpenBao (Opensource Hashicorp Vault) and begin using key management. You can do things like app roles, TOTP, single use wrapped tokens, key rotation and more to make sure that long lived access doesn't exist.
Have you read the TOS of your ISP, are you allowed to run a home server exposed to the internet?
It might be a good idea to at least read what the TOS says just so you are aware of potential consequences.
Can an ISP forbid you having your own home server? That doesn't sound legal. And if I am not mistaken the cloudflare tunnel is a lot like tailscale (which i would recommend over cloudflare anyway) it doesn't need open ports or anything like that.
They can forbid you from anything and they can terminate your service for any reason
And if you do, make sure to read them thoroughly. Most of these rules apply to for-profit hosting only. Or they're vague and they can't enforce them. And most contracts don't have rules anyway. They're mostly concerned with you not attracting DCMA complaints or a virus hosting some spam email server.
If the OP has it only reachable via a VPN, that might be good enough, it's not directly exposed. But otherwise yes.
Another, more important problem with publicly available home server: they lost their data when their setup was maintained by a professional hoster. According to the OPs words, they themselves "know just enough to be dangerous".
Exposing any of this to the public internet wouldn't be a good idea however you put it.
Get a FIDO2 security key for SSH keys.