博文概览 #
你是不是也有这种纠结：想用密码管理器，但又不太想把整份密码库交给第三方；想自托管，又不想为了一个密码库专门养 VPS、配数据库、折腾反代和证书。
NodeWarden 刚好卡在这个位置：它是一个运行在 Cloudflare Workers 上的 Bitwarden 兼容服务端，能接 Bitwarden 的客户端生态，又把部署和运行交给 Cloudflare 这套托管基础设施。
先把丑话说前面：密码库不是图床，丢了、泄了、误删了，都不是“再传一张图”能解决的事。本文只讲部署流程，不替你承诺绝对安全。正式使用前至少做到：
- 主密码足够强
JWT_SECRET用随机强密钥，别用示例值- 定期导出或远程备份
- 重要账号别只压在一个自托管服务上
这篇文章做四件事：
- Fork NodeWarden 项目，并开启上游同步
- 在 Cloudflare Workers & Pages 里从 GitHub 部署
- 根据首次访问提示补齐 Secret/变量
- 绑定自定义域名，让它变成自己的密码库入口
0. 先讲清楚：NodeWarden 是什么 #
NodeWarden 的定位很直接：运行在 Cloudflare Workers 上的 Bitwarden 兼容服务端。
它不是 Bitwarden 官方服务端，也不要把它当成官方平替去找 Bitwarden 客服。你可以把它理解成一个更轻量的自托管方案：用 Cloudflare Workers 承接服务端，用 D1/R2 或 KV 这类托管能力保存数据，再让你继续使用熟悉的 Bitwarden 客户端。
适合它的人：
- 想自托管密码库，但不想维护服务器
- 已经有 Cloudflare 账号和自己的域名
- 能接受开源项目的能力边界和更新节奏
- 愿意自己负责备份和密钥管理
不太适合它的人：
- 需要企业组织、集合权限、SSO、SCIM 之类的完整企业能力
- 不想碰任何 Cloudflare 配置
- 不愿意承担自托管密码库的备份责任
一句话：它解决的是“我想要一个轻量、可控、能跑在 Cloudflare 上的密码库服务端”，不是解决“我从此再也不用管密码安全”。
1. 准备工作：别开局就卡在账号上 #
你需要准备这些东西：
- 一个自己的域名
- 一个 Cloudflare 账号
- 一个 GitHub 账号
- 能正常访问 Cloudflare 和 GitHub 的网络环境
域名在哪里买都行，Spaceship、Cloudflare Registrar、Namesilo 这类都可以，关键是域名要在你手里。密码库这种东西，别长期挂在临时域名上。
Cloudflare 账号这里要注意一点：默认 R2 模式通常需要账号完成绑卡验证。你如果暂时不想绑卡，可以考虑 KV 模式，但 KV 的单文件大小和免费额度都更紧。简单说：
- R2：更适合长期用，附件空间更宽松
- KV：门槛低一些，但限制更明显
别在这一步纠结到天荒地老。你如果打算认真用，优先 R2；只是体验一下，可以先看 KV 模式。
2. Fork 项目：先把代码放到自己名下 #
项目地址：
打开项目后，点击右上角 Fork，把仓库复制到自己的 GitHub 账号下。
Fork 的目的不是“显得很专业”，而是让 Cloudflare 后面能从你的仓库构建和部署。更重要的是，你可以控制什么时候同步上游，而不是每次上游变化都直接影响你的生产环境。
3. 开启自动同步：别把更新全靠记性 #
进入你 Fork 出来的仓库：
GitHub -> Actions -> Sync upstream -> Enable workflow
这样它会按项目内置的 workflow 自动同步上游。你也可以手动更新：
GitHub 仓库首页 -> Sync fork -> Update branch
我的建议很简单：自动同步可以开，但生产密码库别完全“闭眼更新”。项目有大版本变动时，先看一下更新说明，再决定什么时候部署。密码库这种服务，稳定比新鲜更重要。
4. 创建 Cloudflare Worker：让 Cloudflare 替你跑 #
快速入口：
打开后选择：
Continue with GitHub
第一次使用时，Cloudflare 会让你授权 GitHub。授权后选择刚刚 Fork 出来的 nodewarden 仓库。
如果页面已经自动识别好了配置，就按默认配置继续部署。如果 Cloudflare 页面需要你手动填构建和部署命令，可以按下面这样填：
Build command: npm run build
Deploy command: npm run deploy如果你明确要走 KV 模式，把部署命令改成：
npm run deploy:kv然后点击部署，等 Cloudflare 构建完成。这个过程别疯狂刷新，给它一点时间。页面自动跳转后，可以隔一会儿刷新部署状态，直到看到 production 部署成功。
5. 首次访问：跟着“密码提示”补配置 #
部署完成后，Cloudflare 会给你一个默认访问域名。点进去，看到 NodeWarden 的登录页面后，先别急着注册。
第一次访问时，点击登录界面的「查看密码提示」。这个页面会告诉你当前还缺哪些关键配置。
最常见的是缺少 JWT_SECRET。处理方式是：
Cloudflare Dashboard -> Workers & Pages -> 你的 NodeWarden 项目 -> Settings -> Variables and Secrets
新增 Secret：
JWT_SECRET=<一段足够长的随机字符串>正式环境别用临时值，也别用网上教程里的示例值。你可以在本机生成一个：
openssl rand -base64 48保存后重新部署。再回到 NodeWarden 页面刷新，如果密码提示里不再报这个问题，说明这一步过了。
6. 绑定自定义域名：别长期用 workers.dev #
Cloudflare 默认分配的 workers.dev 域名能用，但不建议长期当主入口。
原因很现实：
- 有些网络环境下
workers.dev不稳定 - 自定义域名更好记，也更方便以后迁移
- 密码管理器客户端里填自己的域名，心理上也更清楚
到 Worker 设置里添加自定义域名：
Workers & Pages -> 你的项目 -> Settings -> Domains & Routes -> Add Custom Domain
比如：
vault.your-domain.com如果域名已经托管在 Cloudflare，通常按提示点完就能自动配置 DNS 和证书。等状态变成 active 后，用浏览器打开：
https://vault.your-domain.com能正常看到 NodeWarden 登录页面，就说明入口已经换好了。
7. 客户端怎么连：填自己的服务地址 #
NodeWarden 兼容 Bitwarden 客户端，所以桌面端、手机 App、浏览器扩展都可以按自托管服务来配置。
大致路径是：
Bitwarden 客户端 -> 设置服务器地址 -> 填你的自定义域名
例如：
https://vault.your-domain.com然后再登录或注册对应账号。这里建议你先用一个测试账号验证同步、导入、导出和浏览器扩展登录流程，别一上来就把所有正式密码倒进去。先跑通闭环，再迁移核心数据。
8. 备份：密码库最不该省的步骤 #
NodeWarden 支持导入导出，也有远程备份能力。无论你用哪种方式，原则只有一个：
密码库一定要有备份，而且备份要能恢复。
别只做“我导出过一次”的心理安慰。你至少应该验证：
- 导出的文件能正常下载
- 附件是否包含在备份策略里
- 换一个空实例能否恢复
- 备份文件放在哪里，谁能访问
密码库自托管最容易翻车的点，不是部署失败，而是“平时看起来一切正常，真出事时没有可用备份”。
9. 常见翻车点 #
9.1 打开默认域名失败 #
先别怀疑自己部署错了。workers.dev 在部分网络环境下就是可能不稳定。
解决方式：尽快绑定自定义域名，然后用自定义域名访问。
9.2 页面提示缺少 JWT_SECRET
#
去 Worker 的 Variables and Secrets 里添加 Secret，保存后重新部署。
注意是 Secret，不是随便写在代码里。密钥进 Git，等于把门钥匙挂在门上。
9.3 客户端同步失败 #
先检查三件事：
- 客户端服务器地址是不是你的自定义域名
- 域名是否是 HTTPS
- Worker 是否重新部署过最新配置
别一上来就怀疑客户端。大多数时候，是入口地址或部署配置没对齐。
9.4 R2 和 KV 选哪个 #
如果你只是轻量测试，KV 可以先跑起来；如果你准备长期用，尤其会用附件或 Send 文件，优先 R2。
这不是信仰问题，是限制问题。KV 的上限更紧，后面再迁移才是真的麻烦。
10. 我的结论：能跑很简单，敢长期用靠纪律 #
NodeWarden 的部署流程其实不复杂：Fork 仓库，交给 Cloudflare 构建部署，补齐 Secret，再绑定自定义域名。
真正决定体验的不是这十分钟部署，而是后面的三件事：
- 密钥别乱放
- 更新别闭眼冲
- 备份别靠嘴说
把这三件事做好，NodeWarden 就是一个很舒服的轻量自托管密码库方案。它不要求你养服务器，也不逼你把所有东西都交给第三方。中间这条路，刚好够用，也足够清醒。