Keeping Vaultwarden private but reachable on the home LAN without the client running... does this hold up?

[buscemiflora]

Running Pangolin (self-hosted) on a VPS with Newt on a Raspberry Pi at home. Vaultwarden is currently a public resource with SSO + path rules for the Bitwarden endpoints (/api/, /identity/, /notifications/, /icons/, /attachments/* allowed, /admin/* denied), which works well with the browser extension and mobile clients.
I'm considering switching it to a private resource instead, mostly because I like the idea of a password vault having zero public DNS footprint. What's holding me back is that private resources seem to require the client to be connected, and for something like a password manager I don't want "is my VPN client currently alive" to be a precondition for logging in... especially on mobile, where background VPN apps get throttled or killed by the OS all the time.
So here's the plan I've been sketching out, and I'd like a sanity check before I actually build it:
Vaultwarden stays a private resource... no public domain for it at all.
At home, AdGuard Home on the Pi does a DNS rewrite so the domain resolves straight to the Pi's LAN IP instead of leaving the network.
A small Caddy instance in front of Vaultwarden on the Pi gets its own cert via DNS-01 against my registrar's API, so the local connection is still real HTTPS, not just plain HTTP with a broken padlock.
Away from home, the official Pangolin client connects like normal and resolves the private resource through the tunnel as usual.
End state: at home it's a plain HTTPS domain that works with zero dependency on any client or tunnel, and away from home it behaves exactly like any other private resource. Pangolin itself never has to expose it publicly.
I'm doing something similar for Jellyfin, except that one stays public (TV apps, Chromecast, and other people in the house can't run a client), with the same AdGuard + local Caddy trick so streaming at home doesn't round-trip through the VPS and chew through my upload.
One thing I'm actively trying to avoid: a single network-wide CIDR tunnel that hands out access to my whole 192.168.1.0/24 just to reach two or three services. Feels like it works against the whole point of Pangolin being resource-scoped — one compromised laptop turns into "now you're on my entire home network." I'd rather every service get its own resource, public or private depending on what it is, and keep a wide tunnel around only as a rare fallback for genuinely ad-hoc stuff.
I've seen discussion #685 (keeping traffic local when Pangolin is external) and I know this general shape of problem has been floating around for a while without a built-in solution — so I'm not expecting Pangolin to suddenly do this natively. Small side note for anyone else reading: I'm on the Enterprise Edition (free Personal License — just sign up and apply for a license key, no cost for non-commercial use), and I noticed the automatic certificate sync to Newt sites... the piece that makes 1.18's private HTTPS work — lives under the proprietary Fossorial Commercial License part of the codebase rather than the AGPL/CE side. Worth knowing if you're deciding between CE and EE for this kind of setup, though it's not really the core of my question.
The actual open question for me: even with EE's automatic cert handling for private resources, that only covers access through the client. It doesn't give me a way to reach the resource on the LAN without the client running at all, which is the part I'm trying to solve with the local AdGuard + Caddy detour. Is there a cleaner, more "native" way to get that no-client-needed local path while keeping the resource private, or is a local reverse proxy handling its own cert basically the only route regardless of edition?
Would appreciate anyone poking holes in the plan itself, and if anyone's actually running Vaultwarden this way already, I'd love to hear what broke and what didn't.

[svandive]

To late here now but I’ll respond tomorrow. I have a similar setup