Bitwarden Server Seeder 实战用 dev.playground 预设从零构建可登录、含真实业务数据的开发数据库【免费下载链接】serverBitwarden infrastructure/backend (API, database, Docker, etc).项目地址: https://gitcode.com/GitHub_Trending/ser/server当你的 Bitwarden 开发数据库被清空或全新初始化后直接对着空库调试登录、组织权限和 Vault 体验既低效又缺乏真实感。本文基于仓库中的场景文档 fresh-database.md 展开讲清如何用一条dotnet run -- preset --name dev.playground命令通过 SeederUtility 向本地数据库注入一个企业版组织四个以角色命名的可记忆登录账号、十二个带真实职衔的团队成员、精心设计的 Collection 权限组合以及二十一条贴近生产形态的保险库条目读完即可掌握本地开发基线数据的一键搭建、预设文件结构剖析与常用变体命令。适用场景你需要一个能登录、有真实数据的数据库该场景文档针对的痛点非常直白Just wiped my DB, new to the team, or starting fresh. I need something to log into.刚清库、新入职团队或者想从头开始需要能登录的东西。它面向三类人新加入团队的工程师、刚重置过本地环境的开发者、以及任何想要一个干净基线来开始工作的场景。在 Bitwarden server 仓库中这一需求由 Seeder 体系解决。Seeder 场景索引 中有一句重要提示Seeder 直接写数据库只应对本地开发数据库运行。所有 Seeder 命令都在util/SeederUtility/目录下执行所有被播种的用户默认密码为asdfasdfasdf可用--password覆盖。CLI 参数全集见 SeederUtility README。快速开始一条命令播种在util/SeederUtility/目录下执行dotnet run -- preset --name dev.playground这条命令加载名为dev.playground的内置预设preset把一套经过人工设计的组织数据写入当前连接的数据库。几个要点跳过--mangle场景文档明确建议这里不要使用--mangle。--mangle会随机化 ID、邮箱和标识符以隔离测试避免重复运行冲突但代价是登录邮箱变得不可记忆。dev.playground预设的核心价值恰恰在于登录名即角色保持可记忆是这个预设的设计意图。无需 Azurite该预设不包含任何附件attachment数据因此不需要配置本地 Azure Blob 存储模拟Azurite或其他对象存储即可完整运行。默认即仓库内置种子这正是dev/seed.ps1的默认播种内容之一见下文与 dev/seed.ps1 的关系一节。播种后你能得到什么运行完成后数据库中会出现一个企业版组织Dev Org域名bw.example来自 dev-org.json其登录账号与可见数据如下。四个角色账号登录名即角色预设使用 roster 中的email字段覆盖让四个管理角色拥有可预测的登录邮箱。四个账号密码均为asdfasdfasdf除非--password覆盖每个角色登录看到的是有意不同的 Vault 视图登录邮箱角色登录后看到的内容ownerbw.exampleOwner一切内容——对每个 Collection 都有直接 Can Manage 权限adminbw.exampleAdminCompany-Wide、Break Glass外加两个只读的 Leadership 视图CI Releases、Vendors Contractscustombw.exampleCustomCompany-Wide、CI Releases只读、Finance只读且隐藏密码userbw.exampleUserCompany-Wide 加 Engineering 系列 Collection并带有个人文件夹与收藏这正是deliberate permission mix刻意的权限组合的体现权限不是全放开也不是全锁死而是按 Bitwarden 真实的权限模型管理/只读/隐藏密码分层铺设使得切换四个账号登录就能直观感受不同角色下的 Vault 差异。八位真实感同事与分组结构除四个角色账号外dev-roles roster 还定义了八位production-realistic colleagues每位都有姓名、角色user与职衔姓名职衔所属分组Elena VasquezEngineering LeadEveryone、Engineering、LeadershipMarcus WebbSite Reliability EngineerEveryone、EngineeringPriya SharmaBackend EngineerEveryone、EngineeringTom OkaforFrontend EngineerEveryone、EngineeringIngrid LarsenFinance DirectorEveryone、Finance、LeadershipDiego FuentesAccountantEveryone、FinanceHana KobayashiPeople Operations ManagerEveryone、People OpsSam WhitakerRecruiterEveryone、People Ops场景文档说这八位同事分布在四个 group中从 dev-roles.json 的源码看roster 实际定义了 5 个 groupEveryone全部 12 人、Engineering5 人、Finance2 人、People Ops2 人、Leadershipowner、admin 及两位业务负责人。八位同事覆盖其中 Everyone / Engineering / Finance / People Ops 四组Leadership 组主要用于承载权限实验。Collection 权限矩阵dev-roles 定义了 8 个 Collection每个 Collection 通过groups/users两个维度的manage、readOnly、hidePasswords标记组合出不同权限。这是权限测试的核心资产摘录几个典型配置Company-WideEveryone 组全员可见owner 可管理Engineering与Engineering/Cloud InfrastructureEngineering 组可见owner 与 Engineering Leadelena.vasquez可管理Engineering/CI ReleasesEngineering 组可访问Leadership 组只读casey.custom只读——这是 admin/custom 账号只读 Leadership 视图的来源FinanceFinance 组可管理casey.custom只读且hidePasswords: true隐藏密码Leadership/Break Glass没有绑定任何 group仅 owner 可管理、admin 可访问是典型的破窗break glass应急凭据隔离设计。二十一条贴近生产的保险库条目ciphers 夹具 dev-playground.json 提供了 21 条条目覆盖 Bitwarden 的主要条目类型且细节刻意贴近真实团队Login13 条GitHub含 TOTP、Docker Hub、npm Registry、Figma、AWS IAM - Developer含 TOTP、PgAdmin (Production)、Datadog、Stripe Dashboard含 TOTP、Xero、BambooHR、Slack、Google Workspace Admin含 TOTP、AWS Console (Root)含 TOTP。部分 Login 标注cipherEncryption: cipherKey如 Figma、PgAdmin、AWS Root即使用 cipher-key 加密模式写入用于验证两种加密路径Secure Note5 条Office Wi-Fi、Office Door Codes含季度轮换说明、Incident Response Runbook、Release Signing Checklist、Onboarding Checklist——这些笔记内容甚至与其他 Collection 的权限设计互相呼应如 Onboarding Checklist 提到加入正确的 groupCard1 条Corporate Amex持卡人 DEV ORG LLCIdentity1 条Office Shipping Profile完整的公司收货地址SSH Key1 条Deploy Key - prod-web-01带伪造的 OPENSSH 私钥/公钥与指纹。条目中的密码、token、密钥均为明确的假数据如ghp_FakeSeederToken4DevOrg2026、FAKE-EXAMPLE-NOT-A-REAL-KEY仅用于本地开发体验。预设文件的结构剖析playground.json 如何组装数据dev.playground的完整定义在 util/Seeder/Seeds/fixtures/presets/dev/playground.json它引用了三个夹具并叠加三类分配关系{ $schema: ../../../schemas/preset.schema.json, organization: { fixture: dev-org, planType: enterprise-annually, seats: 20, allowAdminAccessToAllCollectionItems: false }, roster: { fixture: dev-roles }, ciphers: { fixture: dev-playground }, collectionAssignments: [ ... 21 条 cipher→collection 映射 ... ], folderAssignments: [ ... 5 条 用户文件夹映射 ... ], favoriteAssignments: [ ... 4 条 用户收藏映射 ... ] }各部分含义organizationfixture: dev-org指向上文组织夹具planType: enterprise-annually声明企业年付计划schema 支持的枚举值还包括teams-monthly、teams-annually、families-annually等见 preset.schema.jsonseats: 20给组织 20 个席位allowAdminAccessToAllCollectionItems: false显式关闭管理员可访问全部 Collection 条目的组织选项——这保证了权限矩阵必须靠显式授权生效而不是被组织级开关兜底绕过这也是四个角色看到不同 Vault 的前提。roster/ciphers分别引用 roster 夹具与 cipher 夹具保证每次播种出的成员、分组、条目完全确定、可复现preset 的定位就是same data every time与生成式数据相对见 presets.md。collectionAssignments21 条条目逐一指派到 8 个 Collection含两级路径如Engineering/Cloud Infrastructure、Finance/Vendors Contracts、Leadership/Break Glass例如AWS Console (Root)与Google Workspace Admin都落在 Break Glass 中Office Wi-Fi等落入 Company-Wide。folderAssignments为特定用户创建个人文件夹。例如uma.user把 GitHub、Figma 放进 Work 文件夹npm Registry 放进 Personal Projectsowen.owner为两个破窗凭据建立 Break Glass 文件夹。favoriteAssignments为四个用户标记收藏uma.user收藏 GitHub 和 Office Wi-Fi、owen.owner收藏 AWS Root、ingrid.larsen收藏 Stripe Dashboard让每个角色登录后的首页体验各不相同。这些字段均受 preset.schema.json 约束schema 要求预设二选一包含organization或user并严格限定additionalProperties: false即预设文件不允许出现未定义的字段——这也是仓库内所有预设文件格式统一的依据。CLI 侧preset命令的参数定义在 PresetArgs.cs与本文相关的开关有--list列出全部可用预设--name预设名--mangle启用 ID/邮箱随机化以隔离测试--password全部账号密码默认asdfasdfasdf--owner-email/--org-name覆盖 owner 登录邮箱与组织显示名均可与--mangle组合。PresetArgs.cs中对 owner-email 的注释值得注意Must not already exist in the User table; add--mangleto make repeat runs unique. 由此可以推断不带--mangle重复运行dev.playground时若ownerbw.example等邮箱已存在运行将不会成功——这正是该场景文档默认前提为刚清库/全新环境的原因若需要多次播种同一预设做隔离测试应改用带--mangle的其他预设见变体表。与 dev/seed.ps1 的关系仓库的默认本地种子场景文档提到 This is whatdev/seed.ps1seeds by default.。dev/seed.ps1 是仓库为本地开发提供的批量播种脚本其工作机制读取 dev/seeds.json数组形式的种子清单若存在本地seeds.local.json则追加其条目将每条条目的args按 PascalCase→kebab-case 规则转换成 CLI 参数逐条执行dotnet run --project util/SeederUtility -- command args任一条失败即中断并返回其退出码支持-DryRun开关只打印将要执行的命令而不真正执行。seeds.json当前包含三条种子[ { label: Jane Doe Free (individual, free), command: individual, args: { subscription: free, firstName: Jane, lastName: Doe, email: janebw.example } }, { label: John Doe (individual, premium), command: individual, args: { subscription: premium, firstName: John, lastName: Doe, email: johnbw.example } }, { label: Dev Playground (dev.playground preset), command: preset, args: { name: dev.playground } } ]即一个 Free 个人账号、一个 Premium 个人账号加上本文主角dev.playground组织预设。因此在本地按标准流程启动开发环境dev/下的 docker-compose 等后运行./seed.ps1数据库会自动获得上述基线数据也可以单独执行第三条目等价的手动命令dotnet run -- preset --name dev.playground。变体同一需求下的其他预设场景文档给出的变体表完整继承如下均可在util/SeederUtility/下执行场景命令附件覆盖测试需要 Azuritedotnet run -- preset --name qa.enterprise-basic --mangle更大规模组织58 用户、14 分组dotnet run -- preset --name qa.dunder-mifflin-enterprise-full --mangleFamilies 计划dotnet run -- preset --name qa.families-basic --mangleFree 计划个人 Vaultdotnet run -- preset --name qa.stark-free-basic --mangle只要个人用户、不要组织dotnet run -- individual --subscription premium --first-name Jane --last-name Smith --vault这些变体与dev.playground的区别在于QA 预设普遍携带附件数据因此需要 Azurite 或本地附件目录且都建议使用--mangle以便重复播种互不冲突individual命令则完全跳过组织创建一个带个人 Vault约 75 条生成式条目、5 个文件夹的高级订阅用户邮箱规则为{first}.{last}individual.example见 SeederUtility README。如需浏览完整预设目录Developer / Features / QA / Scale / Individual / Validation 六大类见 presets.md。验证与注意事项登录验证用ownerbw.example/asdfasdfasdf登录应看到全部 8 个 Collection换成custombw.example登录Finance 条目密码应不可见Leadership 视图只读——这是最直接的权限行为验证方式。运行边界Seeder 直写数据库务必只指向本地开发库命令在util/SeederUtility/下以dotnet run执行前置是dotnet build成功且连接串指向目标库。重复运行dev.playground不含--mangle邮箱固定重复运行依赖库中无同名邮箱的前提若需反复播种同一形状的组织选择带--mangle的 QA/Scale 预设。数据位置本文引用的预设与夹具全部位于util/Seeder/Seeds/下fixtures/presets/dev/、fixtures/rosters/、fixtures/organizations/、fixtures/ciphers/格式契约在util/Seeder/Seeds/schemas/中可作为自定义预设时的模板。综上dev.playground预设以极低的命令成本一行交付了一个结构完整、权限分层、可逐个角色体验的 Bitwarden 开发基线组织20 席位企业年付 12 名成员 5 个分组 8 个带权限标记的 Collection 21 条多类型保险库条目且刻意排除附件依赖是清空数据库或新环境搭建后的首选播种方案。【免费下载链接】serverBitwarden infrastructure/backend (API, database, Docker, etc).项目地址: https://gitcode.com/GitHub_Trending/ser/server创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
