Give Your Services Real Names: The .lan Pattern That Saved My Sanity

The moment you bookmark 192.168.1.47:8096 in your browser, something has quietly gone wrong. Not broken, not catastrophic. Just wrong. You've accepted a compromise so small it barely registers, and that compromise will compound until your home lab is a thing only you can operate, on the one machine where you remembered to save the bookmarks.

There is a better way. It takes an afternoon, it requires two pieces of software you may already have, and once it's done you'll wonder how you tolerated the alternative. The pattern is called a private DNS zone, and it gives every service on your network a real, human-readable name.

Bookmarking IPs Is a Sign Something Has Gone Wrong

You built the thing. You got Jellyfin running, Nextcloud synced, Home Assistant talking to the lights. It works beautifully, from your desk, on your laptop, when you remember the port. The rest of the time it's a scavenger hunt through a bookmark folder that reads like a CIDR table.

The failure modes are specific and humiliating. You share a bookmark with your kid and it breaks three weeks later when you move the server to a different machine. Your spouse asks, for the fourth time, what the URL is for the photo library. Your phone browser drops the raw IP bookmark after an app update because mobile browsers were never designed to treat IP:port strings as durable navigation targets.

The emotional weight of this is real. You spent weekends on this. You learned Docker networking and reverse proxy concepts and storage pooling. And the payoff is a folder of bookmarks that only work on one browser, on one device, when the IP hasn't changed. Your infrastructure is technically impressive and practically invisible to everyone who lives with you.

There is a pattern. It takes an afternoon to implement. It changes how every device on your network finds every service, permanently. The fix isn't more bookmarks. It's names.

The Real Pain: Infrastructure Nobody Else Can Use

The problem isn't that your family is bad at technology. The problem is that you've built a system that requires memorizing implementation details to use basic features. That's a UX failure, and it belongs to the infrastructure, not the user.

The Shared-Bookmark Problem

IP addresses are not stable identifiers. They feel stable until you swap a NIC, move a VM to a different host, or reorganize your subnet. The moment you do any of those things, every bookmark pointing to that IP is broken. On your machine you notice and fix it. On your kid's laptop, the bookmark just stops working and they stop trying.

Static DHCP leases help, but they're a mitigation, not a solution. You're still distributing raw addresses as if they were meaningful to humans. They aren't. 192.168.1.112 tells you nothing about what's running there. library.house.lan tells you everything.

Some people reach for a VPN as a workaround. Install WireGuard on every device, route traffic through the home server, done. Except now you've traded a naming problem for a configuration management problem. Every new device needs a key. Every family member needs an app. Every phone OS update has a chance of breaking the tunnel. You've pushed the complexity sideways, not eliminated it.

"Infrastructure that requires tribal knowledge isn't infrastructure. It's a hobby that only you can operate."

The Spouse Test

This is the real benchmark. Not "does it work?" but "can someone who didn't build it use it without asking you?"

If your partner cannot open the media library from the couch on their phone without first texting you to ask for the URL, your network has a UX problem. Not a knowledge problem on their end. A design problem on yours.

The Spouse Test is not about technical sophistication. It's about whether the names and addresses you've assigned to your services are durable, memorable, and device-agnostic. Raw IP addresses fail all three criteria. Real hostnames pass all three. The fix is architectural, and it's simpler than you think.

The Pattern: Give Everything a Name

Every serious home lab eventually arrives at the same architectural decision. It doesn't matter whether you got there by reading a forum post, watching a video, or suffering through enough broken bookmarks. The destination is always the same: a private DNS zone that maps human-readable names to local IP addresses, entirely inside your network.

What a Private DNS Zone Actually Is

DNS is the system that translates names into addresses. When you type google.com, a DNS resolver somewhere looks up the corresponding IP and hands it back to your browser. That same mechanism works on private networks, with private names, pointing to private addresses.

A private DNS zone is a resolver running on your LAN that answers queries for a specific suffix you define. When any device on your network asks "what's the IP for library.house.lan?", your local resolver answers with the IP of your reverse proxy. The query never leaves your network. Public DNS servers have no idea house.lan exists, and that's exactly correct.

This is not a hack or a workaround. It's the same mechanism corporations use for internal services. The only difference is scale.

Why a Fake TLD Is the Right Move

You need a suffix that will never collide with a real public domain. ICANN has reserved several for exactly this purpose, but they're not all equally safe.

.local is the most commonly seen in home labs and the most problematic. It's reserved for mDNS (Multicast DNS), which Apple and Linux systems use for zero-configuration device discovery. If you use .local for your private DNS zone, you'll get intermittent resolution failures as mDNS and your DNS server argue over who answers the query.

.internal was informally used for years and has recently received formal ICANN reserved status, making it a legitimate choice. .home is also reserved but sees less tooling support.

