I just looked at the requirements to host your own Bitwarden server. Why does a password manager need 2GB of ram (4GB recommended) and 25GB[1] of storage? That seems quite excessive, how much data and traffic does this thing need to handle for me plus family members?
It is written in Rust and is much lighter on resource requirements.
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
ecce485b8b3a bitwarden 0.06% 46.58MiB / 1.937GiB 2.35% 1.63MB / 28.1MB 17.5MB / 81.9kB 11
As well as what sibling said about it being E2EE and just using a standard API for storage, there are awesome tools these days so you can (and I think should) lock down your instance fairly well. Now when I run services like that I access them exclusively via WireGuard or Nebula, no exposure to the public internet at all. It's reliable, dependable and performant enough to pretty much put everything inside of by default. And for something as lightweight as this it should be fine running it at home off of most connections, if you don't have a fixed IP can bounce through even the cheapest VPS instance and still store nothing in the cloud (or run something like Nebula and automate that bit so that it's an encrypted mesh and only a minimal Lighthouse node need be 3rd party). If your instance is just for yourself then even the server can still be another of your devices. Selfhosting absolutely has its challenges and costs but the surface area for exploiting bugs drops a lot when there is no 3rd party or shared environment involved.
> if you don't have a fixed IP can bounce through even the cheapest VPS instance and still store nothing in the cloud
I've been meaning to look into this with wireguard, but I'm having trouble searching for/finding how to do this. Is "bastion host" what I'd want? Also is there a way to ensure the VPS cannot access the network as well, and just tunnels it essentially?
>I've been meaning to look into this with wireguard, but I'm having trouble searching for/finding how to do this. Is "bastion host" what I'd want? Also is there a way to ensure the VPS cannot access the network as well, and just tunnels it essentially?
First, yes a search phrase like that should get you the right terms, though there isn't anything inherently special about it. If multiple systems are connected to one system with wireguard giving them all access to a given subnet is straight forward. As far as the VPS, it can indeed access that subnet too, since it's acting as part of the subnet, but you can use normal firewall rules on the far side internally to control what can talk to what and how. And in this kind of specific instance the WG is more about controller public facing surface area, the Bitwarden/Vaultwarden traffic in flight is itself encrypted.
Second though, having said all that I think if you worried about the VPS bit (or even if not) you should take a look at the Nebula SDN [0, 1] instead. It's built on the Noise encryption framework as well. There, the fixed IP node (the "Lighthouse") primarily acts to let other nodes know their mutual addresses, and they then attempt to form a direct link with no bouncing through a bastion, it's a real mesh. This generally works even if both are NAT'd, and if not it's transparent fallback and still encrypted between them. Depending on distance between nodes this can be a lot lower latency as well. With Nebula you establish an internal CA (super easy built-in tool for it) and that doesn't (and absolutely shouldn't) live on the lighthouse.
I'm fortunate enough to have fixed IPs available to me at home and office and have tended to use WG a lot just because it's had more advanced support and performance in constrained environments for me (kernel support in Linux and now BSDs). Nebula has been super slick though and I've been using it more and more. It makes all this really easy.
Anyway, hope this helps a bit. It's really exciting to me how much open source networking power is now available to everyone. It's a bit of a counter decentralization force IMO to the last few decades push towards central service providers.
Do you use tricks to get https (like it can be done with Tailscale) or do you not bother anymore and rely on the transport encryption layer solely (like wireguard)?
I’m in the process of moving towards putting stuff behind new vpn solutions (Tailscale/ Wireguard in my case). It does feel good to drop https though. Or does it really not matter? What do HNers think?
The easy alternative is to purchase a domain, and use let's encrypt to create a wildcard certificate for you. I use the integration with my reverse proxy and it's pretty easy. You want a wildcard certificate because of the Certificate Transparency Logs, if you do it by subdomain then the list of registered subdomains will be public.
Certs on multiple devices - you can most likely still use let's encrypt as most things nowadays have native integration. Otherwise you'll likely have to do it manually
I recommend a domain you don't use for other things online
I have my own instance at home as non business user, also residential connection with dynamic IP, and I've picked to connect through ZeroTier, a private VPN based on wireguard
ZeroTier is definitely not based on WireGuard, it's its own custom protocol. Just thought you should know. It's their own and it used to be marketed as "a global network switch", it operates with 2400 MTU and fragments your packets when sending them (because MTU is 1500 on the internet). It also means you can send data over ZeroTier without IP addresses, broadcast and multicast should work too.
However, it's not WireGuard. WireGuard operates on L3, there's no L2 headers, you can't run MPLS over it, you can't add VLAN tags to it, you route all the traffic.
As long as you're not bridging yourself into the ZeroTier network there shouldn't be any issues though, but fragmenting always kills performance.
Aiui, the server's really just a storage backend implementing the correct API - vaultwarden can't really do any harm, it just stores what the client (encrypts and) tells it to. Worst case it doesn't store, and you still (but only) have a copy on the client.
It includes a MS SQL server among other things, so for serving single digit users its gonna be heavy. Check out Vaultwarden as an alternative for small scale self-hosting.
Honest question: do you believe that you’ll be able to guarantee the same/better uptime, performance, and security compared to the SaaS version? Hosting your own password manager seems like something you really shouldn’t do, just like hosting your own e-mail. This stuff is critical to your life.
Better security for sure. Bitwarden is a massive target while I am not. The chance that bitwarden has a databreach is way bigger than the chance that my server gets hacked. No one cares about my server, I am nobody not worth attacking. As long as I don't leave any big holes that can be found by an untargeted attack (which I won't, I run everything behind a personal VPN) it is safer.
You’re probably not worth individually attacking, but a brief look at the failed ssh login logs of any insignificant server shows that you probably are worth automated attacks… so I suppose the question is “Are you more vulnerable due to a) the risk of getting pwnt by an automated attack (due to a misconfiguration or being even a little slow to install a critical patch) or b) due to the risk of bitwarden getting pwnt by a sophisticated targeted actor?”
Further complicating this math is the E2EE nature of it, so it’s not just enough to pwn a server, you’d need to also compromise the client application.
Actually, now that I think about it, if you can compromise the client you don’t even need to compromise the server. I’m not really sure under what scenarios running your own server would protect you in in that case.
> Further complicating this math is the E2EE nature of it, so it’s not just enough to pwn a server, you’d need to also compromise the client application.
The webvault is both a server and a client, and you can't not use it. As soon as you sign into it once (which you must, with the official apps) you have allowed unsigned ephemeral javascript code to run against your decrypted vault.
I can contest to this, I am by no mean important and none of my servers that I own have any importance, BUT I have thousands of people trying to remote into the servers every day and also thousands of requests into some of my webservers with things like /admin /phpmyadmin or whatever, you name it.
So yeah even if you aren't a big target then you are still a target for automated attacks as they just pick whatever IPs they can find and try to breach.
Well, based on what everyone fears is happening over at lastpass, attackers just download all the encrypted vaults, then brute force the master passwords.
I have a hard-to-guess master password, but it wouldn't surprise me if they could crack it with a 2026 vintage GPU farm.
Anyone who doubts you should run zxcvbn and more modern entropy estimators against their passwords. Our intuitions are not good. Offering password-based encryption to normal users is borderline unethical.
The Bitwarden webvault infrastructure is a doomsday target. If it's compromised, no evidence of a client backdoor will exist except in the server logs. You can't avoid using it, because you need to sign into the webvault to configure 2FA. Want to change the encryption passphrase? Guess what, you need to use the webvault. Bitwarden's vault encryption is essentially reduced to the security model of TLS.
And? If you don't trust TLS then I assume you don't trust web banking, or purchasing anything over the internet for that matter. Might as well give up on technology and go find yourself a nice quiet pastoral life.
For me personally, I don't actually trust any of that.
Any purchase I do online is done with a virtual card that links to a bank account that only ever has the amount I need to pay for whatever it is I am currently purchasing. That way it doesn't matter if the information is stolen etc. because there is no more money to use and I can cancel the card as easily as I can create a new.
For banking I also only use my banks official app, I don't know how exactly it works and I assume it does use some form of http and whatnot, but I wouldn't trust using a bank through the browser as you never know what kind of thing an extension or something have in there.
I trust the cryptography behind TLS. I don’t trust every website using TLS. The difference between end-to-end encryption and transport-layer encryption is the website operator can recover the plaintext. And the point of the comment I responded to was that Bitwarden data is not recoverable. I’m glad that you think E2EE is a waste of effort though.
Following up, I find it funny that this old meme comment thought orders and banking are our most trusted activities, and not our communications and data storage.
"Bitwarden has the right to suspend or terminate your access to all or any part of the Website at any time, with or without cause, with or without notice, effective immediately. Bitwarden reserves the right to refuse service to anyone for any reason at any time."
Who would trust their passwords to a service with such a clause?
Yup, it's not rocket science if you already run your own services. An entire generation of techies seem to be completely scared of running their own machine and think it's some kind of massively difficult task.
Same or better uptime might not be granted, but I've been hosting my instance for quite a bit of time now, and the only downtime I've had were due to my ISP.
I'm using vaultwarden too (bitwarden_rs when I first deployed it), and have absolutely no complains whatsoever.
Also, after your device synced with the server at least once, you can still access and export all your passwords, even if the server is down. This is the main selling point for me : even in a disaster scenario, your passwords are "naturally" replicated.
Mine is exposed behind a reverse proxy, with a subdomain != Bitwarden, and a wildcard certificate. Never seen anything weird in the logs since (before, I had a named certificate including subdomain, and I was seeing regular pokes from unknown IPs, so better be on the safe side)
Again, the main bitwarden instance is a huge target. Mine is just a small instance with less than 10 users, which will probably never encounter a targeted attack.
> Also, after your device synced with the server at least once, you can still access and export all your passwords, even if the server is down. This is the main selling point for me : even in a disaster scenario, your passwords are "naturally" replicated.
Watch out for the browser extension clients though - they're prone to session expiry and insisting you relogin which is a problem if the remote server is down or gone.
Hosting your own is a twenty minute setup, more or less, and $5/mo on Hetzner. Uptime, in my experience, is 5 nines.
With SaaS, I am losing the main reason that I am using Bitwarden - that I don't want the X agency to force Bitwarden to give them my passwords.
And I know that if said agency (it varies by country and target) could definitely hack the VPS if I was important enough, that is not part of my threat profile. Self hosted is far less likely to get auto vacuumed than SaaS data.
>> I don't want the X agency to force Bitwarden to give them my passwords.
Then you do not understand how bitwarden works,
Bit Warden has the same access to your passwords that Hetzner does, i.e they have only encrypted access to the binary storage.
The only thing agency X could get from bitwarden is an encrypted vault that is useless with out your master key, all encryption and decryption is done client side. THis by the way is the same access Hetzner would have to turn over if Agency X asks for a copy of your VM running vualtwarden
Those minimums are taken from Docker. The person above asked why they were what they were, I answered. You're just further reinforcing what I explained.
Running something in a Docker container adds very very little overhead - to the point that it's almost immeasurable. The resource utilization is specifically because of the services that have been packaged in the containers.
If you were running the Bitwarden server on bare metal (which you can definitely do), the requirements would still be the same.
HN has reached the point, that it will heavily downvote an objective fact because it goes against the pointed narrative. They took a dependency, copied its system requirements, and someone asks "why?" and that is the actual answer.
A lot of the other answers (multiple Dockers, slimmer image) really address how Docker themselves have these exact system requirements listed, but why do they need to when the point isn't to answer the actual request asked by get lost into a predisposed critique.
[1] https://bitwarden.com/help/install-on-premise-linux/