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 11I assume bitwarden's implementation has been more thoroughly reviewed.
Assuming there is a critical bug in vaultwarden, what is the severity/what information is exposed? Is it relatively safe even then because of the E2E?
But... that seems reasonably unlikely.
> 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?
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.
----
0: https://github.com/slackhq/nebula
1: https://arstechnica.com/gadgets/2019/12/how-to-set-up-your-o... (note 3 years old, there are now Android/iOS clients as well and things are further refined)
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.
TL;DR: ZeroTier is not based on 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
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.
There's a very big gap between a warrant and a torture kidnapping. Self-hosting protects a lot of that gap.
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
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.
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.
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.
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 have a hard-to-guess master password, but it wouldn't surprise me if they could crack it with a 2026 vintage GPU farm.
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.
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.
Who would trust their passwords to a service with such a clause?
Well, yes, after adding photo gallery, I now want a faster device.
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.
If you were running the Bitwarden server on bare metal (which you can definitely do), the requirements would still be the same.
- https://docs.docker.com/desktop/install/linux-install/
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.
Side note: WTF is Docker Desktop on Linux using a VM? I can't even.
With the requirements on here: https://docs.docker.com/engine/install/binaries/
It doesn't even mention space because it's negligible. dockerd uses a few megabytes of ram and around 100MB of drive.
Having facts doesn't always mean you're right. Sometimes it's the wrong facts.