.lan is the practical favorite. It's widely understood to mean "local area network," it has no mDNS conflict, and every DNS server that supports custom zones handles it without complaint.

A brief aside: there's a long tradition in home labs of naming servers after mythological figures. Prometheus, Atlas, Hermes. It's charming, it scales poorly past about six machines, and it tells you nothing about what the server does. Name your services for what they are. Save the mythology for your kids' Minecraft servers.

Every home lab that matures past the "it works on my machine" phase lands here. The naming pattern isn't optional infrastructure. It's the thing that makes everything else usable.

The Two Pieces You Need

The entire pattern has exactly two moving parts. That's it. Two services, one job each, and they compose into something that makes your entire network feel like a professionally managed system. If you're expecting a sprawling dependency tree, you'll be relieved.

Piece One: A DNS Server with Wildcard Rewrites

The first piece is a local DNS resolver that knows about your private zone. When a device on your network asks for any hostname ending in .house.lan, this resolver returns the IP address of your reverse proxy. It doesn't need to know about individual services. It just needs one wildcard rule: everything matching *.house.lan points to one IP.

Your options here are good and plentiful:

AdGuard Home is the most approachable. It has a web UI, handles DNS rewrites through a simple form, and doubles as a network-wide ad blocker. If you're starting fresh, this is the right default.

Pi-hole with dnsmasq works identically. Pi-hole's DNS is dnsmasq under the hood, and you can add custom rewrite rules via config files in /etc/dnsmasq.d/. If Pi-hole is already running on your network, you don't need to change anything.

Plain dnsmasq or Unbound work fine for people who prefer minimal dependencies and config-file-driven setups. Both handle wildcard rewrites without complaint.

Piece Two: A Reverse Proxy with Automatic TLS

The second piece is a reverse proxy that listens on ports 80 and 443, reads the hostname from each incoming request, and forwards the traffic to the correct backend service. This is where the routing intelligence lives.

Caddy is the right default for home labs. It handles TLS certificate generation automatically, its configuration syntax is readable without a reference manual, and it can act as its own local certificate authority when you use the tls internal directive. You configure one block per service, and Caddy handles the rest.

Nginx Proxy Manager gives you a web UI if you'd rather click than type. It's a reasonable choice if you're already comfortable with Nginx and prefer visual configuration.

Traefik integrates tightly with Docker and can auto-discover services via container labels. It's powerful and worth learning if your lab is heavily containerized, though its configuration has a steeper initial curve.

Here's how the two pieces interact. A browser on your phone requests library.house.lan. The phone's DNS resolver, pointed at your AdGuard Home instance, returns the IP of your Caddy server. The browser connects to Caddy on port 443. Caddy reads the hostname from the request, matches it to the library.house.lan block in its config, and proxies the connection to whatever port Jellyfin is actually running on. The phone never needs to know the backend port. The user never needs to know the backend IP. Everything is handled by names.

That's the whole system. DNS answers the name, the proxy routes the traffic, the service responds. Two pieces, clean handoff, no tribal knowledge required.

The Five-Minute Install: Caddy and AdGuard Home

The install itself is not the hard part. The hard part was knowing this pattern existed. Now that you know it, the implementation is mostly typing.

Step 1: Configure AdGuard Home DNS Rewrites

Open AdGuard Home, navigate to Filters > DNS Rewrites, and add a single entry:

• Domain: *.house.lan
• Answer: the IP address of the machine running Caddy

That's the entire DNS configuration. Every hostname under house.lan now resolves to your Caddy server. You don't add individual entries for each service. The wildcard handles everything.

Pi-hole users do the same thing via a custom dnsmasq config file. Create /etc/dnsmasq.d/house.lan.conf with the following content:

address=/.house.lan/192.168.1.50

Replace 192.168.1.50 with your actual Caddy machine IP. Restart dnsmasq. Done.

Step 2: Write Your Caddyfile

Caddy's configuration lives in a file called Caddyfile. Each service gets its own block. Here's a minimal example covering three services:

1library.house.lan {
2    reverse_proxy localhost:8096
3    tls internal
4}
5
6dashboard.house.lan {
7    reverse_proxy localhost:3000
8    tls internal
9}
10
11files.house.lan {
12    reverse_proxy localhost:8080
13    tls internal
14}

Each block follows the same structure: the hostname on the first line, a reverse_proxy directive pointing to the backend, and tls internal to tell Caddy to issue a certificate from its local CA rather than attempting a public ACME challenge.

The tls internal directive is doing significant work here. Caddy generates a root certificate authority on first run, stores it locally, and uses it to sign a certificate for each hostname in your config. Your browser will show a warning until you install the root CA, which the next section covers. After that, every service gets a green padlock with no further configuration.

Step 3: Point Your Network at the Right DNS Server

