背景

刚刚收到github的邮件,讲再不配置2FA验证将无法登录,直到配置完

刚好先前从谷歌自带密码管理工具 转到 Vaultwarden和Bitwarden浏览器扩展 刚好支持TOTP

介绍

Vaultwarden 和 Bitwarden 是两款密切相关的密码管理工具,但它们的定位和使用场景有所不同。以下是它们的核心区别和选择建议:

1. 基本概念

  • Bitwarden

    • 官方产品:由 Bitwarden 公司开发的密码管理器,提供客户端(浏览器插件、手机 App 等)和官方服务器端。

    • 功能全面:支持个人免费使用,也提供付费高级功能(如 TOTP 两步验证、紧急访问等)和企业级服务(SSO、目录同步等)。

    • 云托管或自托管:用户可直接使用官方的云服务,也可自行部署官方服务器(需较高资源)。

  • Vaultwarden

    • 第三方实现:原名 Bitwarden_rs,是社区开发的 Bitwarden 服务器兼容替代方案,使用 Rust 编写。

    • 轻量自托管:专为个人或小团队自托管设计,资源占用极低(适合树莓派等设备)。

    • 兼容性:完全兼容 Bitwarden 客户端,但不支持官方企业功能(如 SSO、目录同步)。

2. 主要区别

对比项

Bitwarden (官方)

Vaultwarden

资源占用

较高(需至少 2GB 内存)

极低(约 50MB 内存)

部署难度

复杂(依赖较多)

简单(Docker 一键部署)

功能支持

完整功能,含企业级服务

支持个人/家庭功能,无企业功能

维护方

Bitwarden 公司

开源社区维护

授权协议

部分功能需付费订阅

完全免费(AGPL 开源协议)

适用场景

企业、需高级功能的用户

个人、小团队、低资源环境自托管

3. 如何选择?

  • 选择 Bitwarden 官方版

    • 需要企业级功能(如 SSO、审计日志、目录同步)。

    • 不愿自行维护服务器,直接使用官方云服务(安全性由专业团队保障)。

    • 需要官方技术支持或付费订阅的高级功能。

  • 选择 Vaultwarden

    • 希望自托管且资源有限(如 NAS、树莓派)。

    • 仅需基础密码管理功能(如密码存储、TOTP、附件)。

    • 倾向于开源免费方案,无需企业功能。

4. 注意事项

  • 安全性:两者均使用 AES-256 加密,但自托管时需自行保障服务器安全。

  • 客户端兼容性:两者使用相同的客户端(如浏览器插件、手机 App),用户体验一致。

  • 功能差异:Vaultwarden 不支持 Bitwarden 的企业功能,但社区可能提供额外插件(如简单的用户管理)。

总结

  • 个人/小团队自托管:优先选 Vaultwarden(轻量、易用、免费)。

  • 企业/高级需求:选择 Bitwarden 官方版(功能全面、支持可靠)。

如果需要进一步部署指导,可参考各自的官方文档:

Vaultwarden

启用SMTP邮箱功能

重点

在配置中,若使用163邮箱,则需设置SMTP_SECURITY=force_tls

可以在.env中配置,也可以直接写在docker-compose.yml的environment:中

假设项目结构如下:

/srv/vaultwarden/
├── docker-compose.yml
└── data/

然后写入以下内容:

version: "3.8"

services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped

    environment:
      # 邮件服务配置
      - SMTP_HOST=smtp.163.com
      - SMTP_PORT=465
      - SMTP_SECURITY=force_tls
      - SMTP_USERNAME=example@163.com
      - SMTP_PASSWORD=abcd1234efgh5678   # 注意:使用授权码
      - SMTP_FROM=example@163.com
      - SMTP_FROM_NAME=Vaultwarden 通知服务

      # 管理员面板令牌(请替换为随机字符串)
      - ADMIN_TOKEN=super_secret_admin_token

      # 可选调试日志
      - SMTP_DEBUG=true

    volumes:
      - ./data:/data
    ports:
      - "8080:80"

📤 配置参数解释

变量名

含义

示例值

SMTP_HOST

邮件服务器地址

smtp.163.com

SMTP_PORT

邮件端口

465

SMTP_SECURITY

安全协议,465端口(使用163邮箱时)必须 force_tls

force_tls

SMTP_USERNAME

登录用户名

example@163.com

SMTP_PASSWORD

邮箱授权码

abcd1234efgh5678

SMTP_FROM

发件邮箱(必须与用户名一致)

example@163.com

SMTP_FROM_NAME

发件人显示名称

Vaultwarden 通知服务

ADMIN_TOKEN

管理员登录令牌

任何安全字符串

SMTP_DEBUG

输出调试日志

true 可选

使用.env与直接在docker-compose.yml中配置的区别与优缺点

几乎所有基于 Docker 的应用在配置环境变量时,都可以通过 .env 文件 docker-compose.yml 内的 environment: 段来实现,两者在效果上功能完全等价,但在管理、可移植、安全性与维护上存在明显差异。

下面我帮你从结构、优缺点、使用场景三方面详细讲清楚 👇

🧩 一、两种配置方式对比概览

对比项

.env 文件

docker-compose.yml 中的 environment

定义位置

