Which Bitwarden deployment fits a business team
Bitwarden documents lite for personal use and home labs, not business use, so a team that needs a shared, governed password vault should plan on the standard installation. The standard deployment is the multi-container setup that Bitwarden's Linux install guide describes, and it is the one that paid features attach to. Paid features need a license file downloaded from the cloud web app and tied to the installation ID, so the choice of deployment type affects how the organization licenses and supports the instance from day one. Before committing, confirm with Bitwarden which deployment type its current licensing terms cover for your organization.
Lite still has a legitimate place. A personal instance, a lab used to learn the server's behavior, or a short-lived test environment can run on it without the overhead of the standard stack. Lite is also the lighter option on paper: it needs at least 200 MB of RAM, while the standard installation's minimum in Bitwarden's Linux guide is 2 GB of RAM and 12 GB of storage, and lite supports MSSQL, PostgreSQL, SQLite and MySQL or MariaDB where the standard install ships an MSSQL Express image by default. Those are real advantages for a home lab. They do not change the documented scope. A team should choose the standard installation when it needs an administrative console for members, policies and SSO, when auditors will ask about the supported deployment path, or when it expects to grow beyond a handful of users. Ask Bitwarden to confirm which features and support apply to each deployment type before you rely on either.
The cost of switching later is the main reason to decide early. Bitwarden's migration guide covers moving from cloud to self-hosted, but it describes the process as an export and import in which attachments, member invitations, enterprise policies and SSO must be redone. A move between two self-hosted deployment types is not documented as a simple swap, so plan it as a rebuild of users, collections and policies. Before the first production user signs in, ask Bitwarden how a lite instance would be migrated to the standard installation, what data carries over, and which settings you would reconfigure by hand.
Standard and lite side by side
This table compares Bitwarden's standard multi-container installation with the single-container lite deployment on the factors a buyer needs to settle first: intended use, databases, sizing, licensing and migration. Read the rows for intended use and paid feature licensing first, since they decide whether lite is even an option for a business. Items marked to confirm have no supplied fact and should be checked with Bitwarden before you commit.
| Factor | Standard installation | Lite deployment |
|---|---|---|
| Intended use | Self-hosted deployment for organizations running Bitwarden on their own infrastructure | Intended for personal use and home labs, not business use, according to Bitwarden's lite guide |
| Container layout | Multi-container installation with the MSSQL database image shipped by default | Single container |
| Supported databases | MSSQL Express image ships by default with a 10 GB database size limit | MSSQL, PostgreSQL, SQLite and MySQL or MariaDB |
| Minimum RAM and storage | 2 GB RAM, 12 GB storage, x64 1.4 GHz processor minimum | At least 200 MB of RAM; storage figure to confirm with Bitwarden |
| Recommended RAM and storage | 4 GB RAM and 25 GB storage | Recommended figures to confirm with Bitwarden |
| Docker requirement | Docker Engine 26 or later | Confirm the container runtime requirements in Bitwarden's lite guide |
| Installation ID and key | Required, retrieved with a valid email address from bitwarden.com/host | Confirm whether an installation ID and key are required |
| Paid feature licensing | Paid features need a license file from the cloud web app, tied to the installation ID and matching data region | Confirm whether paid features can be licensed on lite before relying on them |
| Documented migration path | Cloud to self-hosted migration documented; attachments, invitations, policies and SSO must be redone | Confirm the supported migration path to or from standard with Bitwarden |
How the standard install and lite are built
Bitwarden's two self-hosted options differ mainly in how many moving parts you run and where the vault data lives. The cards below separate the standard install's components from the lite container, so you can check backups, data placement and failure domains against your own environment before choosing.
Standard install is multi-container
The standard self-hosted installation runs several containers that work together, with MSSQL as the default database. Each container is a separate failure point and a separate thing to patch, monitor and restart. Ask Bitwarden which containers a given release starts, and confirm how your team will upgrade them together during a monthly release cycle.
MSSQL Express is the default
The Linux install guide ships an MSSQL Express image by default, and that edition carries a 10 GB database size limit. The vault data sits in that database, so the limit caps how large your organization's stored data can grow. Plan to watch database size over time, and confirm with Bitwarden how to move to a fuller SQL Server edition if you approach the limit.
Hardware floor and headroom
The install guide lists a minimum of 2 GB of RAM and 12 GB of storage, and recommends 4 GB of RAM and 25 GB of storage. Storage must hold the database, attachments and container images, so size the disk for growth and for keeping several backups. Confirm the Docker Engine version you need, since the guide requires Docker Engine 26 or later.
Lite runs as one container
Bitwarden lite packs the server into a single container and supports MSSQL, PostgreSQL, SQLite and MySQL or MariaDB. Choosing the database is the main decision, because the database holds the vault and is the component you must back up. Note that lite is intended for personal use and home labs, not business use, so its simpler layout is not a reason to use it for a company.
Database choice drives backups
With lite, the database engine you pick determines how backups, restores and point-in-time recovery work. SQLite stores data in a single file that is easy to copy but must be backed up while the server is stopped or consistent. PostgreSQL, MySQL, MariaDB and MSSQL each have their own dump and restore tooling. Test a full restore on a separate host before you rely on either option.
Failure domains and what to confirm
Both layouts run on one host unless you design otherwise, so a single server failure takes down the vault and its backups together. Bitwarden's documentation does not establish high availability for these installs in the material reviewed here, so ask Bitwarden directly about clustering or failover before assuming it exists. Keep backups on a separate system and record the installation ID and license file location.
Sizing a Bitwarden install: from 200 MB to 4 GB of RAM
The documented minimum for a standard install is an x64 processor at 1.4 GHz, 2 GB of RAM and 12 GB of storage, with Bitwarden recommending 4 GB of RAM and 25 GB. The standard installation also requires Docker Engine 26 or later. Lite has a far lower floor: Bitwarden's lite deployment guide lists at least 200 MB of RAM. That gap reflects architecture, not a difference in how much security one option gives. The standard stack runs several containers and a full database server, while lite runs as a single container. Treat the 200 MB figure as a floor for personal use and home labs, since Bitwarden positions lite for those settings and not for business use. Confirm the current hardware guidance in the Bitwarden Linux install guide before you order hardware.
Several factors push a standard install from the minimum toward the recommendation. User count drives concurrent sync and admin activity, and the number of vault items, collections and organizations grows the database over time. Attachments are a common surprise because they consume storage outside the normal item records, so ask how many users will store files in their vaults and how large those files typically are. The bundled MSSQL Express image carries a 10 GB database size limit, so database growth is a sizing input you must plan for, not a footnote. If the vault population could approach that ceiling, the team should plan a different database edition or a migration path before the limit is reached. Bitwarden's documentation should be the source for any user-count-based sizing, so ask the vendor directly for guidance matched to your headcount and growth forecast.
Before you commit to a size, run a short check. Record the expected number of users, the expected attachment volume and the growth rate you can defend, then compare those against the documented minimums and recommendations. Confirm which database the install will use and whether the default MSSQL Express image meets your ceiling. If the answer is unclear, the cost of a wrong guess is a rebuild, so document the sizing assumptions in writing and ask Bitwarden to confirm them. Lite may fit a single-person or home-lab use case, but for any shared business vault, size for the standard installation.
Which deployment fits which situation
A single person or a household running a vault on hardware they control is the case lite was built for. Bitwarden's lite guide describes a single container that needs at least 200 MB of RAM and can use MSSQL, PostgreSQL, SQLite or MySQL or MariaDB. Bitwarden positions lite for personal use and home labs, so a family vault sits inside the purpose the vendor states. The standard multi-container install adds more moving parts than a one-user setup usually needs.
- Hardware floor: lite needs at least 200 MB of RAM, so a small host or spare machine can run it.
- Database choice: SQLite keeps the setup simple for one user, but the database file still needs regular, tested backups.
- Stated purpose: Bitwarden positions lite for personal use and home labs, so keep the deployment within that scope.
- Upgrades: each new release means pulling the updated image, reading the release notes and restarting in a planned window.
Before you store important credentials, confirm the current lite requirements in Bitwarden's lite deployment guide and test a full backup and restore onto a second machine.
A small team that wants to test Bitwarden before committing should evaluate the standard installation. It is the closer match to how an organization would run the product, and the setup steps differ from lite in ways that affect sizing. The Linux install guide requires an installation ID and installation key, retrieved with a valid email address from bitwarden.com/host, so the person who requests them needs a mailbox the team controls.
- Identity for the install: request the installation ID and key with a mailbox that will outlive the pilot.
- Sizing: the guide lists a minimum of 2 GB of RAM and 12 GB of storage, but recommends 4 GB and 25 GB, so size the pilot to the recommendation.
- Container runtime: Docker Engine 26 or later is required, so check the host before installing.
- Database ceiling: the default MSSQL Express image limits the database to 10 GB, so estimate vault and attachment growth during the trial.
Features that depend on a license file cannot be tested until a license is installed, so plan the pilot around which features the team actually needs. Confirm the Docker Engine version, the expected database growth and the licensing path in the Linux install guide before the pilot starts.
An organization that needs paid features or single sign-on has to plan around licensing, not just installation. Bitwarden states that self-hosting is free, but paid features need a license file downloaded from the cloud web app's Admin Console, Billing and Subscription pages. That file is tied to the installation ID, and the installation's data region must match the cloud organization's region. Under the server license FAQ, code in the bitwarden_license directory, including the SSO integration modules, may be used for development and testing, but production use requires a paid subscription.
- License binding: the license file is tied to the installation ID, so a rebuilt server may need a new license or ID workflow.
- Region match: confirm the data region of the installation matches the cloud organization before you download the license.
- Directory sync: Directory Connector, licensed GPL-3.0, syncs users from AD, LDAP, Azure, Google Workspace or Okta, and its fit should be tested against your directory.
- Lite compatibility: the lite guide frames lite around personal use, so ask Bitwarden in writing whether paid features and SSO are licensed on lite.
Get written confirmation of licensing for the exact deployment option you plan to run, including how a license is reissued after a rebuild. The licensing for paid features page is the starting point for that conversation.
A regulated organization or an IT department running Bitwarden as a managed service needs repeatable installs, documented versions and a clear support path. The standard installation is the option that fits that model. Bitwarden publishes official Helm charts for Kubernetes in the bitwarden/helm-charts repository, licensed AGPL-3.0, so platform teams can deploy through their existing change process. Lite is positioned for personal use and home labs, so an assessor will expect the standard deployment for business use.
- Pinned versions: record the exact server and self-host release in use, such as the v2026.10.0 release published on October 15, 2026, and test each upgrade before production.
- Release cadence: Bitwarden ships monthly v2026.9.x-style releases, so plan a recurring test and change window.
- Migration: if you move from cloud, attachments, member invitations, enterprise policies and SSO must be redone according to the migration guide.
- Evidence: keep install records, license files, backup test results and change tickets. DeployOpen prepares this evidence, but auditors and certification bodies issue any attestation.
Confirm with Bitwarden the support terms for your chosen deployment, and check with your assessor whether the standard installation and Helm path meet the scope of your review. The Helm charts repository is the natural next read for platform teams.
Upgrades, backups and skills for each deployment
This table compares what each self-hosted Bitwarden option asks of your team after go-live: upgrades, backups, monitoring and the Linux, Docker and database skills needed. The main takeaway is that the standard installation adds an installation ID step, a license file path for paid features and a heavier database footprint, while lite offers a lighter stack that Bitwarden positions for personal use and home labs.
| Capability | Standard installation | Lite deployment |
|---|---|---|
| Release cadence | Monthly v2026.9.x releases, followed by server v2026.10.0 (October 14, 2026) and self-host v2026.10.0 (October 15, 2026) | Confirm with Bitwarden that lite images follow the same monthly release line before scheduling upgrades |
| Install prerequisites | Installation ID and installation key from bitwarden.com/host, using a valid email address | Confirm whether lite requires an installation ID and key, since the standard install does |
| Container and database | Multi-container stack with the MSSQL Express image by default, which has a 10 GB database size limit | Single container with a choice of MSSQL, PostgreSQL, SQLite or MySQL or MariaDB |
| Hardware baseline | Minimum 2 GB RAM and 12 GB storage; recommended 4 GB RAM and 25 GB storage | At least 200 MB RAM, per Bitwarden's lite deployment guide |
| Backup responsibility | Your team backs up the MSSQL database and the installation data directory; confirm exact paths in the install guide | Your team backs up the database you chose; for SQLite, confirm the safe copy method for the database file |
| Monitoring focus | Container health, database growth against the 10 GB limit, disk space and certificate expiry | Container health, disk space and database growth; fewer components to watch |
| Skills required | Linux administration, Docker Engine 26 or later, and MSSQL administration for backups and restores | Basic Docker operation plus administration of whichever database engine you selected |
| Intended use | Supports paid features through a license file tied to the installation ID, which suits business deployments | Intended for personal use and home labs, not business use, so confirm fit before any team rollout |
Paid features, licensing and the installation ID
Self-hosting Bitwarden is free, but paid features need a license file that you download from the cloud web app, from the Admin Console under Billing and Subscription. That license is tied to your installation ID, and the data region of the installation must match the region of the cloud organization that issued the license. Before you choose either deployment, confirm which paid features your organization needs (enterprise policies, SSO, directory sync or similar) and check that the cloud organization sits in the same region as the server you plan to run. A mismatch is a problem you find after the install, so resolve it first. The installation ID and installation key are retrieved at bitwarden.com/host with a valid email address, and the standard installation guide describes that step.
The source code is split across two licenses. The main server code is AGPL-3.0, but files in the bitwarden_license directory, including the Commercial.Core and SSO integration modules, fall under the Bitwarden License. That license is source-available and does not meet the OSI definition of open source. Under its terms, you may use that code for development and testing, but production use requires a paid subscription. In practice, a lab or a staging copy can run the full code, while a production installation that relies on those modules needs a subscription. Read the Bitwarden server license FAQ before you decide which environment hosts which copy.
The documentation this page relies on does not state whether the lite deployment can hold paid features, so do not assume either answer. Ask Bitwarden directly whether a lite installation can accept a license file, apply the installation ID and region rules, and receive SSO and directory features. Get the answer in writing, with the version it applies to, because lite is positioned for personal use and home labs rather than business use. If the answer is no, the standard deployment is the only path for paid features, and that affects the database, hardware and operating effort you plan for.
Moving from lite to standard or from cloud to self-hosted
This sequence moves an existing Bitwarden vault into a new self-hosted instance with its paid features licensed and its data intact. The documented path covers cloud to self-hosted moves, so the lite to standard step needs confirmation from Bitwarden before anyone relies on it. Plan the sequence before users depend on the instance, because several items must be rebuilt by hand.
Confirm the lite to standard path with Bitwarden
Before any data moves, ask Bitwarden in writing whether a lite instance can be migrated to the standard multi-container installation, and which database and version each side uses. The documented migration guide describes moving from the cloud to a self-hosted server, so do not assume the same steps apply to a lite move. The platform or IT lead should file the answer with the change record. The output is a written confirmation or a stated alternative, filed before any export starts.
Inventory what the source instance holds
List every attachment, member, collection, enterprise policy and SSO setting in the source vault. The documented path says attachments, invitations, policies and SSO must be redone after import, so these items need the most attention. Record who administers each one and which users depend on it. The source organization administrator should complete this from the admin console. The output is a written inventory with named owners, which becomes the checklist used in the rebuild step.
Create the target installation ID and key
On the new standard server, request an installation ID and installation key from the Bitwarden host portal using a valid email address. Use a mailbox the team controls, because that address stays tied to the installation and must receive later notices. Check the Linux install guide for the default MSSQL Express image and its 10 GB database size limit before you size storage. The output is a stored ID and key recorded against the new installation.
Export the organization data from the source
Export the organization data from the source instance by following the documented migration steps. Store the export file encrypted and restrict access to the people who will run the import. Take the export after member changes are paused, because anything changed after the export will be missing from the new instance. Compare the item counts in the export with your inventory. The output is a verified export file and a short record of the counts.
Download the license for the new installation
Paid features need a license file downloaded from the cloud web app, found under the Admin Console, Billing and Subscription. The license is tied to the installation ID from the earlier step, and the cloud organization's data region must match the region of the new server. Confirm the region before downloading, because a mismatch will cause licensing problems. Keep the file with the installation records. The output is a license file matched to the installation ID and region, placed on the new server.
Create the self-hosted account and import data
Create the self-hosted account using the same email address as the cloud account, because the documented path requires it. Then import the exported data into the new organization. Check a sample of member logins and item counts against the export record. Differences should be investigated before the import is accepted. The output is an imported organization whose counts match the export, with a signed note explaining any gaps.
Rebuild attachments, invitations, policies and SSO
Re-upload attachments, re-send member invitations, reapply enterprise policies and reconfigure SSO, because the documented migration requires each of these to be redone. Work from the inventory and assign each item to a named owner. Test SSO sign-in with a non-admin account before inviting the full group, and confirm that enterprise policies behave as expected for that test user. The output is a completed checklist where every item carries a tester's sign-off.
Cut over users and retire the old instance
Announce the cutover to members, direct them to the new server, and stop accepting changes on the old instance. Keep the old instance available until the checklist is signed off and sign-in, imports and licensed features have been confirmed on the new one. Confirm the backup plan for the new server before users depend on it. The output is a retirement record that states when the old instance was closed and who approved the change.
Questions buyers ask before choosing a Bitwarden deployment
Is Bitwarden lite supported for business use?
No. Bitwarden's lite deployment guide positions the lite option for personal use and home labs, not business use, so a company vault belongs on the standard multi-container installation. Lite does support a choice of databases, including MSSQL, PostgreSQL, SQLite and MySQL or MariaDB, and it needs at least 200 MB of RAM. The practical question for a team is not whether lite can run, but whether the vendor's intended use matches the workload. Check the current guidance in the Bitwarden lite deployment guide before you commit, and record the answer in your design review so the decision is traceable later.
How much RAM and storage does a standard Bitwarden install need?
Bitwarden's Linux install guide lists a minimum of an x64 1.4 GHz processor, 2 GB of RAM and 12 GB of storage, and recommends 4 GB of RAM and 25 GB. It also requires Docker Engine 26 or later. The default database image is MSSQL Express, which carries a 10 GB database size limit, so plan for growth in attachments and event history and check whether a larger database edition fits your design. Treat the recommended figures as the planning baseline and test your own user count before sizing production hosts. The Linux install guide is the source to confirm current values.
What drives the cost of running a self-hosted Bitwarden server?
Cost has four parts: infrastructure, staff time, paid licensing and any outside help. Infrastructure is the VM or cluster, storage, backups and network, and it recurs monthly. Staff time covers patching the Docker host, rotating the installation key, testing restores and watching the database size limit. Paid features need a license file from the cloud Admin Console, tied to the installation ID, so budget for the subscription if you use enterprise policies or SSO. Outside help is usually a fixed-scope deployment plus an optional retainer for upgrades. Ask any provider for a written scope listing hosts, backup targets, upgrade cadence, licensed features and who owns each recurring task.
How long does a standard Bitwarden deployment take, and what does the team need?
The duration depends on the readiness of your environment, not on a fixed number. Before installation you need a Linux host that meets the minimums, Docker Engine 26 or later, a DNS name and TLS certificate, and an installation ID and key retrieved with a valid email address from bitwarden.com/host. You also need a named owner for the server, an identity decision for SSO, and a backup and restore test plan. Teams that already run Docker and reverse proxies typically move faster. Ask your implementation partner for a timeline in the written scope, with dependencies such as certificate issuance and identity provider access listed separately.
Can our own team run Bitwarden without outside help?
Yes, many teams with Linux and Docker experience run the standard installation in-house, but the work does not stop after go-live. Your staff must keep the host patched, apply each monthly release, test backups and handle incidents without a vendor on call. Bitwarden publishes server and self-host releases on a regular monthly cadence, so someone must own the upgrade calendar. Decide before you start whether your team has the time and skills for that duty. If not, a retainer covering upgrades, backups and documentation can be scoped separately from the initial build, and the scope should state which party is responsible for each task.
How do we move from lite or standard to another Bitwarden setup later?
Plan the move as a data migration plus a configuration rebuild. Bitwarden documents a cloud to self-hosted migration in which the organization exports its data, downloads its license, creates a self-hosted account with the same email and imports the data. Attachments, member invitations, enterprise policies and SSO must be redone after the import. Moving from lite to standard is not described as a simple in-place upgrade in the sources available here, so confirm the path with Bitwarden before you change databases. Keep regular encrypted backups and a documented restore test so the migration has a known good starting point.
Which licensing rules apply to a self-hosted Bitwarden server?
The main server code is licensed under AGPL 3.0, but files in the bitwarden_license directory, including Commercial.Core and SSO integration modules, fall under the Bitwarden License. That license is source-available rather than open source under the OSI definition, and it allows development and testing use. Production use of that code requires a paid subscription. Self-hosting itself is free, but paid features need a license file tied to the installation ID, and its data region must match the cloud organization's region. Read the server license FAQ before you plan which features the production server will use.
Does a Bitwarden deployment need a container orchestrator?
No, the standard installation runs on a Docker host, but Bitwarden also publishes official Helm charts for Kubernetes in the bitwarden/helm-charts repository, licensed AGPL-3.0. Choose Kubernetes only if your platform team already runs and patches clusters, backs up persistent volumes and monitors them. A single Docker host is simpler to reason about for a small deployment, but it concentrates risk on one machine. Confirm the chart version against the current self-host release and test your restore path in the same way whichever route you choose.
What a scoped Bitwarden deployment review covers
A scoped review starts by fixing the deployment decision before anyone installs anything. DeployOpen would first confirm the intended use of the vault (business, personal or a home lab), the number of users who will sign in, the data region the cloud organization sits in, which paid features the organization needs, and whether the team has a database preference. Those five answers decide most of the choice between the standard multi-container installation and the single-container lite deployment. Bitwarden positions lite for personal use and home labs, not business use, so an organization that expects admin console controls, enterprise policies or SSO should treat that as a disqualifying fact early, not a detail to resolve later.
Paid features need a close look because they change the licensing work. Self-hosted paid features require a license file downloaded from the cloud web app and tied to the installation ID, and the data region of that installation must match the cloud organization's region. The review should list each paid feature the team relies on, confirm it is available on the chosen deployment with Bitwarden before scope is fixed, and record who holds the cloud account that will download the license. A standard installation also needs an installation ID and key from bitwarden.com/host, so the review should name the person who will request them and the mailbox that receives them.
DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms inside the client's own infrastructure, so the written scope would state where the containers run, who operates them, how backups are taken and tested, and what documentation the client receives. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so the reader should ask for a quote that follows from that written scope and separates one-time work (planning, installation, hardening, migration) from recurring work (upgrades, monitoring, support, retainers). Ask whether Bitwarden's own support terms apply to the chosen deployment and what the client's internal team must keep running after handover.
How DeployOpen works on this
DeployOpen plans, implements, hardens, backs up and documents self-hosted Bitwarden inside your own infrastructure, whether that means the standard multi-container installation or a lite deployment for a narrow use case. We start by confirming which deployment option your organization can support, then agree the scope in writing before any work begins.
How we scope
- Confirm the user count, business use case, and whether paid organization features are required before choosing a deployment option.
- Document where the installation will run, including cloud account, data center or air-gapped network, and the database platform you need.
- Agree the written scope, deliverables and timeline before work starts, since most engagements are fixed-scope.
- Ask Bitwarden to confirm the license file, installation ID and data region requirements for any paid features in scope.
How we build
- Install the standard deployment or lite container on your infrastructure and configure the database, TLS and reverse proxy settings.
- Size the host against Bitwarden's published minimums and recommendations, then validate them with your expected vault and user load.
- Harden the host, container runtime and database access, and check that the chosen configuration matches your written scope.
- Test login, vault sync, backup and restore, and any SSO or directory integration in a staging environment before cutover.
How we hand over
- Deliver runbooks covering installation, upgrades, backups, restores and the monthly release cadence your team will follow.
- Document the chosen deployment option and the reasons for it, so auditors and future administrators can see the design decisions.
- Walk your administrators through the admin console, license handling and the steps to migrate later if requirements change.
- Record the configuration, access model and evidence your compliance assessment will ask for, without issuing any attestation.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the initial engagement.
- Retainers can cover applying new Bitwarden self-host releases, reviewing changes and re-running restore tests after each upgrade.
- If your needs outgrow lite, we can scope a move to the standard deployment as a new written engagement with its own deliverables.
- Ask any provider, including DeployOpen, to state in writing who handles vendor escalations and what the support window covers.
