I like the workflow of having a DNS record on my network for *.mydomain.com pointing to Nginx Proxy Manager, and just needing to plug in a subdomain, IP, and port whenever I spin up something new for super easy SSL. All you need is one let’s encrypt wildcard cert for your domain and you’re all set.

A reverse proxy makes setup a lot easier and more versatile, and can manage SSL certs for you.

Whatever floats your boat. If you don’t need it, you don’t need it. I have some services exposed to the outside on the standard port and I need a reverse proxy to make that possible. It also does the https with letsencrypt certificates. It’s a bit more comfortable managing them all in the reverse proxy. But I also have some webinterfaces of other less important software that is fine running on some IP on port 5102 and I don’t worry configuring something to change that. I don’t think there is a “should” unless you need to encrypt the traffic or expose that service to somewhere. And it’s also not wrong to do it.

Don’t use jellyfin.server.local

.local is reserved for mdns, which doesn’t support more than one dot. (Though it may still sometimes work).

In any case, to make that work you need either a DNS server on your network or something like duckdns (which supports wildcard entries).

It’s nice not to deal with HTTPS warnings etc and as you said it’s more convenient to access by domain name rather than remembering port numbers. You should be able to technically achieve the latter in another way by using docker and configuring it to assign a real IP for each service (a bridge network presumably), then setting each service to use port 80 externally. But that’s probably as much work as just setting up a reverse proxy.

And if you’re concerned about exposing ports, you can use DNS challenge which doesn’t require opening port 80 on your router.

I would say if locally. No. But the moment you open up to the web. Yes. Nginx proxy manager is also very good for this.

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

9 acronyms in this thread; the most compressed thread commented on today has 10 acronyms.

[Thread #854 for this sub, first seen 6th Jul 2024, 22:45] [FAQ] [Full list] [Contact] [Source code]

Personal preference.

Unless something has changed, Caddy isn’t a dns server. It’s a web server and reverse proxy. If you might expose something to the public internet, you will want it behind the reverse proxy.

If you want to access local network services (private vpn counts) via a domain name all you need is a DNS server and for you clients setup to query that dns server. I use PiHole for this. From what I understand Adguard may be similar to PiHole but I’ve never looked a it.

One thing to be wary of, there are no reserved private network domains. Depending on how you set things up your local network dns queries may go out onto the public internet. It’s best to go ahead and register a domain name that you want to use so that you can control it routing if that happens. They can be had cheap as $11 USD each.

If you’re not hosting any publicly available services, then no. A reverse proxy would be unnecessary. You can just just set static records in your DNS server that tell it which internal hostname goes with what IP and it will relay that info to any device on your local network that requests it. Even with a Wireguard connection, you can tell it to use the DNS server from your local network.

Reverse proxies aren’t DNS servers.

The DNS server will be configured to know that your domain, e.g., example.com or *.example.com, is a particular IP, and when someone navigates to that URL it tells them the IP, which they then send a request to.

The reverse proxy runs on that IP; it intercepts and analyzes the request. This can be as simple as transparently forwarding jellyfin.example.com to the specific IP (could even be an internal IP address on the same machine - I use Traefik to expose Docker network IPs that aren’t exposed at the host level) and port, but they can also inspect and rewrite headers and other request properties and they can have different logic depending on the various values.

Your router is likely handling the .local “domain” resolution and that’s what you’ll need to be concerned with when configuring AdGuard.

It entirely depends on how you want your homelab to work. I use a reverse proxy to set up subdomains for my publicly facing services because I find it easier and cleaner to assign a subdomain to each service, and I also like having HTTPS managed by a single point — a sort of single point of entry to the rest of the services. You’d have to decide what you want out of your homelab, and find and set up the services that yield the outcome that you want.

Definitely yes. I only see positive benefits by using a reverse proxy. From the fun of learning new stuff to the added security (which is never a downside) and being ready to expose outside in a future.

Somewhat related rant: I recently tried to set up a reverse proxy on a Synology NAS, my god was it convoluted.

For sure.

At some point, your services could easily warrent it. If you learn it early, it makes it much easier to organize your services and share them with others if you decide to.

Also, if you do decide to use a domain name, you probably won’t be able to use it internally to your network. If you use Adguard, you can use DNS rewrite to only direct your traffic to your server when you’re in your network.

Also, personally, I use nginx, but I’m more than happy to give you any advice on setup or reverse proxy.

I didn’t for the longest time but now I use Traefik for this. It can automatically add services (i.e. containers) to it’s routing list so the overhead is low and since I also run openwrt on my router I setup *. localhost to point to 127.0.0.1 so I don’t have to remember what ports I’m using for which service (e.g. jellyfin.localhost). You can also setup DNS entries using something like PiHole.