You also have the option of network booting. Generally the PC gets an initial boot image over the network, then mounts an ISCSI disk for the OS to fully boot from.

This causes disk access to be a bit slow, but is useful for a Pi when you're tried of the SD card dying and don't have a M2 hat.

1. https://wiki.archlinux.org/title/Preboot_Execution_Environment
2. https://wiki.archlinux.org/title/ISCSI/Boot

Alternatively, can they run over a tailscale subnet router?

Yes, the cameras wouldn't need to be aware of tailscale (or a VPN), you'd just put a pi or install tailscale on a PC there and expose the cameras over the subnet router config to your server also on tailscale.

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.

Does this work different than the policy key? As far as I know the keys under software\policies are used by both group policy and intune, and honored by windows home editions so I'd expect they'd work more reliably than an outlook config setting.