The final step is making sure every device on your network uses AdGuard Home (or Pi-hole) as its DNS resolver. The cleanest way to do this is through your router's DHCP settings.

Find the DHCP configuration in your router's admin panel. Look for a field labeled DNS Server, Primary DNS, or similar. Set it to the IP address of your AdGuard Home instance. When any device connects to your network and gets an IP via DHCP, it will also receive this DNS server address automatically.

Most routers let you set a primary and secondary DNS. Set primary to your AdGuard Home IP. For secondary, you can use 1.1.1.1 as a fallback for public resolution if your local DNS server is unreachable, though this means .house.lan names won't resolve during that fallback. Some people prefer to leave the secondary blank and let failures be obvious. Both approaches are defensible.

After changing the DHCP setting, devices need to renew their lease to pick up the new DNS server. On most devices, disconnecting and reconnecting to Wi-Fi is sufficient. After that, open a browser, type dashboard.house.lan, and watch it load.

Killing the Browser Warning: Installing the Root CA

The green padlock is the goal. Right now, if you've followed the steps above, you're getting a browser warning instead. The warning is technically accurate and practically annoying, and you can make it disappear permanently with a one-time install on each device.

Why the Warning Appears

Browsers maintain a list of trusted Certificate Authorities (CAs). These are organizations that have been vetted and approved to vouch for the identity of websites. When your browser sees a certificate, it checks whether it was signed by one of these trusted CAs. Caddy's local CA is not on that list. It's a CA you created yourself, on your own machine, for your own network. The browser has never heard of it, so it warns you.

This is correct behavior. The browser is doing its job. Your job is to tell it, once, that this particular CA is trustworthy on this particular device.

How to Install the CA Once and Forget It

First, get the Caddy root CA certificate. By default, Caddy stores it at /data/caddy/pki/authorities/local/root.crt inside the container, or at a similar path on the host depending on your install method. Copy that file to each device you want to trust it.

macOS: Open Keychain Access, drag the root.crt file into the System keychain, then double-click the certificate, expand the Trust section, and set "When using this certificate" to

What This Looks Like Day to Day

Before this pattern, you are the DNS server. Someone wants to pull up Jellyfin and they text you. You look up the IP, you send it over, they bookmark it, and six weeks later the IP changes and the whole cycle starts again. It's a support ticket system disguised as a home network.

After? Your spouse bookmarks library.house.lan on her phone once. It works every time she opens it, regardless of what IP your media server happens to be sitting on that week. Your kids know dashboard.house.lan and navigate there without asking. You drop a link in the family group chat and it resolves for everyone on the network without a single "what's the password for the thing" follow-up.

Browser history and autocomplete finally earn their keep. Because the names don't change even when the IPs do, your browser starts completing dash into dashboard.house.lan and lib into library.house.lan. Muscle memory builds. The network starts feeling like something people actually live in rather than something they navigate around.

The compounding benefit is real. Adding a new service means writing a two-line block in your Caddyfile and one DNS rewrite entry in AdGuard Home. That's it. No new certificates to wrangle, no firewall rules to remember, no IP to announce to the household. The infrastructure absorbs the new service and hands it a name, and everyone who already knows the pattern can reach it immediately.

Five minutes, not an afternoon.

Naming Conventions: A Brief Philosophy

Names matter more than most home lab guides admit. Picking a naming convention early saves you from a messy refactor later, and it shapes how intuitively people navigate your network.

Flat vs. Hierarchical Names

You'll see two schools of thought. The hierarchical camp uses names like media.services.house.lan or monitoring.infra.house.lan, borrowing the logic of organizational DNS trees. It's tidy on paper. In practice, nobody types it. Your spouse will not type media.services.house.lan when she wants to watch something. She'll ask you for the IP instead, which defeats the whole point.

Flat names win on usability. library.house.lan, dashboard.house.lan, photos.house.lan. Short, descriptive, memorable. The zone suffix (house.lan) provides all the namespace you need. Keep the service name itself to one word when you can.

Making Names Memorable

Name services after what they do, not what machine they run on. Machines change. You'll reprovision, migrate, consolidate. A service called zeus.house.lan tells you nothing and becomes actively misleading when Zeus gets retired and the service moves to a new host. Speaking of Zeus: naming your hosts after Greek gods is a fine tradition and a harmless bit of charm. Hermes, Athena, Prometheus. Go for it. Just keep that layer separate from your service names, which should be strictly functional.

Descriptive names are infrastructure design, not aesthetics. A new person sitting down on your network should be able to guess that books.house.lan serves your ebook library and metrics.house.lan shows system graphs. That legibility is the difference between infrastructure someone else can use and infrastructure only you can navigate.

One practical caution: avoid names that collide with public hostnames you actually visit. Don't name a local service photos.google.lan or anything that shadows a real domain you rely on. Keep your zone suffix distinct and your service names generic enough that no collision is possible.

