Should you self-host Bitwarden or stay on the Bitwarden cloud?
If your team is deciding where its password vault lives, stay on the Bitwarden cloud unless a specific requirement pushes you off it. Self-hosting is defensible when data residency rules, internal control requirements or a policy that keeps credentials inside your own network make the hosted service hard to approve, and when you already have people who can run a Docker-based application, handle database backups and apply upgrades on a monthly cadence. Self-hosting is not a cheaper or safer default on its own: you take on the hosting, patching, backup and recovery work that the cloud service otherwise carries for you.
The server code is the same. The main server is licensed under AGPL 3.0, while files in the bitwarden_license directory, including Commercial.Core and the SSO integration modules, fall under the Bitwarden License, which permits development and testing but requires a paid subscription for production use. Paid features on a self-hosted installation need a license file downloaded from the cloud web app (Admin Console, Billing, Subscription) and tied to your installation ID, and that file's data region must match the region of the cloud organization. Confirm the current licensing rules with Bitwarden before you commit, because the license is a recurring obligation in both models rather than a one-time setup step.
Before you choose, check three things: which region your cloud organization is in, which paid features you need (enterprise policies and SSO are the ones that most often decide the question), and who on your team will own the server after go-live. The documented migration path from cloud to self-hosted moves vault data, but attachments, member invitations, enterprise policies and SSO must be configured again, so budget that rework into the decision. If you cannot name an owner for patching and restores, the cloud is usually the safer choice.
How the cloud and self-hosted Bitwarden compare on the factors that matter
This table compares Bitwarden's cloud service with the same server run in your own infrastructure, row by row on licensing, data location, installation ID, deployment options, host requirements, operations and cost. Read each row as a question to put to Bitwarden and your own team, since several answers depend on your contract and region. The main takeaway is that self-hosting moves paid feature licensing, patching, backups and hosting work onto your side, and that the cost of those tasks is set by your environment rather than by any published price.
| Factor | Bitwarden cloud | Self-hosted Bitwarden |
|---|---|---|
| License and paid features | Paid features are included in the cloud plan you subscribe to. | Server code is AGPL-3.0, but files in bitwarden_license are under the Bitwarden License and production use of those paid modules needs a paid subscription. |
| Data location and region | Data sits in the region of your cloud organization. Confirm the regions offered with Bitwarden. | You choose where the host runs. The installation's data region must match the cloud organization's region for paid features. |
| Installation ID and license file | Not applicable. Licensing is handled in the cloud web app. | Installation ID and key come from bitwarden.com/host using a valid email. Paid features need a license file downloaded from the cloud Admin Console and tied to that installation ID. |
| Supported deployment options | Bitwarden hosts the service. You manage users, policies and SSO settings. | Standard multi-container install, lite single-container deployment, and official Helm charts for Kubernetes. Lite is intended for personal use and home labs, not business use. |
| Host and Docker requirements | Not applicable to you. | Linux install guide lists minimum 2 GB RAM, 12 GB storage and Docker Engine 26 or later. Recommended is 4 GB RAM and 25 GB storage. Confirm sizing for your user count. |
| Database | Managed by Bitwarden. | Default MSSQL Express image with a 10 GB database size limit. Confirm the database plan and growth path with Bitwarden before go-live. |
| Patching and upgrades | Bitwarden applies service updates. | Your team applies monthly server and self-host releases, such as v2026.10.0 published October 15, 2026. Confirm the upgrade procedure and support window with Bitwarden. |
| Backups and recovery | Bitwarden operates backup and recovery of the service. Confirm the recovery terms in your contract. | Your team owns database and attachment backups and restore testing. Confirm backup guidance with Bitwarden. |
| Migration path | Documented export, license download and import into a self-hosted account. Attachments, member invitations, enterprise policies and SSO must be redone. | Migration into the cloud is not the same procedure. Plan the reverse path and what it leaves behind before committing. |
| Cost components | Subscription fees paid to Bitwarden, recurring. Ask for per-seat and tier pricing in writing. | Hosting, storage, licensed subscription for paid modules, staff time for upgrades and backups, and outside help if engaged. Quote one-time setup separately from recurring run costs. |
What control and data location change, and what they do not
Moving from Bitwarden cloud to a self-hosted server moves the database, backups and logs into your hands, but it also moves the license, the updates and the evidence into your hands. The cards below separate what you gain from what stays with Bitwarden, and what your auditor will still expect you to show.
Data location and the license region rule
Self-hosting places the vault database in the infrastructure you choose, which matters when data residency is a contractual or regulatory requirement. Paid features are a separate question: the license file is tied to the installation ID, and that installation's data region must match the region of the cloud organization. Before you deploy, confirm the region of your existing organization in the cloud web app and the region you intend to host in, because a mismatch blocks the paid features you are paying for.
Database and backup ownership
On your own server, you choose the database platform, the backup schedule, the retention period and the restore test. The standard installation ships an MSSQL Express image with a 10 GB database size limit, so growth planning is your job from the first day. Ask Bitwarden and your DBA how the database is sized, how backups are taken while the server runs, and who has rights to restore. Vault recovery is only as good as the last restore you have tested.
Access and logging you operate
On Bitwarden cloud, the vendor operates the infrastructure, so you rely on its logs and its access controls. Self-hosting gives you the host, the container runtime and the reverse proxy logs, and it makes you responsible for collecting them, protecting the administrator accounts and reviewing who exports vault data. Decide where logs are sent, how long they are kept, and who can read them. The vendor's own event data and your host logs are different records, and an auditor may ask for both.
Updates and patch responsibility
Self-hosting makes you the party that applies each server release, including the monthly v2026.9.x-style updates that Bitwarden publishes, and the self-host release that accompanies them. Cloud customers receive these changes without scheduling a window. Agree on a patch cadence, a test environment and a rollback path before go-live, and confirm which release lines your license covers so a routine update does not silently break paid features.
Compliance evidence and the auditor's expectations
Moving hosting does not remove your obligations. It changes which controls you must show, such as backup testing, access reviews, change records and data location. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications, and independent auditors and certification bodies make that determination. Ask your auditor which controls they expect to see for a password manager, and confirm them against your own environment before you change hosting.
Which hosting model fits which team
A small business with no dedicated operations people usually gains little from running the server itself. The cloud service removes patching, backups and database upkeep from someone's already full schedule, and the vendor carries those duties. Self-hosting only makes sense here if a specific constraint, such as a contractual requirement to keep vault data on your own premises, forces the decision.
- Operating duties: Someone must apply server upgrades, keep Docker Engine current and maintain database backups, because a self-hosted installation does not patch itself.
- Paid features: Paid features need a license file downloaded from the cloud web app and tied to your installation ID, so the cloud account stays in the loop even when the server runs locally.
- Setup path: A standard installation requires an installation ID and key obtained with a valid email address, which is one more account process to manage.
- Lite deployment: Bitwarden positions lite for personal use and home labs, not business use, so it is not a fit for a company vault.
- Ongoing support: Cloud subscribers rely on the vendor for service availability, while a self-hosted team handles outages itself.
Before deciding, confirm with Bitwarden which plan and features your team needs and ask what the license requirements are for your installation.
A regulated organization often chooses self-hosting because a rule or internal policy requires vault data to stay in a specific location or under its own administrative control. Bitwarden's licensing ties paid self-hosted features to a data region that must match the cloud organization's region, so region planning is part of the design, not an afterthought. Self-hosting shifts evidence and operating controls onto your team.
- Region matching: The installation ID's data region must match the cloud organization's region before a license file works, so confirm the region with your Bitwarden account team before you deploy.
- Hosting location: Self-hosting places the server, database and backups in infrastructure you control, which is the reason most regulated teams consider it.
- Migration cost: The documented cloud to self-hosted migration leaves attachments, member invitations, enterprise policies and SSO to be redone, so plan that rework into the project.
- Evidence: Your team must produce its own access reviews, backup restore tests and change records for the server, since the vendor's cloud controls do not cover your installation.
- Independent review: DeployOpen prepares systems and evidence for assessments but does not issue audit reports, so ask your auditor which artifacts they expect.
Confirm the residency requirement in writing and check it against the migration steps before any data moves.
An IT team that already operates containers and Kubernetes can absorb a self-hosted Bitwarden with less new work than a small team starting from zero. Bitwarden publishes official Helm charts in its helm-charts repository under AGPL-3.0, which fits a GitOps workflow. The main question becomes whether your cluster standards, database operations and backup tooling can cover the server the same way they cover your other workloads.
- Helm charts: Official charts in the bitwarden/helm-charts repository give a repeatable deployment path, which you should review against your own chart policies before adopting.
- Database operations: The standard installation ships an MSSQL Express image with a 10 GB database size limit, so decide early whether you will keep that default or run a database your team already supports.
- Resource baseline: The Linux install guide recommends 4 GB of RAM and 25 GB of storage, a useful starting point for capacity planning on a shared cluster.
- Directory sync: Directory Connector, which is GPL-3.0, syncs users from AD, LDAP, Azure, Google Workspace or Okta, and it runs outside the chart, so plan its deployment separately.
- Lite option: Lite is not the answer for this team, because Bitwarden positions it for personal use and home labs.
Check with Bitwarden which chart version matches the server release you plan to run and how the license file is handled inside your cluster.
What your team runs in each model
This table lists the recurring tasks of running Bitwarden in the vendor's cloud against running the same server yourself, and marks who carries each one. Read the cloud column as what the vendor operates for you and the self-hosted column as what your team must staff, schedule and test. The main takeaway is that self-hosting moves upgrades, database care, host upkeep and incident response onto your side, while the licensing and migration questions remain even after you leave the cloud.
| Task | Bitwarden cloud | Self-hosted Bitwarden |
|---|---|---|
| Version upgrades | Vendor applies server releases to the hosted service | Your team applies releases; the server publishes monthly v2026.9.x releases and self-host v2026.10.0 followed in October 2026 |
| Database administration | Vendor operates the data store | Your team owns the database; the default MSSQL Express image carries a 10 GB database size limit to plan for |
| Container runtime | Vendor operates the runtime | Your team maintains Docker Engine 26 or later on the host |
| Backups and restore tests | Vendor-managed; confirm retention and restore terms in writing | Your team schedules database and file backups and tests restores; the migration guide lists attachments and invitations as items to redo |
| Monitoring and capacity | Vendor monitors the service | Your team watches CPU, memory, disk and database growth against the install guide's 2 GB minimum and 4 GB recommended RAM |
| SSO and Directory Connector sync | Configured in the cloud admin console; confirm SSO setup for your identity provider | Your team reconfigures SSO and runs Directory Connector (GPL-3.0) against AD, LDAP or Okta, then checks sync after each upgrade |
| Paid license renewal | Included in the cloud subscription | Your team downloads the license file from the cloud admin console and keeps it tied to the installation ID and matching data region |
| Incident response | Vendor responds to service incidents; confirm response windows in your contract | Your team detects, triages and restores the server, and owns the response plan and communication |
How the license file ties paid features to your installation ID
Self-hosting Bitwarden is free, but paid features do not switch on by themselves. The organization downloads a license file from the cloud web app (Admin Console, Billing, Subscription) and uploads it to the self-hosted server. That file is tied to the installation ID you obtained when you set up the server with a valid email address at bitwarden.com/host, and the installation ID's data region must match the region of the cloud organization the subscription belongs to. Before purchasing, confirm with Bitwarden which region your cloud organization sits in, confirm which region your installation ID was issued for, and record both in your change ticket so the mismatch is caught before anyone relies on the feature.
When the region does not match, the license is the wrong one for that installation, so the paid features you expected will not be available on the server. The failure is easy to miss during a pilot because the server still runs and the free functions keep working. The practical risks are SSO and enterprise policies that appear configured in the admin console but do not take effect, and an organization that discovers the gap only after users have been onboarded. Ask Bitwarden to confirm the exact behavior for a region mismatch in writing, and test the license on a non-production installation before you rely on it for production.
Keep two categories apart when you plan. The server code in the main repository is under AGPL-3.0, and the Bitwarden server license FAQ says code in the bitwarden_license directory, including the Commercial.Core and SSO integration modules, falls under the Bitwarden License. That license allows development and testing, but production use of those modules requires a paid subscription. Your license file is what makes those modules usable in production, so the cost decision and the region check belong together in one review, and the scope of any quote should name the features and seat count the license covers.
Moving from the Bitwarden cloud to self-hosted Bitwarden and what it leaves behind
The documented migration moves vault data and paid-feature entitlement from the cloud organization to a self-hosted server, but it does not carry over everything an administrator configured. Plan for the manual rebuild before you start.
Confirm the migration path for the current release
Before any data moves, check Bitwarden's migration guide against the release you plan to run, and ask Bitwarden to confirm in writing that the steps still apply to your cloud plan and self-hosted version. Record the server version you will install, since the server and self-host releases ship on a monthly cadence. Done means you have a dated note from the vendor or the current help article, and an agreed owner for each remaining step.
Inventory what the cloud organization holds
An organization administrator lists the items that will not come across in the data export: attachments on vault items, pending and active member invitations, collections and group assignments, enterprise policies, and the SSO configuration. Note each one with its owner and the people who will need to re-approve it. Done means you have a written list that the cutover checklist will reference, so nothing is discovered for the first time on cutover day.
Export organization data from the cloud
Using the cloud web app, the organization administrator runs an export of the vault data and stores the file in an encrypted location with restricted access. Confirm the export contains the items you expect by checking item counts against your inventory. Done means you hold a verified export file and a record of who created it and when. Treat the file as sensitive, because it contains credentials in readable form for anyone who opens it.
Download the license for the installation
The organization administrator downloads the license for paid features from the Admin Console, Billing or Subscription area of the cloud web app. The license is tied to your self-hosted installation ID, and its data region must match the region of the cloud organization, so confirm the region before you install. Done means the license file is saved next to the installation record and you have verified the region matches. A mismatch found here is far cheaper to resolve than one found after import.
Install the self-hosted server and create the account
Retrieve an installation ID and key from bitwarden.com/host using a valid email address, then install the self-hosted server following the Linux install guide. Create the self-hosted account using the same email address as the cloud organization owner, so the import has a matching owner. Apply the license file in the self-hosted admin settings. Done means the server answers, the owner account can sign in, and the license shows as applied.
Import the data and verify the vault
Import the export file into the self-hosted organization and compare item counts, folders and collection membership against the inventory from the first step. Sign in as a few test users in a non-production check to confirm that vault items open and decrypt. Done means the import report matches your counts and the test accounts can read the items they should. Keep the cloud organization in place until this check passes.
Rebuild attachments, invitations, policies and SSO
Work through the inventory and re-upload attachments, since the documented process does not carry them across. Re-send member invitations, reapply enterprise policies such as master password requirements and two-step login, and configure SSO against your identity provider with the self-hosted redirect addresses. Assign each task to a named owner and check each one off in the inventory. Done means every item on the list is either recreated and tested or formally accepted as not needed.
Plan the cutover window and retire the cloud
Schedule a cutover window with users, pause changes in the cloud organization during the export, and communicate the new sign-in address and any client settings they must update. Keep the cloud organization available for a fallback period you agree with your change board, and then decommission it on a documented date. Done means users have signed in to the new server, the rebuild list is closed, and the rollback path is recorded.
Questions buyers ask before choosing self-hosted Bitwarden
What does self-hosting Bitwarden cost, and what drives it up?
Running the server carries no Bitwarden software fee for the core code, but the total cost has several parts. The server code is licensed under AGPL 3.0, while the bitwarden_license directory, including Commercial.Core and SSO integration modules, is under the Bitwarden License, and production use of that code requires a paid subscription. Paid features also need a license file tied to your installation ID. Recurring costs include the host (the documented minimum is 2 GB of RAM and 12 GB of storage, with 4 GB and 25 GB recommended), backups, database capacity and staff time for patching. One-time costs include migration and integration work. Costs rise with user count, the number of paid features enabled and the number of environments you run. Ask any quote to itemize Bitwarden subscription terms, your hosting and DeployOpen's fixed-scope work separately.
How much ongoing effort does self-hosted Bitwarden need?
Expect a recurring operating load: monthly upgrades, host and database care, backups and monitoring. Bitwarden ships monthly releases, with server v2026.10.0 published on October 14, 2026 following the monthly v2026.9.x releases, so someone must test and apply each one. The standard Linux install requires Docker Engine 26 or later and ships an MSSQL Express image by default with a 10 GB database size limit, so disk and database growth need watching before the limit is reached. Kubernetes deployments use the official Helm charts. The effort grows with user count, attachment volume, the number of environments and how often you must prove restores work. Ask any proposal for a written run book covering upgrade cadence, database size monitoring and restore testing.
Who should own a self-hosted Bitwarden instance inside our organization?
Assign ownership to a named platform or IT operations team for the host, Docker, database, patching and backups, and to a security owner for admin console policies, SSO configuration and access reviews. Name at least two people who can perform a restore, so the instance is not dependent on one administrator. Choose the admin account carefully: the installation ID and installation key are retrieved with a valid email address from bitwarden.com/host, and the license file is downloaded from the cloud web app by an administrator of the cloud organization. That mailbox and account should be shared, monitored and documented. Decide who approves upgrades and who is accountable when a monthly release changes behavior in your environment.
Can our team run self-hosted Bitwarden without outside help?
A team with solid Linux, Docker and database skills can run the standard installation alone, provided it commits to a monthly upgrade routine and tested restores. The documented path covers the Linux install, the Helm charts for Kubernetes and the license workflow for paid features. The gaps tend to be the less routine tasks: the first migration from the cloud, SSO setup, disaster recovery drills and out-of-hours response. Check whether your Bitwarden subscription includes vendor support and at what level, because the researched facts do not settle that for you. If you want help, DeployOpen can plan, implement, harden, back up, upgrade and document a self-hosted platform inside your own infrastructure, and it offers retainers for ongoing support and upgrades.
How long does a migration from Bitwarden cloud to self-hosted take?
No duration is documented in the sources available here, so plan the migration against your own data and organization. Bitwarden's documented sequence is to export the organization's data, download the license, create a self-hosted account with the same email and import the data. Several items must be redone afterward: attachments, member invitations, enterprise policies and SSO. The schedule therefore depends on the number of organizations and collections, the volume of vault items and attachments, how many members must be re-invited and reconfigured, how many policies and SSO connections exist, and how long your users need for testing and cutover. Ask for a written plan that includes a dry run on a copy of the data and a rollback path, with timings agreed as part of the scope.
Does the Bitwarden license have to match our data region?
Yes, for paid features. Self-hosting itself is free, but paid features need a license file downloaded from the cloud web app (Admin Console, Billing, Subscription). That file is tied to the installation ID, and the installation's data region must match the region of the cloud organization. Decide the region before you install, because a mismatch affects which license you can apply. Confirm with Bitwarden which regions are available, how a region change is handled and what happens to the license if the installation ID is recreated. Region is a data residency question, so also confirm with your legal and compliance team where your vault data will be stored, since this page does not make any compliance claim.
Can DeployOpen run our self-hosted Bitwarden under a fixed-scope agreement?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support and upgrades are available as retainers. DeployOpen does not publish a price list, and a quote follows from the written scope. It is not a Bitwarden partner or reseller, so Bitwarden licensing and subscription terms remain a separate purchase. The written scope should name the deployment target, the migration steps, SSO integration, backup and restore testing, the upgrade cadence and handover. DeployOpen prepares evidence for compliance assessments but does not issue audit reports or certifications.
Where outside help changes the self-hosting decision
The self-hosting decision is mostly a question of who carries the operating work, and outside help changes that split without changing the license terms. DeployOpen plans, installs and hardens self-hosted platforms inside the client's own cloud accounts, data centers or air-gapped networks. For a Bitwarden server, that typically means sizing the host and database against the published minimums, choosing the database and reverse proxy, configuring the installation with the installation ID and key, and writing the upgrade and backup procedure that the team will run after handover. Those are the tasks that a small internal team often underestimates, because the server appears to work on day one.
Engagements are most often fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask for that written scope to name the Bitwarden components in play, including whether paid features are included, whether the license file workflow tied to the installation ID is covered, and how the migration from the cloud (export, license download, account creation, import and redoing attachments, invitations, enterprise policies and SSO) will be handled and tested. DeployOpen does not publish a price list, so a quote follows from that scope. Your procurement team should ask for the deliverables, the assumptions behind them and what the client must provide, such as the email address used for the installation ID and the network access the server needs.
Ongoing support, upgrades and continuous testing are available as retainers, which matters because Bitwarden ships monthly releases. Before you sign any retainer, confirm with DeployOpen what it covers: how upgrades are rehearsed, who restores from backup in a test, and how security testing of the deployed server is scheduled. Also confirm the limits. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports or certifications, so independent assessors remain responsible for those conclusions. Plan for the recurring cost of that support as a line item separate from the one-time implementation.
How DeployOpen scopes, delivers and supports self-hosted Bitwarden
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For Bitwarden, that means working out whether self-hosting fits your licensing, data region and operating model before any installation begins.
How we scope
- Written scope names the Bitwarden edition, paid features and license file needed for your organization.
- Scope records the installation ID, data region and cloud organization region that must match.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We deploy the official server in your cloud account, data center or air-gapped network.
- Database, backup, TLS and SSO integration are configured and tested against your identity provider.
- Directory sync and enterprise policy settings are reviewed and documented before users are onboarded.
How we hand over
- Handover documents the installation, license renewal steps and the cloud to self-hosted migration record.
- Runbooks cover upgrades, backups, restore tests and the monthly release cadence your team must follow.
- Your administrators receive written access, responsibility and escalation records before go-live.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover patching the server and Docker host on the vendor's release schedule.
- Ask any provider which parts of support fall to the vendor, which to your team, and which to DeployOpen.
