For the first year I self-hosted, I didn’t own a domain. I had a bookmark folder full of things like http://192.168.1.40:8080 and http://192.168.1.40:8096, and I was weirdly proud of it. No registrar, no renewal emails, no DNS records to break. Just a box in the closet and some numbers.
Then I tried to get Vaultwarden working on my phone. The Bitwarden app refused to talk to a plain-HTTP address, and the browser extension wanted a secure context before it would do anything useful. I spent an evening generating a self-signed certificate, installing it on my phone, and discovering that my partner’s phone would need the same treatment, and so would every new device forever.
The next morning I bought a domain for about €12 a year. It was the most useful twelve euros I’ve spent on the homelab, and I still think a lot of beginners buy one too early, for the wrong reasons. Both things are true. Here’s how I’d decide.
What a domain actually does for a home server
A domain name is two things at once. It’s a name that DNS can turn into an IP address, so you type photos.example.com instead of a number. And it’s proof of ownership that certificate authorities like Let’s Encrypt accept when they decide whether to give you a trusted HTTPS certificate.
The first job has plenty of free substitutes. The second one is where owning a domain starts to matter, because modern apps increasingly refuse to work without real HTTPS.
When you genuinely don’t need one
You can skip the domain for a long time if all of the following are true:
- You only use your services at home, or through a private overlay like Tailscale or WireGuard.
- The apps you run are happy with plain HTTP on your LAN, or you can live with clicking through a certificate warning.
- Nobody outside your household needs to open anything.
A Plex or Jellyfin server, a Pi-hole admin page, a Syncthing instance: none of these care whether you own a domain. Jellyfin’s apps connect fine to an IP and port. Pi-hole’s dashboard works over plain HTTP. If that’s your whole setup, a domain is a nice-to-have, not a need.
Tailscale users get an extra reprieve. MagicDNS gives every device on your tailnet a name, and the tailscale cert command can fetch a real Let’s Encrypt certificate for a hostname under your tailnet’s ts.net domain. That covers a surprising amount of the “I need HTTPS for this app” problem without buying anything. The trade-off is that the names are Tailscale’s, not yours, and every certificate issued for them is recorded in public certificate transparency logs, so the machine names you choose are not secret.
When a domain stops being optional
In my experience, three situations push people to buy one.
Apps that insist on trusted HTTPS
Password managers, anything using WebAuthn or passkeys, progressive web apps that want to install on a phone’s home screen, some camera and microphone features in the browser: all of these want a secure context. A self-signed certificate technically gives you one, but only after you install your own certificate authority on every device. That’s fine for a lab. It’s miserable for a household.
Public certificate authorities won’t issue certificates for made-up names like vault.lan, and they won’t issue for a name you can’t prove you control. A real domain fixes this in one step.
Anything public
If people outside your house need to reach something, whether that’s a blog, a shared photo album, or a calendar, they need a name to type. You can use a free subdomain from a dynamic DNS provider like DuckDNS, and that works. But free subdomain services come and go, some need a periodic “are you still using this” click, and you’re one policy change away from losing the name everyone bookmarked.
Cloudflare Tunnel, the most common way to publish a service without opening ports, also expects a domain whose DNS is managed by Cloudflare. If you’re trying to get a public URL without buying a domain at all, Tailscale Funnel will give you a ts.net address instead. That difference in naming is one of several between the two, and Cloudflare Tunnel versus Tailscale Funnel for one public URL goes through the rest.
An IP address that keeps moving
If your ISP changes your public IP now and then, a name that follows it is the only sane way to keep remote access working. Dynamic DNS keeps a name pointed at your current address, and it works with free subdomains and with domains you own. But once you own a domain, you can run the updater against your own DNS provider’s API and stop depending on a free service’s goodwill.
The mistake I made with a fake domain
Before I bought a real domain, I tried to be clever. I set up Pi-hole local DNS records so that my services had names at home. I picked .dev as the ending, because it seemed fitting: nas.dev, vault.dev, media.dev.
Chrome wouldn’t load any of them over plain HTTP. It silently upgraded every request to HTTPS, which my services didn’t have, and then showed an error. It took me an embarrassingly long time to learn that .dev is a real top-level domain, owned by Google, and it’s on the browser HSTS preload list. Browsers are hard-coded to use HTTPS for every .dev name, full stop. I wasn’t inventing a private name. I was squatting on a public one that came with rules.
If you want a made-up name for LAN-only use, pick one that’s actually reserved for that. home.arpa is the official name set aside for home networks. .internal was reserved by ICANN for private use in 2024 and will never be sold as a public domain. .lan and .home are common and generally harmless, though not formally reserved. Avoid .local for DNS records, because it belongs to mDNS, the protocol that makes printer.local work, and mixing the two causes slow or failed lookups on Macs and phones.
But notice what none of these fix: you still can’t get a trusted certificate for them. A reserved private name gives you a tidy label. It doesn’t give you HTTPS.
How I use a domain now, including for private services
This is the part that surprised me most. My domain does more work for services that are not public than for ones that are.
Let’s Encrypt offers two main ways to prove you control a domain. The HTTP challenge asks you to serve a file on port 80, which means the service has to be reachable from the internet. The DNS challenge asks you to create a temporary DNS record instead. Your reverse proxy does it automatically through your DNS provider’s API. Nothing needs to be exposed at all.
So my setup looks like this:
- I own
example.com(not really, but you get it). DNS is hosted at a provider with a decent API. - My reverse proxy requests a single wildcard certificate for
*.home.example.comusing the DNS challenge. - Pi-hole has local records pointing
vault.home.example.com,photos.home.example.com, and the rest at my server’s LAN address. - From outside, those names don’t resolve to anything. There’s no public record. They only work at home or over my tailnet, where Pi-hole answers.
Every device in the house gets a padlock, with no certificate installs and no warnings. The wildcard matters for one extra reason: certificates are logged publicly, so if I requested a separate one for every service, anyone could browse the list of my hostnames. A single wildcard reveals only that home.example.com exists.
Buying one without regretting it
If you decide you need a domain, a few things are worth knowing up front, mostly learned by watching friends get burned.
Look at the renewal price, not the first-year price. Some endings are €1 for the first year and €30 or more after that. A plain .com or your country’s domain at an honest registrar is usually €10 to €15 a year, every year.
Pick a registrar with a real DNS API, or move DNS somewhere that has one. The DNS challenge and dynamic DNS both depend on it. Cloudflare, deSEC, Porkbun, and several others work with most reverse proxies out of the box.
Turn on auto-renew and keep the payment card current. An expired domain is a special kind of outage. Every certificate stops renewing, every name stops resolving, and after a grace period someone else can register it. A friend of mine lost a domain he’d used for family email for six years because the card on file expired and the reminder emails went to an address on that same domain.
Don’t use your real name if you don’t want to. Most registrars include WHOIS privacy for free now. Check before you buy.
Keep it boring. Your homelab domain will end up in bookmarks, config files, and your family’s password manager. A short, pronounceable name you’d be happy to spell over the phone beats a clever one.
So, do you need one?
If everything you run is LAN-only or tailnet-only, and none of your apps are fussy about HTTPS, no. Save the money until something forces the question. If you use Tailscale, its built-in names and certificates may carry you a long way.
If you run a password manager, want passkeys to work, need anything public, or are tired of certificate warnings on every family phone, yes. Buy a boring domain, use the DNS challenge, and put your private services under a subdomain that never appears in public DNS.
And whatever you do, don’t name anything .dev unless you own it. I had to learn that one the slow way.
