First: E2EE. You're thinking in terms of a web gui, not a E2EE client-server where the server itself is untrusted. If done properly (and I've seen no indication Bitwarden's isn't) that would mean that server compromise is irrelevant anyway beyond uptime.

But second in general: Bitwarden has people attacking it full time, and necessarily must be on the public internet with untrusted clients. And I do not. One's own server doesn't need to be on the public internet at all, you can have 100% of access exclusively through a Wireguard or other secure VPN. You have completely control of every single client, because they're all yours. Server blocked from internet entirely, update it out of band, or at least restrict what it can talk to to exclusively upstream update servers. This massively reduces attack surface. If only trusted clients can access something, then compromising it means going through a trusted client. But if the trusted client is compromised in this scenario you're hosed regardless. The server is irrelevant.

There's lots of good reasons of course not to run your own thing, but the security aspect gets overdone with false equivalences. It's the equivalent of people pointing at what the likes of Amazon or Google or whomever have to do for database work. But while they have far more resources, they also have far more demands and requirements. Stuff that is very challenging at hyperscale can be done far more simply but still effectively at small/medium scale. It's not wrong to think about the tradeoffs, but worth being cautious of apples to watermelons comparisons.

I wish password protection was a lot simpler.

Another great option is Cloudlare with it's "cloudflared" tool. Combine that with OIDC+forwardauth and I would be OK exposing some not so critical systems to the internet.

This way, I only have to focus on making sure my vpn is secured.

https://tailscale.com/kb/1153/enabling-https/