Replace subdomain routing with port-based routing

[mairas]

Problem

Windows cannot resolve multi-label .local mDNS names (e.g., signalk.halos.local). This is a hard Windows DNS client limitation with no client-side workaround. All HaLOS subdomain URLs are broken for Windows users.

See halos-org/halos-mdns-publisher#37 for full analysis.

Solution

Replace subdomain-based routing with port-based routing. All services accessed via halos.local (2-label, works everywhere) on dedicated HTTPS ports. Traefik terminates TLS on each port and proxies to backend containers. Authelia served under PathPrefix /auth/ on port 443 as a special case.

URL Scheme

Service	URL	Notes
Homarr	https://halos.local	Port 443, root domain
Authelia	https://halos.local/auth/	Port 443, PathPrefix
Signal K	https://halos.local:4430	Traefik TLS termination
Grafana	https://halos.local:4431	Traefik TLS termination
Cockpit	https://halos.local:9090	Native HTTPS, no Traefik
Other apps	https://halos.local:44xx	Dynamically assigned

Path redirects on 443 for discoverability: https://halos.local/signalk-server/ → 302 to port URL.

Key Design Decisions

• Pre-allocated port range: Traefik ships with entrypoints 4430-4450. No static config regeneration. Port 4430 chosen as base — evokes 443 (HTTPS), not commonly used.
• Runtime port assignment: Apps don't declare ports. configure-container-routing assigns from /etc/halos/port-registry at first start.
• OIDC via path redirects: Redirect URIs use stable path URLs (e.g., https://halos.local/signalk-server/...), so apps never need to know their port.
• Single TLS cert: halos.local SAN covers all ports (certs are hostname-bound).
• SSO cookies: halos.local domain shared across all ports.
• Migration: Homarr tiles auto-update via registry file changes. Old bookmarks break (acceptable given small user base).

Implementation Issues

• Add Traefik port-based entrypoints and routing infrastructure halos-core-containers#102 — Traefik port-based entrypoints and routing infrastructure
• Implement port registry and update configure-container-routing halos-core-containers#103 — Port registry and configure-container-routing
• Migrate Authelia to PathPrefix /auth/ on port 443 halos-core-containers#104 — Authelia PathPrefix migration
• Update prestart.sh for port-based routing (TLS, OIDC, Cockpit, localhost) halos-core-containers#105 — Update prestart.sh (TLS cert, OIDC, Cockpit, localhost redirects)
• Update Signal K and Grafana OIDC configs for port-based routing halos-marine-containers#145 — Update Signal K and Grafana OIDC configs
• Update webapp registry files for path-redirect URLs halos-marine-containers#146 — Update webapp registry files for path-redirect URLs
• Deprecate subdomain mDNS publishing halos-mdns-publisher#38 — Deprecate subdomain publishing

[jrehm]

This fix would also resolve Tailscale remote access, which has the same root cause.

When accessing HALOS via the Tailscale MagicDNS hostname (halos.taile04635.ts.net), Traefik routing works fine once you mirror the halos.local router rules for the Tailscale hostname. The remaining problem is the webapp registry — the {{domain}} template in /etc/halos/webapps.d/*.toml resolves to halos.local, and the sync service continuously writes those URLs into Homarr. Clicking any tile over Tailscale sends the browser to halos.local, which is mDNS-only and not resolvable remotely.

The current workaround is adding halos.local → Tailscale IP to /etc/hosts on each client, which works but is manual. Once this issue lands and Homarr tiles use halos.local:443x port-based URLs, halos.local becomes a plain A-record lookup — resolvable via Tailscale's DNS with a simple split DNS override — and the workaround goes away.

So the Windows mDNS fix and the Tailscale remote access fix are essentially the same change. Nice.