Bitwarden Server

Bitwarden Server is the open-source backend infrastructure powering the Bitwarden password manager ecosystem. It delivers the API, Identity, Admin, SCIM, SSO, Billing, Events, and Notifications microservices required to operate a fully self-hosted credential management platform. Built on .NET 10 with ASP.NET Core and backed by SQL Server (or PostgreSQL via Entity Framework), it supports cross-platform deployment via Docker on Windows, macOS, and Linux.

The architecture separates concerns cleanly across containerized microservices, each with its own deployment boundary. The core server enforces zero-knowledge encryption — all vault data is encrypted client-side using AES-256 before transmission, and the server never processes plaintext credentials. This design gives organizations full data sovereignty while still enabling advanced enterprise features like SAML SSO, SCIM 2.0 provisioning, WebAuthn hardware keys, and real-time audit event logging.

Bitwarden Server uses a dual-license model: the main server code is AGPL v3, while enterprise-specific features in the /bitwarden_license directory operate under the Bitwarden License, which requires a paid subscription for production use. This lets individuals and small teams self-host the full open-source core for free, while larger organizations can unlock advanced features through a commercial relationship.

What You Get

• Zero-Knowledge Encryption Backend - All vault data is encrypted client-side with AES-256 before transmission; the server stores only ciphertext and never processes plaintext credentials, ensuring true data sovereignty.
• Containerized Microservices Deployment - Deploy the full Bitwarden stack via Docker Compose using official container images with simple Bash or PowerShell installer scripts, with US and EU regional image sets available.
• SCIM 2.0 User Provisioning - Automate user and group lifecycle management via SCIM 2.0 integration with enterprise identity providers including Azure AD, Okta, JumpCloud, and Google Workspace.
• SAML 2.0 SSO Integration - Enable centralized single sign-on for organization members using SAML 2.0, with support for IdP-initiated and SP-initiated flows via the dedicated SSO microservice.
• WebAuthn and Passkey Authentication - Support hardware security keys (FIDO2/WebAuthn) and passkeys as passwordless login factors, with configurable limits expandable via premium subscription.
• Event Logging and SIEM Integration - Capture granular user and organization activity events via the Events and EventsProcessor services, enabling audit trails and integration with external SIEM platforms.
• Admin Control Panel - Centralized web interface to manage users, organizations, policies, billing, and security reports without exposing or accessing encrypted vault data.
• Secrets Manager API - Dedicated service for managing application secrets and machine credentials separately from personal vaults, with scoped service-account access for CI/CD pipelines.

Common Use Cases

• Enterprise credential governance - A CISO deploys Bitwarden Server on-premises, integrating with Active Directory via SCIM to automatically provision and deprovision employee vault accounts, enforce master password policies, and route audit events to a Splunk SIEM.
• Compliance-bound data residency - A healthcare or financial services organization runs Bitwarden in a private cloud to satisfy HIPAA or SOC 2 requirements, ensuring encrypted credential data never leaves their controlled infrastructure.
• DevOps secrets management - A platform engineering team uses the Secrets Manager service to inject application secrets into CI/CD pipelines via scoped service accounts, eliminating hardcoded credentials from source repositories.
• Privacy-conscious self-hosters - An individual or small team self-hosts the open-source core on a home server or VPS to eliminate dependence on third-party cloud storage for their most sensitive credentials.

Under The Hood

Architecture Bitwarden Server is structured as a suite of independently deployable ASP.NET Core microservices — API, Identity, Admin, SCIM, SSO, Billing, Events, EventsProcessor, and Notifications — each with its own deployment boundary and configuration surface. The system applies strict dependency inversion throughout: controllers depend only on service interfaces, repositories are abstracted behind typed interfaces, and service registration flows through extension methods on IServiceCollection. This makes it possible to swap infrastructure implementations (e.g. Dapper vs. Entity Framework, SQL Server vs. PostgreSQL) without touching business logic. The authorization layer uses a policy-based model with dynamic requirement factories that evaluate organizational membership, role assignments, and feature-flag state at runtime, enabling fine-grained, data-driven access control across multi-tenant organization hierarchies. A shared CurrentContext abstraction carries authenticated identity and organization context across service boundaries without coupling to HTTP middleware.

