Self-hosting Bitwarden: a complete guide to setting up your own server

Passwords remain the preferred entry point for many attacks: it's estimated that around 81% of data breaches are related to weak, reused, or stolen credentials. Furthermore, only one in three people in the United States uses a password manager, and the average cost of a data breach in 2025 is projected to be around $4,44 million. Bitwarden is an open-source password manager with browser, desktop, and mobile applications, and its self-hosted version allows you to store your team's encrypted vaults on your own server. The key is that you decide where the vault resides and who can access the infrastructure.

There are two main paths: the official Bitwarden server, deployed with Docker on Linux or Windows and offering the brand's complete ecosystem, and Vaultwarden, an unofficial reimplementation written in Rust that consumes significantly fewer resources. Both use the same protocol and work with the official clients, so compatibility with Bitwarden apps is guaranteed in both cases , although support, maintenance, and some available features differ.

What are the benefits of having the vault on your own server?

By setting up Bitwarden on a VPS or your own machine, you gain sovereignty over your data: the encrypted storage never leaves an infrastructure you control. You also get continuous availability, dedicated CPU, RAM, and disk resources, and the ability to scale from personal use to a mid-sized team without changing tools. Added to this is a significantly lower cost compared to maintaining physical hardware and the advantage of standard provider protections, such as DDoS mitigation, regular backups, and network security. Control, availability, and reasonable cost go hand in hand with this type of deployment.

The practical difference between the official Bitwarden and Vaultwarden becomes apparent when we talk about support. The official server is designed for enterprise environments, with contracts, audits, and guarantees for third-party integrations; Vaultwarden is a community project without SLAs or commercial support, but it unlocks features that in Bitwarden typically require a paid plan, such as organizations, two-step authentication, Bitwarden Send, TOTP, and attachments. For a company with formal requirements, the official server is usually a better fit ; for a homelab or a small group, Vaultwarden is very appealing.

If you choose a VPS, look for root access, Docker compatibility, and a stable public IP address. Some providers offer AMD Ryzen 9 processors up to 5,7 GHz, NVMe storage, connections up to 40 Gbps, a 99,95% SLA, and a presence in a dozen cities. As a reference, for fewer than ten users, 2 cores, 4 GB of RAM, and 25 GB of NVMe storage are usually sufficient ; for teams of 10 to 50 people, aim for 4 cores, 8 GB of RAM, and 50 GB of storage.

Requirements and preparation before installation

Before you begin, you'll need a domain with an A DNS record pointing to your server's IP address, for example, vault.yourdomain.com. Ports 80 and 443 must be free and accessible, as Bitwarden's Nginx uses them directly; port 80 is required to validate and renew Let's Encrypt certificates. You'll also need an SMTP server to send verifications and invitations, and an account with administrative or sudo privileges. The installer will ask for an installation ID and key, which can be generated for free at bitwarden.com/host. Without SMTP, you won't be able to verify emails or invite others , and without a domain and open ports, the TLS certificate won't work.

On Linux, the official server requires a minimum of 2 GB of RAM and 12 GB of disk space, although 4 GB of RAM and 25 GB of free space are recommended. On Windows Server, the requirements are significantly higher: 6 GB of RAM and 76 GB of storage as a minimum, with 8 GB and 90 GB recommended for production. Furthermore, Windows Server requires nested virtualization; Azure requires the use of Standard D2s v3 virtual machines with the standard security type, not Trusted Launch. Windows consumes considerably more resources and requires prior verification that the hypervisor supports nested virtualization.

Vaultwarden completely changes the scale: with just 512 MB of RAM it can run smoothly, making it suitable for a Raspberry Pi or a very modest VPS. That's one of its biggest advantages over the official .NET server, which runs a dozen containers, including SQL Server. If resource efficiency is your priority, Vaultwarden has a clear advantage.

