作者： Vaultwarden 与 Bitwarden 自托管版本对比
Bitwarden 官方版需 2GB 内存及十几个容器，而 Vaultwarden 仅需单个容器。本文对比两者资源占用、维护难度及架构差异，助您根据 VPS 性能选择最适合的密码管理方案。
Vaultwarden 和 Bitwarden 自托管版本的实际含义
Vaultwarden 与 Bitwarden 自托管版本之间的选择，是在两个使用相同客户端 API 的服务器之间做选择，而不是在两个密码管理器之间做选择。Bitwarden 官方堆栈在 nginx 后运行约十几个容器，使用 Microsoft SQL Server 存储所有数据，并且绑定到通过电子邮件地址注册的安装 ID。Vaultwarden 是使用 Rust 编写的 Bitwarden 客户端 API 非官方重新实现版本，以一个容器搭配一个 SQLite 文件运行。您的浏览器扩展和手机无法区分这两者，因为它们响应相同的端点。
无论选择哪一种，使用的加密方式都相同。Bitwarden 客户端会在数据离开设备前加密密码库，因此服务器存储的是自身无法读取的数据块；两种方案使用的密码库格式也都属于 Bitwarden。两者的差异在于您需要租用多少计算资源、由谁维护代码、哪些功能需要付费，以及需要备份哪些内容。
Vaultwarden 的 README 直截了当地说明了其定位：“此项目与 Bitwarden 或 Bitwarden, Inc. 没有关联。”这是一个志愿者项目，没有支持服务台，也不提供任何担保。一名活跃维护者在 Bitwarden 工作，并利用个人时间参与贡献；这属于个人支持，不代表 Bitwarden 的认可。
您可以安装的三种堆栈
大多数对比分析都忽略了 Bitwarden 提供两种不同的自托管产品这一事实。
Bitwarden standard。这是由 shell 脚本驱动的官方部署版本。
curl -Lso bitwarden.sh "https://func.bitwarden.com/api/dl/?app=self-host&platform=linux" \
&& chmod 700 bitwarden.sh
./bitwarden.sh install安装程序会询问您的域名、是否申请 Let's Encrypt 证书、从 https://bitwarden.com/host 输入邮箱获取的安装 ID 和密钥，以及您所在的区域（美国或欧盟）。./bitwarden.sh start 随后会拉取镜像并启动堆栈。Bitwarden 文档指出，最低配置要求为 2 GB 内存和 12 GB 存储空间，推荐配置为 4 GB 内存和 25 GB 存储空间，并要求 Docker Engine 26 或更高版本及 Compose 插件。数据库采用 MSSQL Express 镜像，Bitwarden 文档说明其关系型数据库的最大容量为 10 GB。如果该容量不足，您可以将部署指向外部数据库。
Bitwarden lite。这是以前称为 Bitwarden Unified 的部署版本。它于 2025 年 12 月结束测试并更名。它包含一个应用容器和您选择的数据库：
services:
bitwarden:
depends_on:
- db
env_file:
- settings.env
image: ghcr.io/bitwarden/lite
restart: always
ports:
- "80:8080"
volumes:
- bitwarden:/etc/bitwarden
db:
environment:
MARIADB_USER: "bitwarden"
MARIADB_PASSWORD: "super_strong_password"
MARIADB_DATABASE: "bitwarden_vault"
MARIADB_RANDOM_ROOT_PASSWORD: "true"
image: mariadb:10
restart: always
volumes:
- data:/var/lib/mysql
volumes:
bitwarden:
data:它支持 MariaDB 或 MySQL、PostgreSQL、SQLite 和 MSSQL，要求 200 MB 内存和 1 GB 存储空间。Bitwarden 的官方文档提出了两点注意事项：它被记录为适用于个人使用和家庭实验室，而非商业用途；且它不提供自动数据库备份，因此备份工作完全由您负责。
Vaultwarden。单个容器，直接来自项目 README：
docker run --detach --name vaultwarden \
--env DOMAIN="https://vw.domain.tld" \
--volume /vw-data/:/data/ \
--restart unless-stopped \
--publish 127.0.0.1:8000:80 \
vaultwarden/server:latest发布行将 8000 端口绑定到回环地址，这是有意为之。Vaultwarden 提供纯 HTTP 服务，并要求在其前端配置反向代理以终止 TLS（传输层安全）。此处 TLS 是必需的：Web 保险库使用浏览器的 WebCrypto API 进行加密，而浏览器仅在安全上下文中公开该 API，因此在纯 http 连接下，登录页面在浏览器端就会失败，请求根本不会到达您的服务器。完整的 Vaultwarden 安装指南 涵盖了代理和证书的相关配置。
Vaultwarden 与自托管 Bitwarden 共同运行时需要多少 RAM？
供应商给出的最低要求，说明的是安装程序拒绝运行的下限，而不是软件实际占用的资源。以下数据来自 docker stats --no-stream：每个实例处于空闲状态，各有 1 个用户、一个小型密码库且不含附件；测试环境为配备 4 GB RAM 的 Ubuntu 24.04 主机。磁盘占用包括镜像，以及首次成功启动后的数据目录。
此图表背后的数据
[
{
"label": "Vaultwarden (SQLite)",
"idle_ram_mb": 58,
"containers": 1,
"disk_gb": 0.4
},
{
"label": "Bitwarden lite + MariaDB",
"idle_ram_mb": 470,
"containers": 2,
"disk_gb": 1.6
},
{
"label": "Bitwarden standard (MSSQL)",
"idle_ram_mb": "2,400",
"containers": 12,
"disk_gb": 6.5
}
]Vaultwarden 在单个容器中空闲时占用 58 MB。标准 Bitwarden 堆栈在 12 个容器中空闲时占用约 2,400 MB，其中大部分由 MSSQL 容器占用。Bitwarden lite 与其 MariaDB 容器合计占用 470 MB，介于两者之间。在确认这些数据前，请在自己的主机上运行相同的命令，因为占用量会随用户数量、附件和同步流量变化；而且 MSSQL 运行时间越长，工作集通常越大。
对于小型 VPS，实际结论是：使用 SQLite 的 Vaultwarden 在 1 GB 方案上运行没有问题，而标准 Bitwarden 堆栈无法在该配置上启动。使用 2 GB 方案时，标准堆栈达到文档规定的最低要求，但留给操作系统的内存非常少，因此内核的 out-of-memory killer 可能会实际触发。触发后，dmesg 会输出一行日志，标明被终止的进程；在此堆栈中，该进程通常是 sqlservr。为标准部署分配 4 GB。如果同一台 VPS 还要运行多个密码库以外的服务，请在选择方案前先确认其他服务的内存下限，因为PhotoPrism 或 Immich 等照片服务器所需的内存远高于 Vaultwarden。不过，并非所有相邻服务都如此占用资源：例如将 Jellyfin 媒体库重新设计为 90 年代租赁店界面的 Halcyon只是一个浏览器前端，主要依赖其指向的媒体服务器，而不是自带数据库。需要检查的下限也不只有内存，因为用于远程桌面会话的 RustDesk 中继在 docker stats 中几乎不会产生明显占用，但会消耗方案的带宽配额。
Vaultwarden 中哪些付费功能免费？
运行 Bitwarden 服务器不收取费用，但付费功能在上传许可证文件前仍处于锁定状态。可自行托管的高级个人账户和付费组织方案需要许可证，包括 Families 和 Enterprise（Bitwarden 不提供 Teams 的自托管选项）。个人许可证可从云端 Web 保管库的 Settings，然后是 Subscription 中下载；组织许可证可从 Admin Console 的 Billing，然后是 Subscription 中下载。下载后，将许可证上传到自己的实例。组织许可证根据存储在 ./bwdata/env/global.override.env 中的安装 ID 签发。因此，自托管组织仍然持有付费订阅，并且仍会访问 Bitwarden 云端进行计费。
Vaultwarden 无需许可证或订阅即可启用相同功能。项目 wiki 列出了这些功能：
- 组织、集合和组
- 文件附件
- 通过电子邮件、Duo、YubiKey 和 FIDO2 进行两步登录
- Emergency Access
- Bitwarden Send
- 个人 API 密钥
- 通过 OpenID Connect 实现 SSO
SSO 是其中最新的功能，通过 SSO_ENABLED、SSO_AUTHORITY、SSO_CLIENT_ID 和 SSO_CLIENT_SECRET 配置。它只负责验证登录身份。wiki 明确说明，仍然需要主密码，且身份提供商不会控制该密码，因为主密码用于派生解密保管库的密钥。将 SSO_AUTHORITY 指向自托管的 Authentik 身份提供商的发现签发者，用户便可在那里登录，然后使用主密码解锁。该值必须与发现端点返回的 issuer 字段匹配，末尾不能包含 /.well-known/openid-configuration 后缀。
Vaultwarden 不提供的是厂商支持。Bitwarden 持有 SOC 2 Type 2 和 ISO 27001 认证，发布第三方审计报告，并运行私有 HackerOne 漏洞奖励计划。这些认证和报告针对的是 Bitwarden 的代码与服务，而不是你安装的服务器。但如果审计员要求密码管理器背后有明确的供应商，使用志愿者维护的重新实现版本会很难解释。
官方 Bitwarden 应用是否支持 Vaultwarden？
支持。Vaultwarden 实现了客户端 API，因此浏览器扩展、桌面应用、移动应用和内置 Web 保管库都可以连接到它。在每个客户端中，您需要在登录前的环境设置页面中填写自托管服务器 URL，而不是登录后再设置。
有一项功能需要额外配置：向移动应用发送推送通知。没有推送通知时，应用会在打开时或按自身计时器同步，因此您在笔记本电脑上修改密码后，手机不会立即显示更新，除非您打开应用查看。Vaultwarden 可以使用 Bitwarden 的推送中继服务，并且需要从官方安装程序使用的同一个 https://bitwarden.com/host 页面获取安装 ID 和密钥。
PUSH_ENABLED=true
PUSH_INSTALLATION_ID=<your installation id>
PUSH_INSTALLATION_KEY=<your installation key>EU 区域的服务器还需要 PUSH_RELAY_URI=https://api.bitwarden.eu 和 PUSH_IDENTITY_URI=https://identity.bitwarden.eu。Wiki 记录了两个值得在调试前了解的陷阱。通过 F-Droid 或 Neo Store 安装的应用不支持 Firebase，无论服务器如何配置，都不会收到推送通知。在 Vaultwarden 1.30.2 之前连接过的应用必须清除其数据，才能重新注册推送令牌。
重新实现是否安全？
Bitwarden 的审计历史悠久且公开。Cure53 在 2018、2021、2022、2023、2024 和 2025 年对其进行了审查；2025 年的审查覆盖浏览器扩展和自动填充浮层、核心应用、桌面应用、Web vault，以及 RustCrypto crate 和库。IOActive 和 Mandiant 在 2024 年审查了客户端，Fracture Labs 在 2024 和 2025 年开展了 Web 和网络评估，Unit 42 在 2025 年评估了移动应用，ETH Zurich Applied Cryptography Group 则在 2025 年审查了密码学实现。
Vaultwarden 也接受过外部审查，这可能出乎那些认为没人检查它的人意料。德国联邦信息安全办公室（BSI）让 mgm security partners 在 2024 年 2 月至 5 月期间，根据 Caos 3.0 代码分析项目对其进行测试；该审查将 2 个发现评为高风险。除此之外，ERNW 报告了一个影响 1.32.5 以下版本的身份验证绕过漏洞（CVE-2024-55225），该漏洞已于 2024 年 11 月修复。2026 年 7 月发布的 1.37.0 版本修复了通过图标端点实施的 SSRF（服务器端请求伪造）、跨组织密码套件访问，以及目录导入时绕过组织策略的问题。2026 年 10 月发布的 1.37.4 版本修复了另一批问题，其中包括一个影响组织成员撤销功能的高风险漏洞，以及双因素身份验证、组织邀请和附件相关的问题。
这些历史记录表明，该项目具备有效的漏洞披露流程。它们也指出了反复出现的攻击面：管理页面。因此，应将该页面视为敏感功能。除非设置了 ADMIN_TOKEN，否则它处于关闭状态；此外，应存储哈希值，而不是明文令牌。
docker run --rm -it vaultwarden/server /vaultwarden hash该命令会输出一个 Argon2 PHC 字符串（密码哈希竞赛格式），将其粘贴到 ADMIN_TOKEN 中。在启用管理页面前先启用 HTTPS，因为令牌会随请求发送；如果使用普通 HTTP 连接，路径上的任何设备都能读取明文令牌。实际风险主要来自该令牌和备份文件，而不是密码学实现；对运行中的实例进行加固会同时处理这两项。尽可能不要让 /admin 暴露在公网，并配合常规的主机加固措施，例如限制服务器上的 SSH 访问。
官方 API 变更导致的问题
这是人们低估的风险。Bitwarden 提供客户端，而这些客户端会在夜间自动从应用商店更新。Vaultwarden 必须跟进。当客户端版本变更导致 API 协议发生变化时，未升级的 Vaultwarden 会遇到已更新的客户端，导致您未操作的设备出现登录或同步失败。
发行说明中有一个具体示例。Vaultwarden 1.37.0 指出：“此更新是支持 2026.7.0+ 版本客户端所必需的，请在报告任何相关问题前先进行更新。”一个月后，于 2026 年 8 月 22 日发布的 1.37.2 版本对 2026.8.0 及更高版本的客户端重复了此警告，因此停留在 1.37.0 或 1.37.1 的服务器已落后于应用程序。截至 2026 年 10 月 27 日，当前版本为 1.37.4（发布于 2026 年 10 月 5 日），此前还有 9 月 13 日发布的 1.37.3。
两个习惯可以保持系统稳定。锁定特定的镜像标签而不是使用 latest，这样无人值守的拉取操作就不会在凌晨自动升级您的服务器。然后，密切关注发行动态并主动进行升级，升级前务必阅读说明，因为重大变更会在那里发布。1.37.2 的警告也发布在项目的 GitHub Discussions 中，并提供了服务器升级后客户端仍异常时的恢复步骤：注销并重新登录，清除应用或扩展缓存，仅在最后不得已时才重新安装移动应用或扩展。例如，1.35.5 版本在升级时使所有现有的双重验证“记住我”令牌失效，导致用户在认为已保存的状态下被强制登出。
Bitwarden 标准版部署则面临相反的问题。升级通过 ./bitwarden.sh updateself 和 ./bitwarden.sh update 进行，更新会执行数据库迁移。迁移前进行的备份无法回滚迁移后的架构，因此请务必在备份时记录对应的版本号。
备份：这是实际导致人们丢失密码库的地方
Vaultwarden 的数据目录就是服务器本身。请保留以下内容：
db.sqlite3- 所有
rsa_key*文件，包括rsa_key.pem和rsa_key.der attachments/config.jsonsends/
容器运行时，不要使用 cp 复制 db.sqlite3。SQLite 可能正在写入，因此复制结果可能是损坏的数据库；它在恢复前看起来可能完全正常。请改用在线备份 API：
sqlite3 data/db.sqlite3 ".backup '/path/to/backups/db-$(date '+%Y%m%d-%H%M').sqlite3'"从 1.32.1 开始，镜像中还提供内置的 /vaultwarden backup 命令。无论使用哪种方式，快照在移出之前仍与原始数据位于同一磁盘上，因此应按计划通过将 restic 快照保存到异地存储将其推送到其他服务器。一个悄悄停止运行的备份任务，与从未存在过的备份任务没有区别。因此，应让定时器将自身的失败报告到你能注意到的位置，这正是连接到 systemd OnFailure 单元的自托管 ntfy 服务器的用途。rsa_key 文件与数据库同样重要：服务器使用该密钥签署会话令牌。因此，将数据库恢复到一个新生成的密钥旁边，会使所有用户退出登录，并导致正在处理的组织邀请失效。
Bitwarden standard 会备份更多数据。只要 mssql 容器正在运行，它就会每晚将数据库备份写入 ./bwdata/mssql/backups，并保留最近 30 天的备份。你也可以手动触发备份：
docker exec -i bitwarden-mssql /backup-db.sh需要保留的目录包括 ./bwdata/env（环境变量，包括数据库和证书密码）、./bwdata/core/attachments、./bwdata/mssql/data 和 ./bwdata/core/aspnet-dataprotection。最后一个目录最容易被忽略。它包含框架级数据保护材料，包括身份验证令牌和部分数据库列。因此，如果不恢复该目录就恢复数据库，受其保护的列将无法读取。Bitwarden lite 完全不会自动备份，因此选择 lite 就意味着必须像使用 Vaultwarden 一样自行维护转储计划。
双向迁移
迁移通过客户端完成，而不是服务器，因为导出和导入都是客户端功能。因此，两个方向的操作流程相同。
每位用户都从 Web 保管库或桌面应用导出，在新服务器上创建账户，然后执行导入。格式包括明文 .json、明文 .csv、加密 .json，以及用于保存单个保管库中 JSON 和文件附件的 .zip。卡片、身份信息、已保存的通行密钥和 SSH 密钥只有在 JSON 格式中才能保留，因此使用 CSV 迁移会静默丢弃这些数据。任何导出格式都不包含回收站项目或发送内容，组织所有的数据也不属于个人导出内容。
请将明文导出视为实时机密，因为它确实是机密：整个保管库会以明文形式存储在磁盘上。应在同一次操作中完成导出、导入和删除。不要通过电子邮件或聊天发送明文导出文件。
迁移过程中有一个常见陷阱。与账户绑定的加密导出文件无法导入到其他账户，而迁移服务器必然意味着使用其他账户。请选择受密码保护的导出选项，因为这种格式可以移植。
从 Vaultwarden 迁移到标准 Bitwarden 更复杂，因为组织结构不会包含在导出文件中。您需要在新服务器上重新创建组织，再次邀请用户，并由每位用户导入自己的保管库。请提前安排维护窗口，不要等到迁移当天才发现这一点。
应选择哪一种？
如果您是个人用户、家庭用户，或在 1 GB、2 GB VPS 上运行家庭实验室，请使用 Vaultwarden。组织、紧急访问和 Send 都是免费功能，空闲内存开销大约相当于一个浏览器标签页，备份只需要一个 SQLite 文件和一个小目录。正因如此，Vaultwarden 在自托管密码管理方案中占据主导地位。
如果其他人依赖该服务开展专业工作，请使用 Bitwarden 官方服务器：例如公司需要支持合同、合规要求指定供应商，或您已经为企业功能付费。标准部署应分配 4 GB 内存，并将许可证文件和安装 ID 视为部署内容，而不是文档手续。
Bitwarden lite 处于一个尴尬的位置。它是供应商提供的代码，资源开销只有官方服务器的一小部分，这一点确实很有吸引力；但 Bitwarden 将其定位为个人和家庭实验室使用，而且不提供自动备份。您需要承担 Vaultwarden 的运维工作，却无法获得 Vaultwarden 的免费功能集。如果供应商代码对您的重要性高于功能，并且您愿意自行运行数据库，可以选择它。
如果您还在决定这台服务器将托管哪些其他服务，更广泛的自托管服务清单会将这个选择与其他争用相同内存的服务放在一起比较。
FAQ
Vaultwarden 足够安全，可以作为正式密码管理器吗？
对于个人和家庭使用，在满足一定条件的情况下可以。客户端会在保管库数据到达服务器前对其加密，因此 Vaultwarden 永远不会看到您的主密码或任何明文数据。它已经过外部评估：BSI 曾让 mgm security 合作伙伴在 2024 年 2 月至 5 月期间对其进行测试，ERNW 报告了一个已在 1.32.5 中修复的身份验证绕过漏洞。请保持版本最新，禁用管理页面，或将其置于 Argon2 哈希后的 ADMIN_TOKEN 保护之下，并且只通过 HTTPS 提供服务。需要供应商支持或审计文档的企业应运行 Bitwarden 自有服务器。
Vaultwarden 相比 Bitwarden self-hosted 需要多少 RAM？
根据使用 docker stats --no-stream 测量的空闲安装，使用 SQLite 的 Vaultwarden 在一个容器中约占 58 MB，而 Bitwarden 的标准部署在 12 个容器中约占 2,400 MB，其中大部分由 MSSQL 数据库占用。Bitwarden 文档将 2 GB 列为标准堆栈的最低要求，建议使用 4 GB；Bitwarden lite 需要 200 MB。Vaultwarden 运行在 1 GB VPS 上也有充足余量。
自托管需要 Bitwarden 许可证吗？
免费个人保管库不需要。运行服务器是免费的。要解锁个人高级功能和付费组织计划，需要许可证文件；Families 和 Enterprise 是 Bitwarden 允许您自托管的仅有组织计划。您可以从云端 Web 保管库下载许可证文件，然后将其上传到您的实例；组织许可证会根据存储在 ./bwdata/env/global.override.env 中的安装 ID 签发。Vaultwarden 不需要许可证，并会自行启用组织功能。
以后可以从 Vaultwarden 迁移到 Bitwarden，或反向迁移吗？
可以，两个方向都可以通过客户端完成。每位用户都可以从 Web 保管库或桌面应用导出其保管库，在新服务器上创建账户后，再将其导入新服务器。.zip 导出格式会携带个人保管库的附件，JSON 格式会携带卡片、身份信息、通行密钥和 SSH 密钥。回收站项目和 Sends 不包含在任何导出格式中，组织拥有的项目也必须由所有者单独导出。因此，请计划在新服务器上重新创建组织并重新邀请用户。