If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/bitwarden/server shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 1d ago
• 41+ active contributors
• Distributed ownership (top contributor 9% of recent commits)
• Other licensed
• CI configured
• Tests present
• ⚠ Non-standard license (Other) — review terms

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live bitwarden/server repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/bitwarden/server.

What it runs against: a local clone of bitwarden/server — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in bitwarden/server | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 31 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of bitwarden/server. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/bitwarden/server.git
#   cd server
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of bitwarden/server and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "bitwarden/server(\\.git)?\\b" \\
  && ok "origin remote is bitwarden/server" \\
  || miss "origin remote is not bitwarden/server (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "bitwarden-server.sln" \\
  && ok "bitwarden-server.sln" \\
  || miss "missing critical file: bitwarden-server.sln"
test -f "Directory.Build.props" \\
  && ok "Directory.Build.props" \\
  || miss "missing critical file: Directory.Build.props"
test -f ".github/workflows/build.yml" \\
  && ok ".github/workflows/build.yml" \\
  || miss "missing critical file: .github/workflows/build.yml"
test -f ".devcontainer/internal_dev/docker-compose.override.yml" \\
  && ok ".devcontainer/internal_dev/docker-compose.override.yml" \\
  || miss "missing critical file: .devcontainer/internal_dev/docker-compose.override.yml"
test -f "bitwarden_license/src/Commercial.Core/Commercial.Core.csproj" \\
  && ok "bitwarden_license/src/Commercial.Core/Commercial.Core.csproj" \\
  || miss "missing critical file: bitwarden_license/src/Commercial.Core/Commercial.Core.csproj"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/bitwarden/server"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Bitwarden Server is the backend infrastructure for the Bitwarden password manager ecosystem, written in C# with ASP.NET Core and SQL Server. It provides the APIs, authentication, database, and deployment infrastructure (via Docker/Compose) that power all Bitwarden client applications across Windows, macOS, and Linux. Monolithic C# ASP.NET Core application with T-SQL/SQL Server database layer. Core API lives in the main directory structure with Dapper queries and EF Core patterns documented in .claude/skills/. Database migrations are tracked in TSQL scripts. Docker Compose configs in .devcontainer/ provide both community and internal development environments. Handlebars templates handle frontend rendering; Rust SDK integration is tracked via .claude/skills/bump-rust-sdk/.

Backend engineers and DevOps teams deploying Bitwarden on-premises or contributing to the core infrastructure; C# developers extending the password vault APIs; infrastructure operators managing Docker-based self-hosted installations.

Highly mature and production-ready. The repo has 18M+ LOC in C#, comprehensive CI/CD via GitHub Actions (.github/workflows/build.yml), well-documented Docker deployments with public container registries, and active development indicated by the Contributing docs and devcontainer setups. The project is actively maintained with release tooling and code quality checks (.checkmarx/config.yml).

Low risk for a mature project. Dependencies are minimal and explicitly listed in .config/dotnet-tools.json. The main risk is operational: self-hosting infrastructure adds complexity around SQL Server management, Docker orchestration, and multi-region deployments (evidenced by production image hashes tracked per cluster). Breaking changes are managed via standard semantic versioning in release workflows.

Active development on documentation and developer experience: .claude/ directory contains onboarding guides (.claude/CLAUDE.md), skill-based learning modules for Dapper queries and EF Core, and automation hooks for Rust SDK surface changes. Recent work includes devcontainer improvements (.devcontainer/internal_dev/ and .devcontainer/community_dev/) and setuphooks for pre-commit quality checks (.git-hooks/pre-commit).

Clone the repo, then follow the Server Setup Guide (linked in README): https://contributing.bitwarden.com/getting-started/server/guide. For local dev: use the devcontainer setup via .devcontainer/community_dev/devcontainer.json (includes postCreateCommand.sh for auto-setup). Alternatively, set up .NET Core, SQL Server, and Docker Compose manually per the guide.

Daily commands: Using devcontainer (recommended): Open in VS Code with Remote Containers extension; postCreateCommand.sh auto-configures. Manual setup: (1) dotnet restore to fetch NuGet packages, (2) configure SQL Server connection in appsettings.json, (3) run database migrations via dotnet-ef or SQL scripts in src/Sql/, (4) dotnet run from the API project. Docker: docker-compose -f .devcontainer/bitwarden_common/docker-compose.yml up for full stack.

