You just need a reverse proxy

Nginx manager. Surprisingly simple. You change your letsencrypt to contain yourdomain.com and *.yourdomain.com and voila.

I have that exact setup. Let’s suppose you want to use layzer.lan as your domain. The way I did it:

1. Make a DNS record that maps *.layzer.lan to your private IP (let’s say it’s is 192.168.0.10). You can do this by either manually editing your local DNS resolver config file, or hosting a DNS server and adding a a new entry. I did the later, and chose AdGuard for that. Either option will make your PC underestand that going to any subdomain *.layzer.lan means going to 192.168.0.10.

2. Use a reverse proxy. I use nginx-proxy-manager, and added a proxy host for each service you want to access with the link. For example, for my Immich server that is running in port 30041, I added a proxy host such that http://immich.layzer.lan/ takes you to http://192.168.0.10:30041/. Ports 80 and 443 have to be free for nginx to take. You can also add https support from here, and it’s very easy to do if you have bough a real domain.

Offtopic; I just noticed that on my Lemmy Android client you appear as laserjet, but on web you appear as layzerjeyt lol. Any idea why?

You want a reverse proxy. A reverse proxy reads requests to subdomains and then forwards them to ports and back.

The easiest GUI one is: https://nginxproxymanager.com/

But there is also just straight nginx, or you can use Caddy or traefik or anything else.

Use Caddy on each device, with tls turned off. Basically

http://service1.devicename.lan/ {
    tls off
    reverse_proxy localhost:8000
}
http://service2.devicename.lan/ {
    tls off
    reverse_proxy localhost:8096
}

https://doc.traefik.io/traefik/ if you dockering

i use with openwrt DNS Forwarding to create a wilcard domain (eg service1.nbsp.lan, service2.nbsp.lan etc), then when i vpn in all my services just work ™️… kinda

I wanted to say I know this one, but a lot of people beat me to it use caddy.

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

6 acronyms in this thread; the most compressed thread commented on today has 8 acronyms.

[Thread #52 for this comm, first seen 12th Jul 2026, 06:30] [FAQ] [Full list] [Contact] [Source code]

Read up on the host header, any http server can parse that. Set up DNS resolver and the http server does the rest. If you already serve from a reverse proxy, just change the port setup to a host header based setup. The term to search for is vhost config.

Caddy makes it dead simple to do exactly what you described.

Not sure if it’s the simplest way, but this is how I did it. I set up a reverse proxy service in a vm using caddy and then used pihole (also in a vm) to set up a local DNS record pointing to the reverse proxy. The systems need to be set up to use the pihole server as their DNS resolver.

How it works is you type audiobookshelf.local.lan in the address bar and it queries pihole which says it at 192.168.1.100 or whatever. The Caddy web server at that address then passes the request on to the service at 192.168.1.60:8080.

Setup is a bit tedious but it has worked for me.

What is the absolute simplest way to accomplish this?

< gets on soap box>

The absolute simplest way is to use IPv6: on your Debian machine, assign multiple IPv6 addresses, one for each service you want to expose to your LAN. There’s no penalty with having a dozen v6 addresses.

Although you have those addresses, your machine generally uses just a single one for its own outbound and inbound traffic. For each service, you would edit their config so that they bind to a specific IPv6 address. Finally, you would configure an AAAA entry in DNS so that your chosen subdomain will point to the IPv6 address in question.

As an example, suppose you had three different web servers running Nginx, currently on port 80, 8081, and 42069. What you would change is the server config for each server instance, adidng the IPv6 address as part of the “listen” directive. Since each instance is now bound to a different IP address, nginx can now listen to the conventional port 80 and n’ary will the three collide. In other software, the configuration option you’re looking for is the “bind address”. By binding each app to its own IP, it will only respond if you send a request to that IP (or DNS name, which translates to an IP); this conveniently makes debugging really easy.

For a home network, you might have a single /64 IPv6 subnet. But that still means you literally have billions upon billions of addresses to use before you ever run out. And as you’ve recognized, using DNS names to identify services is a lot easier and intuitive than using port numbers. It also neatly avoids the need to memorize IPv6 addresses, because that’s never been necessary: we have DNS.

If your ISP won’t give you IPv6, you can still use locally-assigned private ranges, known as ULA, and this works because your services are contained to your LAN. Best practice is to randomly generate a subnet then use it.

< gets off soap box>

Nginx proxy manager is the easy way. Spin it up and the UI is fairly straight forward. You can also achieve the same thing with nginx or caddy, but you’ll have to set up the configs by hand.

If they’re just internal the simplest way is to add another IP on the same interface to whatever is serving your service, then bind the service to that IP and add the entry in DNS.

If for some reason you want to keep everything hosted on one IP, for a reverse proxy, caddy is pretty simple. An example caddyfile would be:

http://service1.devicename.lan/ { 
    reverse_proxy 1.2.3.4:9005
}

http://service2.devicename.lan/ { 
    reverse_proxy 127.0.0.1:1234
}

This would also allow you to set https in the future using ACME (dns method if internal only) or your own CA / custom cert.

If all your services support binding to a unix socket, I’d bind them to /run/<servicename>.sock or similar, and set up a reverse proxy that hits /run/$servicename.sock when serving $servicename.devicename.lan. If the service can’t bind to a unix socket, you can probably socat it or similar, and keep using the generic reverse proxy. Then, all your router has to do is route port 80 to your Debian machine.