The other answers covered options on hooking up the internal DNS, so here is the https part for the sake of completeness.

One option is running an internal CA, but that’s for crazy people. And you have to distribute your root CA to every device using it, which can be annoying if you don’t have centralized configuration management in place.

If you want https with caddy and don’t want it exposed you can use a DNS challenge with your external DNS provider. Check the list here for your provider.

Assuming docker and your dns isn’t built in you build a custom docker image with the plugins you need. This is a Dockerfile for route53 based on here:

FROM caddy:builder AS builder

RUN xcaddy build \
    --with github.com/caddy-dns/route53

FROM caddy:alpine

COPY --from=builder /usr/bin/caddy /usr/bin/caddy

And then a docker-compose.yml in the same dir to use it:

services:
  caddy:
    build: .
    restart: unless-stopped
    ports:
      - 80:80
      - 443:443
      - 443:443/udp
    volumes:
      - ./caddy_data:/data
      - ./caddy_config:/config
      - ./conf:/etc/caddy

With this mount setup you write conf/Caddyfile and include the DNS provider specific configuration relevant to your plugin, probably documented in its repo.

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.