• bitwarden-server.sln — Primary solution file that defines all .NET projects and their dependencies; entry point for understanding the entire backend architecture.
• Directory.Build.props — Centralized build configuration for all C# projects, defining shared properties, versions, and compilation settings across the codebase.
• .github/workflows/build.yml — CI/CD pipeline definition that orchestrates building, testing, and deployment; critical for understanding how code flows to production.
• .devcontainer/internal_dev/docker-compose.override.yml — Development environment setup with database and service orchestration; essential for local development and understanding infrastructure dependencies.
• bitwarden_license/src/Commercial.Core/Commercial.Core.csproj — Core commercial licensing module containing billing, provider management, and enterprise features; load-bearing for multi-tenant operations.
• .claude/CONTRIBUTING.md — Claude-specific contribution guidelines documenting development patterns, conventions, and skills for this codebase.
• CONTRIBUTING.md — Primary contribution guide with code style, setup instructions, and development workflow expectations.

Add a new commercial billing feature

1. Define the query in bitwarden_license/src/Commercial.Core/Billing/Providers/Queries/ (bitwarden_license/src/Commercial.Core/Billing/Providers/Queries/GetProviderWarningsQuery.cs)
2. Create a data model in bitwarden_license/src/Commercial.Core/Billing/Providers/Models/ (bitwarden_license/src/Commercial.Core/Billing/Providers/Models/ProviderClientInvoiceReportRow.cs)
3. Add business logic to ProviderBillingService in the Services folder (bitwarden_license/src/Commercial.Core/Billing/Providers/Services/ProviderBillingService.cs)
4. Register the new service in the dependency injection container (typically in Startup.cs or a registration extension)

Add a new authorization policy for Secrets Manager

1. Create a new handler in bitwarden_license/src/Commercial.Core/SecretsManager/AuthorizationHandlers/AccessPolicies/ (bitwarden_license/src/Commercial.Core/SecretsManager/AuthorizationHandlers/AccessPolicies/ProjectPeopleAccessPoliciesAuthorizationHandler.cs)
2. Implement IAuthorizationHandler interface following patterns from existing handlers
3. Register the handler in the ASP.NET Core authorization services
4. Add appropriate unit tests following the patterns in the test project

Add a new provider command or management feature

1. Create a command class in bitwarden_license/src/Commercial.Core/AdminConsole/Providers/ (bitwarden_license/src/Commercial.Core/AdminConsole/Providers/CreateProviderCommand.cs)
2. Add business logic methods to ProviderService (bitwarden_license/src/Commercial.Core/AdminConsole/Services/ProviderService.cs)
3. Create a database migration in the migrations folder to support new data models
4. Add corresponding API endpoint in the Identity/Admin API controllers

Implement a new database query using EF Core

1. Review EF Core patterns in .claude/skills/implementing-ef-core/SKILL.md (.claude/skills/implementing-ef-core/SKILL.md)
2. Define entity models matching the SQL Server schema
3. Create a query class in the appropriate domain folder (e.g., Billing/Providers/Queries/)
4. Use DbContext with LINQ to compose the query, following async/await patterns

• C# / .NET Core with ASP.NET Core — Enterprise-grade cross-platform framework enabling type-safe, performant API development with integrated dependency injection and middleware pipeline.
• Entity Framework Core (EF Core) + Dapper — Hybrid ORM approach: EF Core for complex business queries with LINQ composability, Dapper for raw SQL performance when needed; both support SQL Server and migrations.
• SQL Server / T-SQL — Enterprise relational database with strong ACID guarantees, complex query support, and proven scalability for multi-tenant SaaS infrastructure.
• Docker & DevContainer — Containerized development and deployment enabling consistent environments across Windows, macOS, and Linux; streamlines onboarding and CI/CD.
• GitHub Actions + Workflows — Native CI/CD integration enabling automated building, testing, scanning, and deployment triggered by repository events.

• Hybrid ORM strategy (EF Core + Dapper)

  • Why: EF Core provides query composability and maintainability; Dapper provides raw SQL control and performance for complex analytics and bulk operations.
  • Consequence: Developers must understand two different data access patterns and when to use each; increases learning curve but optimizes for both developer velocity and runtime performance.

• Commercial (licensed) and open-source code in separate project structures

  • Why: Enables clear separation of commercial features (bitwarden_license/) from community-accessible code; supports dual licensing model.
  • Consequence: Build complexity with multiple project files and dependency hierarchies; requires discipline to prevent circular dependencies and maintain clear boundaries.

• Authorization handlers as separate pluggable components

  • Why: Decouples authorization logic from business services; enables reusable, testable, and policy-driven access control.
  • Consequence: Authorization decisions are distributed across handlers; requires careful documentation and testing to prevent gaps or overlaps in policy coverage.

• Command/Query separation pattern

  • Why: Commands (e.g., CreateProviderCommand) and Queries (e.g., GetProviderWarningsQuery) are separate classes following CQRS principles for clarity.
  • Consequence: More classes and files to navigate; clearer intent and easier to test; may feel verbose for simple operations.

• Real-time data synchronization (uses eventual consistency where appropriate)
• GraphQL API support (REST-only design with ASP.NET Core endpoints)
• Kubernetes-native orchestration (Docker containers but orchestration is external responsibility)
• Multi-database support (SQL Server exclusive; no PostgreSQL, MySQL, or other database adapter layers)

