Your homelab is the perfect place to learn about both the good and bad sides of networking and server infrastructure. On the one hand, a homelab is an extremely useful tool for any tinkerer. On the other hand, it’s a security nightmare if not set up properly. Here are four privacy settings that most homelabbers get wrong, and how to fix them.
Exposing admin dashboards to the internet
Proxmox was never meant to be managed outside your LAN
There are a lot of admin dashboards in any homelab, and it never fails that something breaks when you’re not home. While Tailscale and VPNs allow you to utilize your network from anywhere, the easiest solution is to simply use a reverse proxy and open that admin dashboard to the network with a domain name, right? You’ve got password authentication set up, so isn’t it secure? Most of the time, it’s not as secure as you think.
Having an admin dashboard open to the internet means that bots can look for that specific type of admin dash and try different brute force methods to get into it. This actually happened to me recently, with one of my admin dashes that I had behind a reverse proxy getting compromised and a crypto bot being deployed on my server without me knowing.
Lots of Docker containers (or services in general) can have exploits that make it possible for brute force attempts to break through the authentication stack and gain access to the app. So, if you open that admin dashboard to the internet, you’re asking for trouble.
5 uncomfortable truths about homelabbing you need to hear
Maybe that Netflix subscription would have been cheaper…
Leaving default credentials on self-hosted apps
Default passwords are one of the easiest ways to get compromised
Even if you don’t open your admin dashboards up to the public, you should at least change the default login credentials for your self-hosted apps and networking gear. The fact of the matter is, your homelab is susceptible to being infiltrated whether you open it up to the wider internet or not.
Hackers have many ways to gain access to your local network, be it through smart home devices with shoddy security, 3D printers, or even normal paper printers, your network isn’t as secure as you think it is. If someone is able to gain access to your local network in any way, then they’re able to access your self-hosted services, too.
If your setup is anything like mine, then you likely use standard ports for various services—the same ports that every other homelabber also uses. This makes it easy for hackers to gain access to your self-hosted stack, or even your router admin pages, if you use default login credentials.
Opening ports to the public when they should be internal only
Not every service needs to be reachable from the internet
The rule of thumb should be to open as few network ports on your router as possible, as an open network port is an invitation for hackers to enter your network. Now, I have several ports open on my network for various reasons, but I also know the risks of opening those ports.
The problem comes when you open ports on your network that don’t actually need to be opened. For example, if you want to run a Minecraft server at your house, the you need to open port 25565 on your network. However, if you’re only running that server to play locally, then there’s no reason to open that port up to the world.
The same goes with SSH. You should rarely, if ever, port forward port 22 on your network. HTTP/S is also a risky one, though it’s something that many homelabbers do, with opening port 80 and 443 to the web.
Really, if you don’t have an explicitly good reason to forward a port, then simply don’t forward the port. It’s better to have all ports closed on your network.
Keeping API tokens or passwords stored as plain text
Plain text secrets make breaches much worse
You’re going to use a lot of API tokens in your homelab, so you’re going to want to keep them written down somewhere. Just please don’t write your passwords or API keys down in plain text. I made the mistake early on in my homelab journey of putting API keys in Obsidian, which stores notes as plain text Markdown files.
While this is convenient, it is anything but secure. In fact, vibe coders are constantly leaking their API keys on GitHub because they’re stored in plain text in files that are committed to their repo and pushed publicly. Don’t do that in your homelab.
Instead, use a password manager or another form of encrypted storage, so even if the document leaks, the contents aren’t available for others to use and abuse. Whether the API key belongs to your OpenAI account for ChatGPT access or it’s the API key for Sonarr, it needs to stay nice and safe where nobody else can access it.
- Brand
-
KAMRUI
- CPU
-
AMD Ryzen 7 7735HS
- Graphics
-
AMD Radeon 680M
- Memory
-
16GB LPDDR5
- Storage
-
512GB NVMe
The KAMRUI Hyper H1 mini PC is perfect for setups that need a high-performance desktop without spending an arm and a leg. It boasts the AMD Ryzen 7 7735HS 8-core 16-thread processor and 16GB of LPDDR5 RAM (which is not user-upgradable). The pre-installed 512GB NVMe drive can be swapped out for a larger one though, and there’s a second NVMe slot for extra storage if needed.
Your homelab is only as secure as you make it
While I love homelabbing, one of the biggest problems with running a homelab is being in charge of its security. If you know what you’re doing, it’s not that big of a deal. However, newcomers definitely can (and do) make mistakes when it comes to how secure a homelab is.
At the end of the day, if you have questions on how secure your homelab is or isn’t, err on the side of opening up the fewest ports possible and changing default passwords. If you simply do those two things, your homelab should be fairly secure, at least until you learn how to set up VPNs, stacks like Authentik, and harden your services.