Tech Stack The server runs on .NET 10 with ASP.NET Core as the web framework, using a custom Bitwarden.Server.Sdk MSBuild SDK for multi-project orchestration and SQL asset compilation. Data access uses two parallel strategies: Dapper with raw T-SQL stored procedures for performance-critical paths and an Entity Framework Core layer that supports PostgreSQL and MySQL for teams avoiding SQL Server. The identity layer is built on Duende IdentityServer for OAuth 2.0 and OpenID Connect flows. Email rendering uses a Node.js-based MJML pipeline compiled to Handlebars HTML templates embedded in the assembly, with MailKit for SMTP delivery and fallback support for SendGrid and Amazon SES. Azure Service Bus, AWS SQS, and RabbitMQ are all supported as message queue backends via abstracted interfaces. Push notifications flow through Azure Notification Hubs or the Bitwarden relay service.

Code Quality The test suite spans nearly a thousand files covering unit tests, integration tests, and end-to-end scenarios across all major services, using xUnit with AutoFixture for data generation and NSubstitute for mocking. Nullable reference types are enabled in all production code (annotations mode in tests), and TreatWarningsAsErrors is set project-wide, turning type safety violations into build failures. Error handling uses typed custom exceptions with explicit domain semantics — BadRequestException, NotFoundException, GatewayException — rather than relying on generic catch blocks. The build enforces editorconfig rules including async naming conventions, internationalization diagnostics, and field declaration style. The commercial code in bitwarden_license is isolated behind SDK references, keeping licensing boundaries enforced at the compiler level rather than by convention.

What Makes It Unique Bitwarden Server’s most distinctive technical characteristic is its end-to-end zero-knowledge architecture enforced at the protocol level: the User entity stores sealed key material (master-password-derived key, public/private keypair, signed public key, security state) rather than any plaintext secret, and a SignedPublicKey field enables cryptographic verification of key authenticity across devices. The KeyManagement subsystem implements a KDF abstraction supporting both PBKDF2 and Argon2id with per-user parameters, allowing the server to guide clients toward stronger derivation without holding the derived key. The MJML-based email system compiles responsive transactional templates at build time into Handlebars-enhanced HTML embedded in the assembly, eliminating runtime template rendering dependencies. The dual-infrastructure data access strategy (Dapper stored procedures plus EF Core) lets the same domain logic target SQL Server with maximum performance or open-source databases for cost-sensitive deployments without forking business logic.

Self-Hosting

Bitwarden Server uses a dual-license structure that is important to understand before deploying. The main server code — API, Identity, Admin, Events, Notifications, and supporting libraries — is licensed under the GNU Affero General Public License v3.0 (AGPL). This means you can run it, modify it, and distribute it freely, but if you offer it as a network service and modify the AGPL-licensed code, you must publish those modifications under the same license. This is a strong copyleft obligation that matters most if you are building a managed service on top of Bitwarden. For individuals, teams, and organizations running it internally, the AGPL poses no practical restriction beyond transparency.

Running Bitwarden Server yourself is a meaningful operational commitment. The Docker Compose setup is well-documented and the installer scripts handle most of the initial configuration, but you take on responsibility for database backups, TLS certificate renewal, version upgrades (monthly release cadence), log retention, and uptime. The default stack requires a capable server — Bitwarden’s own documentation recommends at least 2 GB RAM for a small team deployment. High-availability configurations require you to manage multiple container replicas, a load balancer, and shared storage yourself; there is no built-in clustering support in the community setup.

The enterprise features that differentiate the paid tiers — SCIM provisioning, SAML SSO, advanced organizational policies, priority support, and SLA guarantees — live in the /bitwarden_license directory under the Bitwarden License, which explicitly requires a paid subscription for production use. The cloud-hosted Bitwarden Teams and Enterprise plans include managed upgrades, guaranteed uptime SLAs, 24/7 priority support, and automated backups, which a self-hosted deployment must replicate independently. For organizations that need SSO and SCIM but want self-hosting, a paid Bitwarden subscription is still required to legally unlock those features in production.