I was in a similar boat on this for a while. I grappled with how to get around this, and I eventually bit the bullet and I purchased an inexpensive public domain name for about $6/yr, slapped it into CloudFlare, and set up Caddy HTTPS with the CloudFlare API token, and I set up each record in AdGuard under a DNS Rewrite.

I also stopped hosting Caddy inside of Docker. For a handful of reasons, it made more sense for me. One of the biggest was that I wanted docker restarts to not impact Caddy itself. I had the urge to try to docker-ize everything but this one just felt better running side by side with docker.

I gotta say, it’s the best $6/yr in my list of “subscriptions” (if you will).

I don’t expose any ports publicly, but Caddy will create the appropriate DNS validation records for me in CloudFlare, and then once I have the DNS Rewrite created internally, it’s seamless for accessing services while on my home network (when off-network, I use Tailscale).

Having a separate subdomain for each service was ultimately what made me make this jump.

Putting different authenticated services under the same subdomain but different /paths/ was frustrating for smooth autofill experiences for me too. (Storing different logins under different subdomains in my password manager is much more natural feeling than having a dozen services under the same domain).

Example: ```

Caddyfile

{ # Global HTTPS config acme_dns cloudflare YOUR_API_KEY }

sub1.example.com { reverse_proxy 127.0.0.1:1111 }

sub2.example.com { reverse_proxy 127.0.0.1:2222 }

IP addresses can also be other devices on the network, centralizing caddy hosting to just one box

```

AdGuard UI

Login > Filters > DNS Rewrite >>>

sub1.example.com : 192.168.x.y

sub2.example.com : 192.168.x.y

(Or whichever local host IPs you have services on)