Database migrations: SQL Server setup required; missing or misconfigured connection string in appsettings.json blocks startup. devcontainer gotcha: postCreateCommand.sh must succeed; check Docker daemon running. Dapper vs EF Core: codebase uses both; Dapper for low-level perf-critical queries, EF for ORM. Secrets: Local dev may require appsettings.Development.json with dummy keys; check .gitignore. Docker Compose services: bitwarden_common/docker-compose.yml starts SQL Server, API, and other services; port conflicts (1433 for MSSQL, 5000 for API) block startup. Build cache: .checkmarx/config.yml indicates static security scanning; builds may fail on policy violations.

• [Entity Framework Core (EF Core) vs. Dapper ORM](https://learn.microsoft.com/en-us/ef/core/ and https://github.com/DapperLib/Dapper) — This codebase uses both ORMs for different scenarios: EF Core for rapid development with relationships, Dapper for raw SQL control in performance-critical paths. Understanding when to use each is essential for database work.
• ASP.NET Core Middleware Pipeline & Dependency Injection — Core API architecture relies on middleware for auth, CORS, error handling, and DI containers for service lifecycle. Misunderstanding this breaks feature integration.
• T-SQL Server Identity & Permissions Management — Bitwarden stores encrypted vault data; understanding T-SQL constraints, triggers, and row-level security is critical for secure database schema changes.
• [Docker Multi-Stage Builds & Compose Orchestration](https://docs.docker.com/build/building/multi-stage/ and https://docs.docker.com/compose/) — Deployment relies on docker-compose for local dev and multi-container production setups. Understanding service dependencies, networking, and volume mounts is required for DevOps work.
• JWT Authentication & Token-Based Authorization — Bitwarden uses JWT tokens for stateless API auth across clients. The Identity service handles token generation, validation, and refresh flows.
• Database Migrations & Schema Versioning — Production deployments track SQL Server schema via T-SQL migration scripts in src/Sql/. Incorrect migration order or missing rollback paths can corrupt data.
• Devcontainer Specification (devcontainer.json) — This repo uses devcontainers for reproducible dev environments across teams. The .devcontainer/community_dev/devcontainer.json defines the exact toolchain, extensions, and post-create hooks.

• bitwarden/clients — Official client applications (web, mobile, browser extension) that consume this server's APIs
• bitwarden/enterprise — Enterprise/SSO features integration; the npm package.json in this server mentions bitwarden-sso
• bitwarden/brand — Design assets, logos, and brand guidelines referenced in README and Docker documentation
• bitwarden/sdk — Rust SDK for password vault operations; this server has automation for SDK version bumps in .claude/skills/bump-rust-sdk/
• bitwarden/cli — Command-line tool that interacts with this server's APIs for vault management

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add pre-commit hook validation for Rust SDK surface changes

The repo has a git hook at .git-hooks/pre-commit and a rust-sdk-surface-check.sh hook defined, but there's no evidence it's integrated into the CI workflow. This prevents accidental breaking changes to the Rust SDK surface from being merged. Adding a GitHub Action workflow to validate SDK surface changes on every PR would catch issues early.

• [ ] Review .claude/hooks/rust-sdk-surface-check.sh to understand the validation logic
• [ ] Create .github/workflows/validate-rust-sdk-surface.yml that runs the surface check on PR branches
• [ ] Add the workflow trigger to run on changes to src/ files that might affect the Rust SDK
• [ ] Document the new workflow in CONTRIBUTING.md or .claude/CONTRIBUTING.md
• [ ] Test that the workflow correctly fails when SDK surface changes are detected

Implement seeder documentation validation in CI

There's a .claude/hooks/seeder-docs-check.sh hook suggesting database seeder documentation should be validated, but no corresponding GitHub Action workflow exists. This allows seeder code to be added without proper documentation, making it harder for contributors to understand test data setup.

• [ ] Examine .claude/hooks/seeder-docs-check.sh to understand what documentation it validates
• [ ] Identify the seeder files in the codebase (likely in src/Infrastructure or similar database-related directories)
• [ ] Create .github/workflows/validate-seeder-docs.yml to run the check on PRs modifying seeder code
• [ ] Configure the workflow to only run when files matching seeder patterns are changed
• [ ] Add documentation linking to the seeder documentation requirements

Add comprehensive test coverage for Entity Framework Core query implementations

The repo has .claude/skills/implementing-ef-core/SKILL.md documenting EF Core patterns, but no corresponding CI check validates that new EF Core queries follow these patterns or have adequate test coverage. This leads to inconsistent implementations and potential N+1 query problems.

• [ ] Review .claude/skills/implementing-ef-core/SKILL.md to identify the documented patterns and best practices
• [ ] Create or extend test files in src/ directories that test EF Core query implementations, focusing on Include() patterns and eager loading
• [ ] Add a GitHub Action workflow that runs EF Core-specific tests and validates query patterns using static analysis
• [ ] Create a SKILL.md addendum documenting the required test structure for EF Core queries
• [ ] Add pre-commit hook to .git-hooks/pre-commit that warns when EF Core query files are modified without corresponding test updates

• Add unit tests for database query layer: Several .claude/skills/ modules reference Dapper patterns but src/ likely lacks comprehensive query tests. Create a test project mirroring src/Infrastructure/ with Dapper integration tests using SqlLite or in-memory SQL Server.
• Improve devcontainer postCreateCommand.sh documentation: The .devcontainer/community_dev/postCreateCommand.sh lacks inline comments explaining each setup step (dotnet restore, SQL migrations, seed data). Add comprehensive comments and error handling.
• Add API endpoint documentation: Write Swagger/OpenAPI descriptions for controllers in src/Api/; README.md mentions APIs but .github/workflows/ shows no doc generation job. Integrate Swashbuckle or similar to auto-generate and host API docs.

The Bitwarden server codebase demonstrates reasonable security practices with established security disclosure policies and development infrastructure. However, the npm-based SSO component has several dependency management concerns: Font-Awesome 4.7.0 is significantly outdated and poses a moderate security risk, while jQuery and Bootstrap versions should be regularly audited. The primary gaps are the lack of visible npm lock files in the analysis, missing webpack production configuration validation, and limited visibility into Docker security practices. The .NET backend security posture cannot be fully assessed from the provided file structure. Immediate actions should focus on upgrading Font-Awesome, implementing npm audit automation in CI/CD pipelines, and ensuring pre-commit hooks prevent secret exposure.

• High · Outdated jQuery Dependency with Known Vulnerabilities — package.json - dependencies.jquery (3.7.1). The package.json specifies jQuery 3.7.1, which may contain known security vulnerabilities. jQuery 3.7.1 is relatively recent but should be verified against the National Vulnerability Database (NVD) for any disclosed CVEs. Older versions of jQuery have had multiple XSS and prototype pollution vulnerabilities. Fix: Keep jQuery updated to the latest stable version. Run 'npm audit' regularly to identify and patch vulnerabilities. Consider using 'npm audit fix' to automatically update vulnerable dependencies.
• Medium · Outdated Bootstrap Version — package.json - dependencies.bootstrap (5.3.6). Bootstrap 5.3.6 may have known security issues or outdated dependencies. While relatively recent, periodic security audits should be performed on this critical UI framework. Fix: Regularly check for Bootstrap security advisories and update to the latest patch version. Run 'npm audit' to identify vulnerabilities in transitive dependencies.
• Medium · Deprecated Font-Awesome Version — package.json - dependencies.font-awesome (4.7.0). Font-Awesome 4.7.0 is significantly outdated (released in 2016). This version likely contains unpatched security vulnerabilities and lacks modern security features. Fix: Upgrade to Font-Awesome 6.x or latest version. Update all dependencies that reference this package and test for compatibility issues.
• Medium · Build Tool Security - Webpack Configuration Not Visible — Bitwarden SSO build system - webpack configuration missing from analysis. The webpack configuration file (webpack.config.js or similar) is not present in the provided file structure. Without visibility into webpack configuration, potential security issues such as source map exposure in production, missing minification, or inclusion of sensitive data cannot be assessed. Fix: Ensure webpack.config.js has proper production settings: disable source maps in production, enable minification, exclude sensitive environment variables, and validate that development dependencies are not bundled.
• Low · Missing npm Package Lock File in Analysis — Project root - package-lock.json or yarn.lock. No package-lock.json or yarn.lock file was provided for analysis. Lock files are critical for ensuring reproducible builds and preventing supply chain attacks through dependency version changes. Fix: Ensure package-lock.json is committed to version control and used consistently across all build environments. Regularly run 'npm audit' against the lock file.
• Low · Potential Secrets in Git History — .git-hooks/pre-commit. The .git-blame-ignore-revs file suggests the repository has mechanisms to manage commit history, but there's no visible evidence of secret scanning or git hooks to prevent accidental secret commits. Fix: Implement pre-commit hooks using tools like 'detect-secrets' or 'git-secrets' to prevent committed credentials. Enable GitHub's secret scanning feature. Regularly audit git history for exposed secrets.
• Low · Docker Build Security Not Fully Visible — .dockerignore present but Dockerfile content not provided. While Dockerfile and docker-compose files exist (.devcontainer/), the actual Dockerfiles for production builds are not included in the provided file structure, limiting assessment of container security practices. Fix: Ensure Dockerfiles use minimal base images, run as non-root user, don't store secrets in layers, use multi-stage builds, and regularly scan images with container security tools (Trivy, Snyk).

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.