1. Unbound can override custom domain names if you want.
2. I migrated from Nginx to Angie’s to get more features for free. And also has builtin let’s encrypt support.
3. If the services are public configure fail2ban and something like Angie Guardian see: https://angieguardian.org/ to reduce ddos and bots.

Not sure if it fits in your setup, but I’m accomplishing what you’re looking for (myservice.mydomain.com) with self-hosted AdGuard and DNS rewrites (send URL X to IP Y), and then just point the router to AdGuard DNS.

The few services I need to access from outside my home LAN run through Tailscale on my laptop or phone, so no services are publicly exposed.

Hmmm… there’s a few different things going on here.

As others have already said you don’t need a cert if you’re just messing around internally, you can use an internal TLD - .local is reserved for mdns, Avahi, etc. so that’s fine… personally, I use .home

I use pfSense, but I presume that OPNSense has the same function in DHCP to provide the Domain Name in there, so any static mappings will respond to thing.home

I also have HAProxy to resolve external httpS://IP:Port to an internal http://thing.home (note: no S internally)… this simplifies my setup, and I presume it could work internally too, but I’ve not set it up as DHCP solves that for me.

I don’t use containers, instead each thing is it’s own VM, or physical machine, so I don’t know whether NAT (on proxmox) would resolve your issues with everything’s on 1 VM…?

You dont need to map ip+port, most selfhosted services let you change their port to the default http port

If this is for internal only you can setup OpnSense to do DNS records either through static IPs or add hostnames to the DNS records via DHCP. If you want this externally that’s a whole other ball of wax.

Neither require you to purchase a domain name. Just use whatever you want .internal While you can use other things like .lan, .internal is the only one that is actually reserved for LAN use.

*I’m pretty sure you can add firewall rules in OpnSense as well to redirect from port 80 or 443 to whatever port you’re actually using but that may cause more problems than it’s worth. If you can’t change the port in the app itself then, honestly just bookmark it with the actual port so you don’t have to remember it.

No need to have an external domain. And you can set up an internal DNS to route any domain name to any IP address. Just be sure not to point anything to your external IP address from your ISP or any globally addressable IPv6 addresses.

Issue is that it might confuse your devices that jump between internal access and external access like your phone if you use a domain name that’s owned by someone else, like example.com. I have two domains, one for my VPSs and one for internal stuff. So when my devices are outside the network they can’t resolve any of the DNS addresses that are set up inside and can’t access any of the IP addresses. That is unless I connect with vpn. I also have pangolin for a few things that are accessible externally, but that’s rare since apps can’t use those kinds of authentication systems, just web front ends.

You don’t need an external domain. Use .internal as your tld and you can use whatever domain your want. jellyfin.homelab.internal, for example.

I own a domain and run my internal stuff under internal records. Part of the reason for doing it this way is I can use the DNS challenge for issuing LE certs to the internal services automatically.

And no a reverse proxy will not expose anything to the Internet, unless you also open the port in your firewall (and forward it in NAT if it’s on the lan and you use NAT).

If you don’t mind the warning “Woah, I don’t trust this website”, you don’t need to buy any domains. Just use local certificates.

Sample caddyfile that I use

#------------- general options
{
    local_certs
}
#------------- services
service.server.lan {
	reverse_proxy <INTERNAL SERVER IP>:<INTERNAL SERVER PORT>
}

However, you need to have a DNS entry which points *.server.lan to the correct server. You can now visit https://service.server.lan/ which should point correctly.

Best of luck!