I Do Not Recommend Bitwarden

我不再推荐 Bitwarden

A review of my experience with Bitwarden after several years of self-hosting it, and why I decided to move away from the password manager. 回顾我自托管 Bitwarden 多年后的使用体验，以及我决定弃用这款密码管理器的原因。

Almost four years ago I published a guide on how to run your own LastPass on hardened OpenBSD, in which I explained how to set up an OpenBSD instance, either as a cloud instance or as a Raspberry Pi bare metal installation, that would host Vaultwarden as a backend for the Bitwarden client applications. After having used a similar approach for myself for several years now, I came to the conclusion that I do not recommend the use of Bitwarden any longer. Let me explain. 大约四年前，我发布了一篇关于如何在加固后的 OpenBSD 上运行个人版“LastPass”的指南。文中我解释了如何设置一个 OpenBSD 实例（无论是云实例还是树莓派裸机安装），并将其作为 Bitwarden 客户端的后端来托管 Vaultwarden。在亲身实践并使用了几年类似方案后，我得出的结论是：我不再推荐使用 Bitwarden。让我来解释一下原因。

Freemium dual-license password manager

免费增值双重许可的密码管理器

Wikipedia describes Bitwarden as _a freemium open-source password management service that is used to store sensitive information […] owned and developed by Bitwarden, Inc., and that is now almost ten years old. The company behind the software is not only developing the Bitwarden server, as well as client applications for most platforms, but it is also offering a SaaS product for users who don’t want to put up with hosting this unwieldy beast on their own. More on this in just a moment. 维基百科将 Bitwarden 描述为“一种用于存储敏感信息的免费增值开源密码管理服务……由 Bitwarden, Inc. 拥有和开发，至今已有近十年历史。”这家软件背后的公司不仅开发 Bitwarden 服务器及大多数平台的客户端应用，还为那些不想自行托管这个“笨重巨兽”的用户提供 SaaS 产品。稍后我会详细说明这一点。

Bitwarden’s pricing for their hosted offering is similar to their competitors’ offerings, albeit with differences in terms of functionality. Regardless of whether one picks their hosted offering or decides to self-host, however, the client applications remain the same. Bitwarden 的托管服务定价与竞争对手相似，尽管在功能上存在差异。然而，无论用户选择其托管服务还是决定自行托管，客户端应用本身是完全一样的。

Since 2022, Bitwarden is also backed by $100M of PSG growth equity, joined by Battery Ventures. A password manager that wants to remain open-source is one thing, but the same password manager with an investor on its board that needs to see a return on $100M is another. Without wanting to sound overly cynical, this is usually the point in time in which the rent-seeking begins and the product slowly shifts from serving its users to serving its investors. 自 2022 年起，Bitwarden 获得了 PSG 增长股权投资的 1 亿美元注资，Battery Ventures 也参与其中。一个想要保持开源的密码管理器是一回事，但一个董事会里坐着需要 1 亿美元回报的投资人的密码管理器则是另一回事。我不想显得过于愤世嫉俗，但这通常是“寻租”行为开始的时刻，产品也会慢慢从服务用户转向服务投资者。

Unwieldy beast

笨重的巨兽

If you decide to self-host Bitwarden, however, you will relatively quickly find yourself in what I would describe as enterprise software hell. The standard Bitwarden server deployment is a heavy-weight C# backend that ships with MSSQL Express and won’t work with more Linux-native databases like PostgreSQL or MariaDB. Depending on the size of the deployment and the requirements with regard to high availability, you might want to utilize Kubernetes, which in turn adds additional overhead and complexity. 如果你决定自托管 Bitwarden，你会很快陷入我所说的“企业软件地狱”。标准的 Bitwarden 服务器部署是一个重量级的 C# 后端，捆绑了 MSSQL Express，且无法与 PostgreSQL 或 MariaDB 等更符合 Linux 原生特性的数据库兼容。根据部署规模和高可用性需求，你可能还需要使用 Kubernetes，这又增加了额外的开销和复杂性。

Because of this, many smaller to medium-sized deployments prefer to look into Vaultwarden instead, which is an unofficial Bitwarden-compatible server written in Rust™. The simple and lightweight nature of Vaultwarden compared to the official Bitwarden server makes such a big difference for administrators that the unofficial server project has seemingly three times the stargazers on GitHub as compared to Bitwarden’s official implementation. This should make you think, especially as a series B-funded company with $100M, whether your (technical) users appreciate the current direction your software stack is heading towards, or whether you might want to look into bringing the people that built a vastly more successful backend implementation on-board to optimize and accelerate your official stack. 正因如此，许多中小型部署更倾向于使用 Vaultwarden，这是一个用 Rust 编写的非官方 Bitwarden 兼容服务器。与官方服务器相比，Vaultwarden 的简洁轻量为管理员带来了巨大的差异，以至于该非官方项目在 GitHub 上的星标数量似乎是 Bitwarden 官方实现的三倍。这应该引发思考：特别是作为一家获得 1 亿美元 B 轮融资的公司，你的（技术）用户是否认可你软件栈当前的发展方向？或者，你是否应该考虑吸纳那些构建了更成功后端实现的人才，来优化和加速你的官方技术栈？