Before you begin, decide how you're going to manage your SSL certificate. You can let Let's Encrypt generate it during installation, use a purchased certificate or one issued by an authority, or use a self-signed certificate for testing purposes only. For email, gather your SMTP host, port, username, password, and sender address. A self-signed certificate is suitable for testing, but not for production.

Installing the official Bitwarden on Linux

The usual starting point is Ubuntu 24.04 LTS, although the steps can be adapted to Debian 12 and Rocky Linux 9 by changing the package manager. Update the system and open the necessary ports in the firewall. With UFW, this would be as simple as allowing ports 80/tcp and 443/tcp and reloading the firewall rules. Don't forget to keep SSH accessible so you don't get locked out of the server.

Bitwarden runs on Docker, so install Docker Engine 26.0 or higher and the Docker Compose V2 plugin. You can do this from the official Docker repositories or, on Ubuntu, using the docker.io and docker-compose-plugin packages. Then enable the service to start automatically after each reboot and check the versions with `docker --version` and `docker compose version`. Docker Engine 26+ and Compose 2+ are the minimum requirements for everything to work smoothly.

The recommendation is to run Bitwarden with a dedicated user without administrator privileges. Create the bitwarden user, add it to the docker group, and prepare the /opt/bitwarden directory with 700 permissions and the bitwarden owner. This 700 permission prevents other system users from reading or modifying the password database. A user without privileges greatly limits the potential damage if the application is compromised.

