Selfhosted

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

5 acronyms in this thread; the most compressed thread commented on today has 6 acronyms.

[Thread #967 for this sub, first seen 11th Sep 2024, 19:25] [FAQ] [Full list] [Contact] [Source code]

The steps below are high level, but should provide an outline of how to accomplish what you're asking for without having to associate your IP address to any domains nor publicly exposing your reverse proxy and the services behind the reverse proxy. I assume since you're running Proxmox that you already have all necessary hardware and would be capable of completing each of the steps. There are more thorough guides available online for most of the steps if you get stuck on any of them.

1. Purchase a domain name from a domain name registrar
2. Configure the domain to use a DNS provider (eg: Cloudflare, Duck DNS, GoDaddy, Hetzner, DigitalOcean, etc.) that supports wild card domain challenges
3. Use NginxProxyManager, Traefik, or some other reverse proxy that supports automatic certificate renewals and wildcard certificates
4. Configure both the DNS provider and the reverse proxy to use the wildcard domain challenge
5. Setup a local DNS server (eg: PiHole, AdGuardHome, Blocky, etc.) and configure your firewall/router to use the DNS server as your DNS resolver
6. Configure your reverse proxy to serve your services via domains with a subdomain (eg: service1.domain.com, service2.domain.com, etc.) and turn on http (port 80) to https (port 443) redirects as necessary
7. Configure your DNS server to point your services' subdomains to the IP address of your reverse proxy
8. Access to your services from anywhere on your network using the domain name and https when applicable
9. (Optional) Setup a VPN (eg: OpenVPN, WireGuard, Tailscale, Netbird, etc.) within your network and connect your devices to your VPN whenever you are away from your network so you can still securely access your services remotely without directly exposing any of the services to the internet

Focus on DNS for the host machine and it's port mappings, not the individual containers.

If you're instead asking "How can I easily map a DNS name to service and port?", then you want a reverse proxy on your host machine, like nginx (simplest) or Traefik (more complex, but geared towards service discovery and containers).

In the latter scenario you setup a named virtual host for each service that maps back to the service port exposed for your containers. Example: a request for jellyfin.localdomain.com points to the host machine, nginx answers the request and maps the host name in the request, then proxies your session to the container.

It's copy and paste for the most part once you get the first one going unless you're dealing with streaming.

If you're running a flexible platform on your router like OpenWRT, you could also do some port forwarding as a means to achieve the same thing.

@___ normally in the containers you can specify the dns server to use or include hosts directly in the static table, at the orchestrator level the ingress and egress options are used to specify interfaces and network configuration, although i think kubernetes stores everything in the etcd.

I have a similar setup except I use pfSense as my router and pihole for DNS, but I'm sure you can get the same results with your setup. I'm running HAProxy for my reverse proxy and configs for each of my docker containers so any traffic on 443 or 80 gets sent to the container IP on whatever unique port it uses. I then have DNS entries for each URL I want to access the container by, with all of those entries just pointing to HAProxy. Works like a charm.

I have HAProxy running on the pihole itself but there's no reason you couldn't just run that in it's own container. pfSense also let's you install an HAProxy package to handle it on the router itself. I don't know if opensense supports packages like that though.

You can even get fancy and do SSL offloading to access everything over HTTPS.