Bitwarden self hosted: the official server on a dedicated machine

Official server, lite, or Vaultwarden

There are three common ways to put Bitwarden clients against your own server, and they are different software. The standard deployment is Bitwarden's own server, aimed at IT professionals and system administrators; Bitwarden's docs rate the Linux script method as needing intermediate to advanced skill. Bitwarden lite, the single-container build renamed from Bitwarden Unified in December 2025, is described by Bitwarden as intended for personal use and home labs, not for business contexts. Vaultwarden is a separate, unofficial server; we cover it on the Vaultwarden self-hosted page.

Bitwarden's own FAQ says it expects most client functions to work against non-official servers such as Vaultwarden, but cannot guarantee it, and that its support may be limited if you run one. If the vault belongs to a business and you want vendor support, licensed organisation features and Bitwarden's release cadence, run the standard deployment. That is what the rest of this page does.

What the standard deployment needs

The figures are Bitwarden's, for the Linux standard deployment. The bundled MSSQL Express database needs no extra licence but stops at 10 GB of relational data; past that, Bitwarden supports an external MSSQL server of version 2019 or later. The host OS must be under active mainstream vendor support. Lite, for comparison, asks for at least 200 MB of RAM and 1 GB of storage, which is why it suits a small board at home and not a company vault.

Which of our machines fit

The recommended spec is small, so the question is less about cores than about isolation and recovery. Every x64 line on the dedicated server range clears Bitwarden's minimum. For the recommended 2 GHz dual core, pick a line at 2 GHz or above, such as the Intel Atom C2750 cartridge (8 cores at 2.4 GHz, 8 to 32 GB) or the Intel Xeon E3-1585L v5 cartridge (4 cores at 3 GHz, NVMe); several lines run at 1.7 to 1.8 GHz with more cores. A cartridge gives the vault a whole machine for one job, which is what that class is for. Bitwarden lists only x64 processors for the standard deployment and names ARM support as a feature of lite, so we read the standard deployment as x64 only and would not put it on the X-Gene ARM cartridge or the Ampere Altra line.

Pick a single-socket rack server when you want the out-of-band console: every racked single-, dual- and quad-socket server has HPE iLO, Dell iDRAC or a Supermicro BMC, while most cartridges have power control only (the m510 and m710x have a console). A console matters on a firewall-first build, because a wrong rule locks you out of SSH and the console still reaches the screen. Racked machines are handed over in about 30 minutes once payment is approved; ready servers lists what is racked now.

Installing it on Ubuntu

1. Point a DNS record at the server. Bitwarden suggests a hostname that does not contain the word Bitwarden, so the name does not advertise what runs there. It cannot be served from a subfolder of a domain.
2. Fetch an installation id and key at bitwarden.com/host with a valid email, choosing the data region (US or EU) your cloud account or organisation lives in. Bitwarden uses them to register the install, authenticate to its push relay and validate licences, and says to treat both as secrets and never reuse them across installations.
3. Install Docker Engine with the Compose plugin, then turn the firewall on (next block) before any container starts.
4. Create the bitwarden service account and /opt/bitwarden as below. Bitwarden warns against installing as root. Give the account a strong password: membership of the docker group controls every container on the host.
5. Run the installer as that user and answer its prompts: domain, Let's Encrypt (y, with an email for expiry notices), the installation id, the key, then the region.

sudo ufw default deny incoming
sudo ufw default allow outgoing
grep '^IPV6=' /etc/default/ufw
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

The grep must print IPV6=yes, so every rule also gets a v6 twin; ufw status verbose then lists each port twice. Bitwarden needs both 80 and 443 and does not run on one port alone. Keep in mind Docker's own documentation: published container ports are routed before ufw sees them, so ufw guards SSH and anything else on the host, not the containers. After the first start, sudo ss -tlnp shows every listener on IPv4 and IPv6; nothing beyond 22, 80 and 443 should face the internet. IPv6 on our servers is added at checkout at no charge; if you publish an AAAA record, test the vault over it.

sudo adduser bitwarden
sudo groupadd docker
sudo usermod -aG docker bitwarden
sudo mkdir /opt/bitwarden
sudo chmod -R 700 /opt/bitwarden
sudo chown -R bitwarden:bitwarden /opt/bitwarden
sudo -iu bitwarden
cd /opt/bitwarden
curl -Lso bitwarden.sh "https://func.bitwarden.com/api/dl/?app=self-host&platform=linux" && chmod 700 bitwarden.sh
./bitwarden.sh install