docker-compose.yml 同目录,单独文件

直接写在 Compose 配置内

作用方式

Compose 会自动读取 .env 中的变量,并在 docker-compose.yml 中替换

Compose 将变量直接传入容器

优先级

在 Compose 中变量展开时优先使用 .env

明确写在 environment: 下的优先级更高

典型用途

保存敏感配置(密码、密钥)或环境相关参数

直接写死配置,快速启动

迁移/复用性

高,可在不同部署环境复用同一套 compose 文件

低,每次部署都要改 YAML

安全性

较好(可以单独管理权限、不进 Git)

差一些,容易被误传入版本库

可读性

环境变量集中、清晰

配置集中但可能太长

变量引用

支持 ${VAR_NAME} 语法在 Compose 中展开

不支持引用其他变量

⚙️ 二、实际效果对比

🅰️ 使用 .env 文件

目录结构:

/srv/vaultwarden/
├── docker-compose.yml
└── .env

.env 内容:

SMTP_HOST=smtp.mailgun.org
SMTP_PORT=587
SMTP_SECURITY=starttls
SMTP_USERNAME=postmaster@yourdomain.com
SMTP_PASSWORD=very_secret_password
SMTP_FROM=notify@yourdomain.com
SMTP_FROM_NAME=Vaultwarden

docker-compose.yml 内容:

version: "3"
services:
  vaultwarden:
    image: vaultwarden/server:latest
    environment:
      - SMTP_HOST=${SMTP_HOST}
      - SMTP_PORT=${SMTP_PORT}
      - SMTP_SECURITY=${SMTP_SECURITY}
      - SMTP_USERNAME=${SMTP_USERNAME}
      - SMTP_PASSWORD=${SMTP_PASSWORD}
      - SMTP_FROM=${SMTP_FROM}
      - SMTP_FROM_NAME=${SMTP_FROM_NAME}
    ports:
      - "8080:80"
    volumes:
      - ./data:/data

优点:

  • .env 可以放在服务器上,不进版本库;

  • 同一份 compose 文件可以被多个环境(测试/生产)共用;

  • 修改邮箱配置时只需改 .env,不用重写 compose 文件;

  • 方便用脚本、CI/CD 自动替换。

🅱️ 全写入 docker-compose.yml
version: "3"
services:
  vaultwarden:
    image: vaultwarden/server:latest
    environment:
      - SMTP_HOST=smtp.mailgun.org
      - SMTP_PORT=587
      - SMTP_SECURITY=starttls
      - SMTP_USERNAME=postmaster@yourdomain.com
      - SMTP_PASSWORD=very_secret_password
      - SMTP_FROM=notify@yourdomain.com
      - SMTP_FROM_NAME=Vaultwarden
    volumes:
      - ./data:/data
    ports:
      - "8080:80"

优点:

  • 结构直观,单文件部署;

  • 复制到别的机器即能直接启动;

  • 适合本地快速测试或临时部署。

⚠️ 缺点:

  • 配置文件冗长;

  • 密码容易泄露(进 git、CI、日志);

  • 更改变量需重写 compose 文件;

  • 不易复用多套环境(如测试/正式不同 SMTP)。

🧠 三、优缺点总结(简表)

场景

推荐方式

原因

🧪 本地测试 / 单机快速起容器

docker-compose.yml 直接写

改一次就行,方便启动

🏭 生产环境部署

.env 文件

可隐藏敏感信息、易维护

🚀 CI/CD 自动化

.env + 环境变量注入

安全可控、便于替换

🧩 多环境共用模板(dev/stage/prod)

.env

灵活切换

🔐 涉及账号密码等敏感配置

.env

.gitignore 隐藏

🔒 四、安全与维护建议

  1. 不要把 .env 提交进 Git 仓库
    添加到 .gitignore

    .env
  2. 备份 .env 文件
    尤其 Vaultwarden 邮件、管理员密钥、数据库路径等。

  3. 在生产服务器上权限限制

    chmod 600 .env
    
  4. 变更配置后重新部署
    每次修改 .env 后需执行:

    docker-compose down && docker-compose up -d
    

✅ 五、推荐实践(Vaultwarden)

我建议这样做:

  • .env 管理所有敏感或环境依赖的配置(如 SMTP、DOMAIN、ADMIN_TOKEN);

  • Compose 文件只定义结构与变量引用;

  • 版本库中保留 .env.example 模板:

.env.example

SMTP_HOST=
SMTP_PORT=
SMTP_SECURITY=starttls
SMTP_USERNAME=
SMTP_PASSWORD=
SMTP_FROM=
SMTP_FROM_NAME=Vaultwarden
ADMIN_TOKEN=

实际部署时复制:

cp .env.example .env
nano .env

使用——以GitHub的2FA为例

通常在服务器上搭建Vaultwarden,在谷歌浏览器安装插件Bitwarden,手机安装软件Bitwarden

保存TOTP

使用TOTP

通行密钥

注意

一定要保存好二次验证恢复码

参考

2023重制版本!10分钟搭建一个专属的密码管理工具——Vaultwarden_哔哩哔哩_bilibili

集成的验证器 | Bitwarden 帮助中心中文版

关于双重身份验证 - GitHub 文档

关于密钥 - GitHub 文档