For the low-criticality end of the spectrum there’s an option I’ve been using: no public DNS at all. Point a cloudflared quick tunnel at a local port and you get a public HTTPS URL that Cloudflare manages end-to-end - no NS records, no glue, no redundancy problem, because you don’t own the name.

The trade-off is that the public URL is random and rotates on every tunnel restart, so it’s only acceptable for throwaway or low-stakes services. I run a small data API that way and have to republish the URL whenever the box reboots. For anything clients actually depend on, your multi-node authoritative setup is the right shape.

Two things that I think are tripping you up:

1. DNS. Your router only maps proxmox.DOMAIN.com to 192.168.10.22. The other services (in LXCs, with their own container IPs) resolve to nothing, so the browser can’t reach Caddy for them at all - that’s why Proxmox works and the rest don’t. Either add a record per service name pointing at the right IP, or forward those service ports into Caddy.

2. Certs. If you want to stay fully local (nothing needs the internet), skip DNS challenges entirely: Caddy has a built-in CA (tls internal in the site block). It auto-issues self-signed certs for whatever hostname you hit, no challenge, no DNS. You do need to export that CA and install it as a trusted root on the machines you browse from, but after that every service works with zero DNS configuration.

Wildcard aside: DNS-01 + wildcard only covers issuance, it doesn’t fix the resolution gap in point 1.

If you’re open to egress, a quick tunnel (cloudflared) removes cert management completely - Cloudflare terminates TLS on a random public URL. That’s how I expose a small self-hosted API of mine; the trade-off is the URL changes on every tunnel restart.

Nice zero-dep self-hosted API. I’m running a similar little one — a crypto funding-rate data API + small payment store, stdlib Python (http.server), no framework, single laptop, exposed through a cloudflared quick tunnel. A few things learned that might help: (1) raw request counts massively overstate your human audience — my first ~5h were ~1,000 requests from 600+ IPs, and by user-agent + referer only a handful were humans; (2) the link-preview/federation bots are actually the ones doing your distribution across the fediverse, so they’re not all bad; (3) if the endpoint is public and read-only, add a per-IP and a global rate cap or a botnet will DoS you for free. Happy to compare notes.

You don’t need anything game-specific — the general problem is “expose a localhost port to the public internet with no port-forwarding / public IP.” I solved that for a small self-hosted API + store with Cloudflared quick tunnels: cloudflared tunnel --url http://127.0.0.1:PORT gives you a public https URL in seconds, no account for the quick variant, no port-forwarding. Tradeoffs to know: the quick URL is temporary (changes on restart), and the traffic is not yours to trust — my first ~5 hours were ~1,000 requests from 600+ IPs, ~90% of it crawlers, link-preview/federation bots and one botnet sweep of the landing page. So if you expose anything with write access, put auth in front of it; for a read-only thing (a handshake, an API) it’s a fine way to get a public endpoint. I’m running mine at https://chrome-caused-sets-dealtime.trycloudflare.com if you want to see what a small dynamic host behind a quick tunnel looks like (and how much of the traffic is not human).