And surely that’s what Bitwarden decided to do, right? 当然，Bitwarden 肯定就是这么做的，对吧？

Bitwarden lite

Bitwarden 精简版

Sadly, however, it seems that Bitwarden’s NIH syndrome was too strong to simply take over Vaultwarden as an official project. Instead, the company seemingly hired the main developer of the Vaultwarden project and decided to publish a “lighter” version of their existing backend dubbed Bitwarden unified lite, which is still a service built on Microsoft’s .NET, and which still appears to require more than three times the RAM a Vaultwarden instance usually consumes. 遗憾的是，Bitwarden 的“非我所创症候群”（NIH syndrome）似乎太严重了，以至于无法直接将 Vaultwarden 作为官方项目接管。相反，该公司似乎雇佣了 Vaultwarden 项目的主要开发者，并决定发布一个名为“Bitwarden unified lite”的现有后端“精简版”。它依然是基于微软 .NET 构建的服务，且其内存占用似乎仍是 Vaultwarden 实例通常消耗的三倍以上。

Regarding the open-source part of Bitwarden, things have been getting murkier over the past year or so. In late 2024, users started noticing that a new dependency, @bitwarden/sdk-internal, had been pulled into the clients. Its license read: 关于 Bitwarden 的开源部分，过去一年左右的情况变得愈发模糊。2024 年底，用户开始注意到客户端中引入了一个新的依赖项 @bitwarden/sdk-internal。其许可证写道：

You may not use this SDK to develop applications for use with software other than Bitwarden (including non-compatible implementations of Bitwarden) or to develop another SDK. “你不得使用此 SDK 开发用于 Bitwarden 以外软件（包括非兼容的 Bitwarden 实现）的应用程序，也不得使用它开发其他 SDK。”

For a product that prides itself on being open-source, this is a fairly significant plot twist. After considerable backlash in the community, however, Bitwarden called it a “packaging bug” and eventually relicensed the SDK under GPLv3. Technically, the issue is resolved. Philosophically, however, this episode tells you all you need to know about where Bitwarden is heading: The freeware parts are bait, the actual product is the SaaS subscription, and the community is there to contribute issues and translations as long as it doesn’t cost the company anything. 对于一个以开源为傲的产品来说，这是一个相当重大的剧情反转。在社区引发强烈抵制后，Bitwarden 将其称为“打包错误”，并最终将该 SDK 重新授权为 GPLv3。从技术上讲，问题解决了。但从理念上讲，这一插曲足以让你看清 Bitwarden 的走向：免费部分只是诱饵，真正的产品是 SaaS 订阅，而社区的存在只是为了在不增加公司成本的前提下贡献问题反馈和翻译。

The real culprit

真正的罪魁祸首

Setting aside the backend, however, the real culprit with regard to Bitwarden are the client applications. Advertised functions do not work as expected, basic features are non-existent (after ten years!) and the user interface is poor to put it mildly, especially when compared to equally priced alternatives. And don’t get me wrong, if Bitwarden was purely a FOSS-effort and not funded by venture capital all these flaws could be brushed aside because, after all, it would be a community effort. However, Bitwarden isn’t a community effort, which is reflected very noticeably in the bureaucratic processes they drowned the community in, but more on this in a moment. 抛开后端不谈，Bitwarden 真正的罪魁祸首是客户端应用。宣传的功能无法按预期工作，基础功能缺失（十年了！），用户界面用委婉的话说就是很差，尤其是与同价位的替代品相比时。别误会，如果 Bitwarden 纯粹是一个自由开源软件（FOSS）项目，且没有风险投资支持，所有这些缺陷都可以被忽略，毕竟这是社区的努力。然而，Bitwarden 并非社区项目，这一点在他们让社区深陷其中的官僚流程中体现得非常明显，稍后我会详细说明。

Migrating vaults

迁移保管库

About a year ago, I supported someone who tried to switch from a competitor to Bitwarden under the thought of rather supporting open-source software with a yearly subscription than some proprietary platform that one has no insights into. Part of the migration was naturally importing existing vaults from the previous password manager into the new Bitwarden account. As can be seen in my bug report on GitHub, however, this went sideways very quickly, and resulted in at least one vault requiring significant technical workarounds for the import to work. 大约一年前，我协助某人从竞争对手切换到 Bitwarden，因为他认为与其使用不透明的专有平台，不如通过年度订阅来支持开源软件。迁移的一部分自然是将现有的保管库从之前的密码管理器导入到新的 Bitwarden 账户中。正如我在 GitHub 上的错误报告中所述，这个过程很快就出了岔子，导致至少有一个保管库需要大量的技术变通才能完成导入。