Self-Hosting Is easier with a Domain

Something that I got into not too long after starting my homelab journey was self-hosting websites. From my own personal website to self-hosted services (like Calibre for eBooks and AudioBookshelf for audiobooks), I wanted an easy way to access those services outside my home.

I could have used port forwarding and forward specific ports to the services and accessed them that way. However, that doesn’t necessarily work well with SSL certificates, and if your public IP changes, then you’ll have to start using a new IP to access everything. With Nginx Proxy Manager (or any other proxy management app), you can properly set up SSL certificates for true HTTPS browsing, whether local or remote.

With a domain for your homelab, those services can easily be accessed outside your local network. I use this to access almost everything that I self-host on my server. From server administration pages to services, I use domain names almost exclusively to access my servers at this point.

If your IP address rarely changes, then you’re able to just put that IP into your DNS host and have things resolve to your local network through a program like Nginx Proxy Manager. This is the case for me, but I know that some people have IPs that change frequently, and thankfully that’s not a hard problem to solve.

If your IP changes often, then dynamic DNS is perfect for you. This is another tool in your belt to constantly update the IP address that your DNS server points to without having to manually change anything. Not all DNS servers support dynamic DNS (DDNS), so be sure wherever you buy your homelab domain from (or whatever nameserver you choose to use) supports it. I personally use Cloudflare, which has a few ways to access your home services.

Cloudflare tunnels are one option, but I prefer DDNS with fully qualified domain names (FQDN) as it’s the easiest to set up and let others access your services through. DDNS runs a local service on one of your computers inside your network, constantly checking what your external IP is. If that IP changes, it updates the IP address of your domain through a connection to your DNS provider.

I personally use the CloudflareDDNS Docker container to keep my IPs updated, though you can choose whatever DDNS software you prefer. Unifi has DDNS built-in for several providers, and other routers might also offer a similar service if you’d rather do that than worry about running a Docker container.

Either way you go, DDNS is essential if your IP changes even semi-frequently, as it’ll keep your self-hosted services live on your domain name all the time.

Internal DNS for Secure Services

Not everyone wants to access their services externally, and I get that. While I have most of my services open with DDNS and Nginx Proxy Manager, there are still some services I don’t want accessed outside my network. I’ve already mentioned that you can set your external DNS server to point to an internal IP. However, you can also just set up Nginx Proxy Manager to work in conjunction with a service like Pi-Hole for local DNS resolution.

This works by Pi-Hole acting as your DNS server, and then Nginx Proxy Manager handling where the domain goes. Once fully set up, you can type in myservice.domain.com and Pi-Hole will resolve it locally without ever sending the request outside your network.

With the added security this brings, you’ll be able to use domain names for everything in your services stack, but without having to open anything up externally. It’s the most secure way to use a domain on your local network. The best part is, it can even be free.

Getting a Domain Is Easier Than You Think (And Could Be Free)

There are a number of ways you can get a domain name. I typically buy them from Cloudflare, but there’s Namecheap, GoDaddy, Squarespace, and many others. Most .com domains cost about $10 per year to register these days. Other TLDs like .me, .co, .wiki, .media, or even something fun like .lol or .tech could definitely cost more though.

However, there’s a slight workaround here. If you’re going for local DNS resolution only, you don’t technically have to own a domain. Your system will simply look for the local entry and navigate from there. This can lead to unexpected consequences if you pick something popular.

For example, you could redirect google.com to go to your own self-hosted search engine if you wanted. However, that would mean everyone on the network would go to your search engine and not Google when navigating to that domain. You could also accidentally pick a domain to use for your homelab that someone else eventually claims and uses. In this instance, you could have conflicts because trying to access that new website redirects you to your homelab.