通过CloudFlare部署VaultWarden
本文最后更新于 2026年2月9日 上午
通过CloudFlare部署Bitwarden轻量替代方案Warden
首先非常要感谢文末的两位开源作者和CF大善人，博主最近在b站偶然发现Github上这个开源项目，因为部署起来比较方便，而且不需要vps服务器，很适合需要搭建自托管密码管理服务但是又没有服务器的开发者。
一、引言
对于关注隐私的技术爱好者来说，自托管密码管理器是一个绕不开的话题。官方的 Bitwarden 服务器架构较重，不仅对服务器配置有要求，部署维护也相对麻烦。而 Warden 的出现提供了一种轻量级的替代方案，它基于 Cloudflare Workers 和 D1 数据库构建，完美利用了 Serverless 架构的优势。
这套基于 GitHub Actions 的开源自动化部署方案。配置好之后，我们只需要专注于代码本身，剩下的构建、发布工作交给流水线自动完成即可，用起来无论是部署还是备份都很方便，几分钟就可以完成系列任务。
二、部署前的准备说明
整个部署流程分为4个核心阶段：Cloudflare侧准备（必须手动操作，搭建基础环境）、GitHub侧配置（配置自动化权限）、执行部署（触发GitHub Actions工作流）、后期配置（完善运行环境，确保可用）。
我们需要提前准备好：Cloudflare账号（已绑定域名更佳）、GitHub账号、Warden项目代码（可直接Fork官方仓库），全程无需复杂的本地环境配置，跟着步骤操作即可。
三、第一阶段：Cloudflare侧准备（手动操作，核心基础）
在触发自动化部署前，我们需要先在Cloudflare控制台搭建好所需的基础设施和权限，这一步是部署成功的关键，不能跳过。
3.1 获取Account ID
Account ID是Cloudflare账号的核心标识，后续GitHub Actions需要用它关联我们的Cloudflare账号。
登录Cloudflare控制台（https://dash.cloudflare.com/）；
在控制台右侧边栏，或者浏览器地址栏中，找到并复制你的「Account ID」（一串英文+数字的组合）；
暂时保存下来，后续配置GitHub Secrets时会用到。
3.2 创建API Token（关键权限配置）
API Token用于GitHub Actions授权操作Cloudflare的Worker、D1等服务，权限配置必须准确，否则会导致部署失败。
在Cloudflare控制台，点击右上角头像，选择「My Profile」（我的个人资料）；
在左侧菜单中找到「API Tokens」，点击「Create Token」（创建令牌）；
重点配置权限，该Token必须拥有以下3类权限（缺一不可）：
Account - Cloudflare Workers - Edit（编辑Worker服务的权限）；
Account - D1 - Edit（编辑D1数据库的权限，Warden用于存储密码数据）；
Account - Cloudflare KV - Edit（如果需要用KV存储附件，必须添加）。
配置完成后，点击创建，务必立即保存生成的API Token（刷新页面后会隐藏，无法再次查看）。
提示：我第一次部署时，漏加了KV的Edit权限，导致GitHub Actions运行失败，排查了很久才发现是权限问题，大家一定要仔细核对。
3.3 创建D1数据库
D1是Cloudflare推出的轻量SQL数据库，Warden的所有密码数据都会存储在这里，数据库名称需与后续配置保持一致。
进入Cloudflare控制台，点击左侧菜单「Workers & Pages」，再选择「D1」；
点击「Create database」（创建数据库），输入数据库名称；
关键注意点：根据Warden的工作流文件（push-cloudflare.yaml）默认配置，数据库名称推荐设为「vault1」，如果想自定义名称，后续需要修改wrangler.toml中的对应配置，否则会部署失败；
数据库创建完成后，记录下「Database ID」，后续配置GitHub Secrets时会用到。
3.4 （可选）创建R2存储桶
如果我们需要用Cloudflare R2存储密码附件（如文件、图片），可以创建R2存储桶，无需附件功能可跳过此步骤。
进入Cloudflare控制台，点击左侧菜单「Storage & databases」，选择「R2」；
点击「Create bucket」（创建存储桶），输入存储桶名称（例如「warden-attachments」）；
创建完成后，记录下存储桶名称，后续配置GitHub Secrets时会用到。
四、第二阶段：GitHub仓库配置（准备自动化部署）
我们先将Warden项目Fork到自己的GitHub账号，然后配置Secrets（敏感信息）和Variables（可选配置），让GitHub Actions拥有操作Cloudflare的权限。
4.1 Fork Warden项目（前提步骤）
打开作者的GitHub仓库:https://github.com/qaz741wsd856/warden-worker，点击右上角「Fork」，将项目复制到自己的GitHub账号下，后续所有操作都在自己Fork的仓库中进行。
4.2 配置Repository Secrets（核心步骤）
Secrets用于存储敏感信息（如API Token、数据库ID），GitHub会对其进行加密，避免泄露，所有必填的Secrets都必须准确添加。
进入自己Fork的Warden仓库页面，点击顶部「Settings」（设置）；
在左侧菜单中找到「Secrets and variables」，选择「Actions」；
点击「New repository secret」（新建仓库密钥），依次添加以下4个必填Secrets：
名称：CLOUDFLARE_API_TOKEN，值：第一阶段创建并保存的API Token；
名称：CLOUDFLARE_ACCOUNT_ID，值：第一阶段获取的Account ID；
名称：D1_DATABASE_ID，值：第一阶段获取的D1数据库ID；
如果创建了R2存储桶，需额外添加：名称：R2_NAME，值：创建的R2存储桶名称。
每个Secrets添加完成后，点击「Add secret」保存，确保所有值都没有输入错误（空格、大小写都会导致失败）。
4.3 配置Variables（可选，覆盖默认设置）
Variables用于配置非敏感的自定义参数，无需修改默认设置可跳过，需要自定义时按以下步骤操作：
在「Secrets and variables」→「Actions」页面，点击「Variables」选项卡；
点击「New repository variable」，可添加以下可选变量：
BW_WEB_VERSION：自定义Web Vault前端版本，默认是v2025.12.0，可设为「latest」（最新版本）或其他具体版本号；
SEED_GLOBAL_DOMAINS：设为「false」可跳过域名数据播种，默认无需修改。
五、第三阶段：执行部署（触发GitHub Actions）
配置完成后，我们只需触发GitHub Actions工作流，它就会自动完成环境安装、代码构建、部署到Cloudflare的全流程，无需手动干预。
5.1 触发工作流（两种方法，推荐方法A）
方法A：推送代码触发
只需对自己fork的仓库做一次微小修改（比如修改README.md的一个字符），然后推送到main分支，即可自动触发工作流。
原理：GitHub Actions默认配置了「push到main分支触发部署」，这种方法无需手动操作，后续更新代码时也能自动重新部署。
方法B（推荐）：手动触发
进入仓库的「Actions」标签页；
在左侧工作流列表中，选择「Build」工作流；
点击「Run workflow」（运行工作流），在弹出的窗口中直接点击「Run workflow」，即可手动触发部署。
5.2 监控部署进度
触发工作流后，点击对应的运行记录，即可查看实时部署日志，工作流会自动执行以下操作，我们只需耐心等待（全程约5-10分钟）：
安装Rust和Node环境（Warden依赖这两个环境构建）；
下载并处理Web Vault前端文件（用于密码管理的Web界面）；
检查D1数据库是否为空，如果为空，自动执行schema.sql和数据迁移（初始化数据库结构）；
编译Warden代码，并部署到Cloudflare Worker。
提示：如果部署失败，查看日志中「Failed」的部分，大概率是权限配置错误（Secrets值错误、API Token权限不足）或数据库名称不匹配，对照前面的步骤排查即可。
六、第四阶段：后期配置（确保服务可用）
代码部署成功后，Warden服务虽然已经在Cloudflare上运行，但还需要配置运行时密钥、自定义域名等，才能正常注册和登录，这一步是收尾关键。
6.1 设置运行时环境变量（核心步骤）
这些变量用于Warden的身份验证和权限控制，必须正确配置，否则无法注册账号。
回到Cloudflare控制台，点击左侧「Workers & Pages」，找到刚刚部署的Warden Worker（名称通常与GitHub仓库名称一致）；
点击Worker名称，进入详情页，选择顶部「Settings」（设置），再找到「Variables and Secrets」；
点击「Add secret」（添加密钥），依次添加以下3个加密变量（Secret）：
ALLOWED_EMAILS：允许注册的邮箱，格式为「your-email@example.com」，多个邮箱用逗号分隔，也可用通配符「*@example.com」（允许该域名下所有邮箱注册）；
JWT_SECRET：一个长且随机的字符串，用于生成身份验证令牌，务必生成强密码（可使用密码生成器，长度建议16位以上）；
JWT_REFRESH_SECRET：另一个长且随机的字符串，用于刷新身份验证令牌，与JWT_SECRET不重复即可。
所有变量添加完成后，无需重启Worker，配置会自动生效。
6.2 配置自定义域名（强烈推荐）
Cloudflare Worker默认的「*.workers.dev」域名可能会出现无法访问的情况，且不够简洁，配置自己的域名能提升稳定性和易用性。
- 进入Cloudflare控制台，找到你要使用的域名（已添加到Cloudflare的域名），点击进入域名管理页；
- 回到Warden Worker的设置页，点击「Domains & Routes」（域名和路由），再点击「Add Route」（添加路由）；
- 在「Route」中输入「vault.example.com/*」（替换成你的子域名+域名），在「Worker」中选择部署的Warden Worker，点击「Save」保存。
6.3 配置客户端（完成最后一步）
配置完成后，我们可以用Bitwarden客户端（App、浏览器扩展）连接自托管的Warden服务，开始使用。
打开Bitwarden客户端（可在官网下载，支持全平台）；
在登录页面，选择「自托管环境」（或「Server URL」）；
输入我们刚才配置的自定义域名（比如「https://vault.example.com」），点击确认；
使用ALLOWED_EMAILS中配置的邮箱，注册账号并登录，即可正常使用自托管的Warden密码管理器。
七、部署总结与避坑清单
至此，我们已经完成了用GitHub Actions自动化部署Warden到Cloudflare的全流程。整个流程的核心是「一次配置，终身受益」——后续只要更新GitHub仓库代码，GitHub Actions就会自动重新部署，无需再手动操作Cloudflare和GitHub之间的关联。
根据我的部署经验，总结几个常见坑，大家可以重点注意：
API Token权限一定要配置完整，漏加D1或KV权限会导致部署失败；
D1数据库名称推荐设为「vault1」，避免修改配置文件带来的额外麻烦；
Secrets中的值不能有空格、大小写错误，否则GitHub Actions无法正常授权；
自定义域名的DNS记录必须开启「Proxied」，否则无法访问Worker服务。
最后，附上部署完成的检查清单，大家可以对照核对，确保所有步骤都已完成：
- Cloudflare：创建API Token（含Workers、D1、KV权限）
- Cloudflare：创建D1数据库（推荐命名为「vault1」）
- Cloudflare：（可选）创建R2 Bucket
- GitHub：添加Secrets（CLOUDFLARE_API_TOKEN、CLOUDFLARE_ACCOUNT_ID、D1_DATABASE_ID、R2_NAME）
- GitHub：运行「Build」Action进行部署
- Cloudflare：在Worker Settings中添加ALLOWED_EMAILS、JWT_SECRET、JWT_REFRESH_SECRET
- Cloudflare：配置DNS（Proxied）和Worker Routes（自定义域名）
- 客户端：登录测试，确认服务可用