Common Gotchas and How to Dodge Them

The pattern is straightforward, but a few specific failure modes will eat your afternoon if you meet them unprepared.

Split-DNS and the Away-From-Home Problem

*.house.lan only resolves on your LAN. The moment you leave home, those names go dark. Your phone will fail to reach dashboard.house.lan from a coffee shop, and depending on how your apps handle DNS failures, it may not be obvious why.

Two solutions. The cleaner one: run a WireGuard VPN back to your home network. When you're connected, your phone routes DNS through your home resolver and everything works exactly as it does on the couch. The simpler one: accept the limitation. Most home services don't need to be reachable remotely, and keeping them LAN-only is a reasonable security posture. Decide which camp you're in before you start, and document it somewhere you'll find it in six months.

The .local Trap

When Your ISP's Router Ignores Your DNS

Some ISP-provided routers override DHCP DNS settings and force all clients to use the router's own resolver. Your AdGuard Home server sits there doing nothing while every device on the network dutifully sends queries to the ISP box, which has never heard of house.lan.

The fix depends on how much control you have. If you can replace the ISP router with your own hardware, do it. If you can't, set DNS manually on each device that matters: your laptop, your spouse's phone, the kids' tablets. It's tedious once and invisible forever after. A third option: configure your router in bridge mode if it supports it, and put a proper router behind it. That gives you full control over DHCP and DNS without fighting the ISP firmware.

Two more quick ones worth knowing. Docker containers don't always inherit the host's DNS configuration. If a container needs to resolve library.house.lan, add dns: explicitly in your Compose file pointing at your AdGuard Home IP. And before you start Caddy, check whether anything else is already listening on port 443 with ss -tlnp | grep 443. Caddy's failure mode when the port is taken is quiet enough to cost you real debugging time.

Alternatives and When to Use Them

The two-piece architecture, a local DNS resolver plus a reverse proxy, stays the same regardless of which tools you pick. What changes is the surface area, the configuration style, and how much you already have running.

When Pi-hole + dnsmasq Makes More Sense Than AdGuard

If Pi-hole is already running on your network for ad-blocking, there's no reason to add AdGuard Home alongside it. Pi-hole uses dnsmasq under the hood, and dnsmasq supports wildcard rewrites through custom config files. Drop a file in /etc/dnsmasq.d/ with address=/.house.lan/192.168.1.50 and you get the same wildcard behavior. No second DNS server, no migration, no split authority.

Plain dnsmasq without Pi-hole is the lightest possible footprint. No web UI, minimal memory, runs happily on embedded hardware or a minimal VM. If you're provisioning a small machine where every megabyte counts, dnsmasq alone is the right call. Unbound is worth considering if you want a full recursive resolver alongside your local zone. It's more configuration to stand up, but you get proper DNSSEC validation and no dependency on upstream resolvers for public queries.

When Traefik or Nginx Proxy Manager Beats Caddy

Nginx Proxy Manager offers a GUI for managing proxy hosts, which matters in households where someone other than you might need to add or change a service. If your partner is comfortable in a web interface but not in a config file, NPM is the right proxy.

Traefik shines if you're already deep in Docker and want containers to register themselves automatically via labels. The learning curve is steeper than Caddy, but once it's configured, adding a new containerized service means adding three labels to the Compose file. No Caddyfile edit required. The tradeoff is complexity: Traefik's dynamic configuration model takes longer to reason about when something goes wrong.

Pick the tool that fits your existing setup. The pattern underneath is identical.

Your Checklist: From IP Hell to Named Services

Ten steps. Most of them take under five minutes once the first one works. The first one takes an afternoon, and then you never do it again.

Real Names Are the Difference Between a Lab and Infrastructure

Infrastructure that requires memorizing IPs is infrastructure only its builder can use. That might feel fine right now, when you're the one who set it all up and the addresses are still fresh. Give it six months. Give it a new router that reassigned everything. See how long the mental map holds.

The pattern scales without changing its nature. Three services or thirty, the architecture is identical: one DNS rewrite, one reverse proxy, names that describe what things do. Each new service costs five minutes and one Caddyfile block. The household learns the zone suffix once and navigates everything after that without asking you.

This is the difference between a personal project and something your household actually relies on. Reliance requires legibility. Legibility requires names. Your Plex server isn't infrastructure until your spouse can reach it without texting you first. Your home dashboard isn't infrastructure until your kids bookmark it themselves and the bookmark still works in January.

Pick one service today. One. Give it a name. Add the DNS rewrite, write the two-line Caddyfile block, install the CA cert on your phone, and open yourservice.house.lan in a browser. Notice how different it feels from typing an IP. That feeling is the point. Everything else in this guide is just the machinery behind it.