groupadd docker reports an error if the Docker package already created the group; that is harmless. The installer creates ./bwdata beside the script, and the 700 mode keeps it readable by the bitwarden user alone.

Mail, the admin portal and sign-ups

Bitwarden treats SMTP as required on a self-hosted server: it sends account verification, organisation invitations and the admin portal login links. Set the values in ./bwdata/env/global.override.env, using port 587 with STARTTLS as Bitwarden's SMTP guide recommends, then run ./bitwarden.sh restart. The same file holds the database password, which is one more reason the directory stays at mode 700.

globalSettings__mail__replyToEmail=no-reply@example.com
globalSettings__mail__smtp__host=mail.example.com
globalSettings__mail__smtp__port=587
globalSettings__mail__smtp__ssl=false
globalSettings__mail__smtp__startTls=true
globalSettings__mail__smtp__username=vault@example.com
globalSettings__mail__smtp__password=CHANGE_ME
adminSettings__admins=ops@example.com
# add once your own account exists:
globalSettings__disableUserRegistration=true

The System Administrator Portal lives at /admin on your domain. It has no password: it emails a magic link, valid for 15 minutes, and only to addresses listed in adminSettings__admins (comma-separated). From it an admin can see versions and configuration, and view and delete users and organisations, though not read vault items. Our advice: list only addresses on a mailbox with its own two-step login, because whoever reads that inbox holds the portal.

Registration is open by default, so anyone who reaches the URL can create an account. Start the stack with ./bitwarden.sh start, register and verify your own account, then set globalSettings__disableUserRegistration=true and restart. Further people join by organisation invitation.

Backups, restores and updates

While the mssql container runs, Bitwarden backs up the database every night into ./bwdata/mssql/backups and keeps each file 30 days. Those files share a disk with the live database, so a disk failure takes both. Bitwarden recommends backing up the whole ./bwdata directory as well, above all env (variables and passwords), core/attachments, mssql/data and core/aspnet-dataprotection (framework-level data protection covering authentication tokens and some database columns).

• Trigger an extra database backup at any time with docker exec -i bitwarden-mssql /backup-db.sh; it takes no terminal, so it is safe in cron.
• Copy an archive of ./bwdata to storage off the machine. It contains secrets: keep it mode 600 and encrypt it before it leaves.
• Restore by loading a .BAK file with sqlcmd inside the mssql container, offline restore preferred, then restart, per Bitwarden's backup guide.
• Update with ./bitwarden.sh updateself followed by ./bitwarden.sh update, after a backup. Self-hosted releases trail the cloud by several days, so the portal may announce a version you cannot install yet.

Licences for paid features

The server itself is free to self-host; paid features are unlocked with a licence file from your Bitwarden cloud account. A Premium user downloads it under Settings, Subscription and uploads it on the self-hosted vault. Only Families and Enterprise organisations can be self-hosted: the organisation is created in the cloud first, its licence is downloaded against your installation id, and one organisation deployment is allowed per subscription. After each renewal the self-hosted licence must be updated within 60 days or the organisation is disabled. Billing sync replaces re-uploading the file by hand, but it takes several steps: set globalSettings__enableCloudCommunication=true and globalSettings__baseServiceUri__cloudRegion (US or EU, plus the EU identity, API and push URIs for an EU organisation) in global.override.env, run ./bitwarden.sh rebuild and start the server again, allow outbound HTTPS to Bitwarden's API and identity hosts, then paste a billing sync token generated in the cloud Admin Console. After each renewal you still press Sync license. Families organisations update by manual upload only, and sync cannot be set up during a free trial.

Where one server is the wrong answer

For high availability Bitwarden recommends its Helm chart on Kubernetes, not one Docker host; a single machine is a single point of failure, and the backup plan above is what stands behind it. If nobody on the team is comfortable with Linux, Docker and database restores, Bitwarden's own cloud is the lighter path. For one person's vault on a small board, lite is the documented fit. Moving an existing install to a new machine follows Bitwarden's migration guide; our migration page covers the cutover and DNS side.