Download the bitwarden.sh script from the official URL and grant it execute permissions. Before running it, you can review its contents, and then execute `./bitwarden.sh install`. The installer will ask for the domain (without https://), whether you want to use Let's Encrypt and an email address for notifications, the database name, the installation identifier and key, and the US or EU region. Make a note of the two bitwarden.com/host values , as they are required to complete the deployment.

When finished, all configuration and data will be stored in /opt/bitwarden/bwdata. Start the services with ./bitwarden.sh start and check with docker ps that the containers are running. It's normal for them to take a minute or two to become healthy. You should see between five and seven containers, such as bitwarden-web, bitwarden-api, bitwarden-identity, bitwarden-attachments, bitwarden-icons, bitwarden-mssql, and bitwarden-nginx. Wait until they are healthy before considering the installation complete.

Email, administration panel, and public registry

The server settings are overwritten in bwdata/env/global.override.env. Open this file as the bitwarden user and populate the variables globalSettings__mail__smtp__host, port, ssl, startTls, username, password, and from. If you are using port 587 with STARTTLS, leave ssl=false; if your provider requires implicit TLS on port 465, set ssl=true. In adminSettings__admins, include the email addresses that will be allowed to access the admin panel, separated by commas. After editing the file, restart with ./bitwarden.sh restart.

Open your domain in your browser, create an account, and verify your email using the link you'll receive. The master password encrypts the vault on your device: the server doesn't know it and can't recover it if you forget it. Choose a long phrase and store it in a safe place. If the verification email arrives, your SMTP setup is working correctly. The master password is designed to be unrecoverable.

Once the required number of users have registered, or if you prefer to add users only via organizational invitations, disable public registration. Add `globalSettings__disableUserRegistration=true` to `global.override.env` and restart. Verify in a private window that the account creation option no longer allows registration. Leaving registration open on the internet is an invitation for anyone to use your instance.

The system panel is located at https://your_domain/admin. It doesn't use a traditional password: you enter one of the emails from adminSettings__admins and receive a one-time access link. From there, you can view and deactivate users, force account deletion, and view organizations. Organizations, collections, and permissions are managed from the web vault, under New Organization. Accessing the panel is convenient, but it should be handled with care.

Organizations, licenses and billing

To self-host a paid organization, you must first create it in Bitwarden's cloud vault and retrieve the license from your account. Then, you upload that license to your own server to create a self-hosted copy of the organization. Only Family and Business organizations can be imported to self-hosted servers. Billing originates in the cloud, even though the vault itself resides on your server.

Optionally, you can configure billing and license synchronization between your cloud and self-hosted organizations. This makes it easy to update licenses when the number of seats changes, streamlines renewals, and unlocks sponsored family organizations for members of enterprise organizations. Synchronization isn't required, but it saves a significant amount of administrative work.

Once the organization is created, first invite an administrative team with high-privilege members. For redundancy, it's advisable to include at least one other owner. Establish policies as soon as possible, such as requiring SSO or enrolling members in the administrator password reset process. If you're migrating from another secrets manager, import that data directly to avoid copying and pasting. Then invite the rest of the team; if you're using an identity provider or a directory like Azure Active Directory, you can leverage SCIM or Directory Connector to automatically synchronize users. Defining policies and a second owner from the start prevents unexpected issues.

Some paid features, such as certain organizations or premium features, require uploading a license file generated from your bitwarden.com account. Official clients are set up the same way as in the cloud, but before logging in, you must change the region or server to Self-Hosted and enter the exact URL, for example, https://your_domain. If the URL doesn't match precisely, the client won't connect.

Installation on Windows Server

On Windows Server 2025, access is via RDP, and you need Docker Desktop with Hyper-V, not WSL2. The official Bitwarden installer for Windows is a PowerShell script called bitwarden.ps1. Note: Docker Desktop does not have official support for Windows Server and may cause stability issues, so Linux remains the most reliable option. Additionally, Windows Server requires nested virtualization. Before installing, verify that your hypervisor supports this type of virtualization.

Open PowerShell as administrator and create firewall rules for ports 80 and 443. Then create a local user named Bitwarden, add it to the docker-users group, and prepare C:/Bitwarden. In Docker Desktop, go to Settings, Resources, File Sharing, and add C:/Bitwarden; apply and restart. Allocate at least 4 GB of RAM to Docker. Docker Desktop needs to be able to access the C:/Bitwarden folder to start the containers.

Download the script with Invoke-RestMethod and run bitwarden.ps1 -install. The prompts are equivalent to those in Linux: domain, Let's Encrypt or custom certificate, email, identifier, key, and region. Then edit C:/Bitwarden/bwdata/env/global.override.env with the SMTP settings and restart with bitwarden.ps1 -restart. Access the domain and create the master account. The installation details and SMTP settings are configured the same as in the Linux deployment.

Docker Desktop only starts automatically upon login if an RDP session is open. To prevent this, create a scheduled task that runs at startup, with a one-minute delay, using the Bitwarden account and the option to run regardless of whether the user is logged in. Without this task, Docker Desktop might remain shut down after a reboot . The bitwarden.ps1 script supports commands such as -start, -restart, -updateself, -update, and -renewcert.

Some scenarios, such as installing behind a proxy with alternative ports, require editing bwdata/config.yml and applying the changes after a reboot. The same applies to Linux. If you change ports or the proxy, check config.yml in addition to the environment variables.

Vaultwarden, the lightweight alternative

Vaultwarden is an unofficial reimplementation of the Bitwarden server written in Rust. It maintains the same protocol and works with the official apps, browser extension, and CLI without modification. The project is maintained by dani-garcia; it was formerly called bitwarden_rs and was renamed to avoid confusion with the brand. Its main appeal is that it unlocks premium features for free because it's a custom server, but it doesn't offer commercial support or a Service Level Agreement (SLA). It's an excellent option for personal use or small groups, but less so if you need contractual guarantees.

A typical Docker Compose deployment declares a vaultwarden service with the vaultwarden/server:latest image, container_name vaultwarden, restart always, the DOMAIN variable with your HTTPS URL, SIGNUPS_ALLOWED set to true, a ./vw-data:/data volume, and port 11001:80. The DOMAIN variable isn't just for show: it's essential for correctly generating attachment URLs and ensuring the client understands that HTTPS is being communicated through the reverse proxy. If you omit it or leave it as HTTP, some functions will fail in unintuitive ways. Vaultwarden requires genuine HTTPS on the client side because apps and browsers refuse to synchronize with an origin that doesn't have valid TLS.

The usual practice is to deploy the container behind a certified reverse proxy, such as Nginx, and use Certbot and Let's Encrypt if you don't already have one. Vaultwarden includes an /admin panel for managing users and organizations from the browser, protected by the ADMIN_TOKEN. In recent versions, it's recommended to generate an argon2id hash with `docker run --rm -it vaultwarden/server:latest /vaultwarden hash`. The command returns a PHC string starting with `$argon2id$`, and this string, not the original password, is what goes in the Compose file. Since Docker Compose interprets each `$` as an environment variable, you must duplicate each `$` in the string to `$$`. Never store the token in plain text or upload it to a Git repository, even a private one.

Setting `SIGNUPS_ALLOWED` to `true` is necessary the first time you create your own account from the client. Once you have it, change it to `false` and restart with `docker compose up -d`. Leaving registration open on a server exposed to the internet means that anyone who finds the URL can create an account and use your instance as their own manager. Closing registration after creating accounts is a basic security measure.

The entire Vaultwarden state resides on the /data volume: the SQLite database, attachments, and cached icons. A consistent backup can be as simple as copying that directory with the container stopped, or using sqlite3 for a hot dump without stopping the service: `docker exec vaultwarden sqlite3 /data/db.sqlite3 '.backup /data/db-backup.sqlite3'`. If you already have an incremental backup strategy using rsync and hard links, the same approach works by targeting vw-data. Since you store credentials here, for off-server backups, a remote encrypted rclone backup is more effective than an unencrypted rsync to another disk. Vaultwarden backups are straightforward, but they must be performed off-server.

Before updating the container, check the Vaultwarden changelog. Because Vaultwarden closely monitors protocol changes, some major updates may require migrating the database format. Do not update blindly if you haven't tested the new version first.

Backups, updates, and monitoring

The official Bitwarden performs an automatic nightly backup of the database in bwdata/mssql/backups. In addition to these backups, you should also back up attachments in bwdata/core/attachments, the configuration files in bwdata/env and bwdata/config.yml, and certificates. Live SQL Server files in bwdata/mssql/data should not be backed up while the service is running, so they are excluded. What you should save off-server is the database, attachments, configuration, and certificates.

You can create a script that compresses bwdata using `tar`, places it in a backups folder, and deletes backups older than 30 days using `find`. Scheduling this in cron for 2 AM is an easy way to remember. Then copy those files to another server or external storage using SFTP, FTPS, or an encrypted tool. A backup that only resides on the same server won't protect you from a hardware failure . On Windows, you can do something similar with `Compress-Archive` and a scheduled task, deleting the old ZIP files.

Updates to the official server are done with the same script, as the bitwarden user. First, update the script itself with `./bitwarden.sh updateself`, and then update the containers with `./bitwarden.sh update` and `./bitwarden.sh start`. On Windows, this would be `bitwarden.ps1 -updateself`, `bitwarden.ps1 -update`, and `bitwarden.ps1 -start`. The order matters: first the script, then the images.

Monitor the status of containers, free disk space, certificate expiration, and error logs. A full disk can corrupt the database, and an expired certificate prevents clients from synchronizing. Review the logs weekly and test restoring from a backup quarterly: stop Bitwarden, rename bwdata, restore the backup, start it up, and verify that everything works. Testing the restore is just as important as creating the backup.

Safety and common problems

Enable two-factor authentication on the administrator account as soon as possible. Restrict SSH on Linux or RDP on Windows to known IP addresses and consider using fail2ban to block brute-force attempts. Check Let's Encrypt renewals with `./bitwarden.sh renewcert` or `bitwarden.ps1 -renewcert`, disable public logging, and authorize only necessary emails in the admin panel. 2FA and good remote access restrictions prevent many problems.

If the installer doesn't obtain the certificate, check that the DNS is pointing to the server and that port 80 isn't being used by another service; `sudo ss -tlnp | grep ':80'` will help clarify this. If Docker returns `permission denied`, the `bitwarden` user isn't in the `docker` group or hasn't logged in again; log out and log back in with `sudo -iu bitwarden`. If emails aren't arriving, check the SMTP variables and logs with `docker logs bitwarden-api`. If clients aren't connecting, confirm that you've selected a self-hosted server and that the URL is exactly `https://your_domain`. Most issues can be resolved by checking DNS, ports, permissions, and logs.

High memory usage can be alleviated by restarting Bitwarden, but if the problem persists, you'll likely need to upgrade to a plan with 4 GB or more. If an update breaks your installation, restore the bwdata directory and revert to the previous version; before reinstalling, check the release notes for incompatible changes. Do not attempt an update without a backup.

• SSL certificate: Check the padlock icon in your browser and force renewal if it has expired.
• Containers: Check docker ps and the logs to see if any appear as Exited.
• E-mail: Test SMTP separately and review the rejections in the identity logs.
• Disk and memory: Monitor the space and use docker stats to detect containers that are running wild.
• Customers: Check the self-hosted server URL before logging in.
• Restoration: Perform a full bwdata recovery at least once per quarter.

Frequently asked questions and common doubts

Yes, Bitwarden can be hosted on macOS, but it requires a dedicated Mac, remote access, and is less efficient than Linux or Windows. The community offers fewer resources, and the setup is more complex, so it's not the best option for production environments.

Bitwarden's core features are free and include unlimited storage and cross-device synchronization. The personal premium plan costs around $19,80 per year and adds advanced 2FA options; the family plan is around $47,88 annually, and teams require an enterprise license. The free version is usually more than enough to get started.

Alternatives include the lighter Vaultwarden; 1Password, with a cloud interface; KeePassXC, offline; and Passbolt, geared towards teams. If self-hosting seems like too much, Bitwarden Cloud offers similar security without maintenance. The choice depends on how much control and management you want.

Bitwarden is very secure when properly configured. It uses 256-bit AES-CBC encryption and supports key derivation with PBKDF2 SHA-256 or Argon2id. The master password never leaves the device unencrypted. Hosting it yourself removes the cloud provider from your threat model. End-to-end encryption is the foundation of its design.

You can migrate from Bitwarden Cloud by exporting the vault from Settings > Export Vault and importing it into your instance from Settings > Import Data. Passwords, notes, and the organization structure are preserved. Exporting and importing is fast and eliminates the need for manual copying.

To add users, create an organization from the web vault and send them an email invitation. They will need to receive the email, so SMTP must be properly configured, and they will need to accept the invitation to join. Invitations without a configured email address will not be delivered.

If you forget the master password, there is no way to recover it. The vault remains encrypted and inaccessible by design. Store it in a secure, offline physical location, and don't rely solely on a digital file. The master password is the key that cannot be duplicated from the server.

For most deployments, Docker is sufficient and easier to manage. Kubernetes only makes sense for large enterprises that require high availability, load balancing, and automatic node failover. Don't set up Kubernetes if Docker already meets your needs.

Linux uses about a third of the RAM required by Windows Server, is updated with package managers, and has a larger self-hosting community. Windows is familiar to Active Directory administrators and offers management tools and commercial support from Microsoft. Linux is the efficient option; Windows, the familiar one.

It's clear that setting up your own Bitwarden or Vaultwarden vault requires proper preparation: a domain, TLS, SMTP, Docker, off-site backups, and a sensible access policy. The reward is an encrypted vault under your control, with official clients and the peace of mind of knowing exactly where your data is stored. HTTPS, SMTP, off-server backups, and 2FA are the four pillars you shouldn't neglect, and performing a quarterly restore will save you a lot of headaches.