Password Managers guide
Self-Host Bitwarden: The Production Checklist Most Guides Skip
Plan an official Bitwarden self-hosted deployment with capacity, TLS, mail, backups, upgrades, and a clear Vaultwarden comparison.
Published and reviewed by OpenAlt · September 22, 2026
Official Bitwarden Self-hosted is the full upstream server stack for teams that want the official deployment path, support model, and operational boundary. It is not the same product as Vaultwarden. Before running the official installer, plan the host, domain, TLS, mail, licensing, backups, verification, and rollback.
Table of Contents
- What are you deploying?
- Capacity and prerequisites
- Domain, TLS, and mail
- Installation flow
- Organization and licensing boundary
- Verification
- Backup
- Upgrade and rollback
- When Vaultwarden is the better fit
- Frequently Asked Questions
What are you deploying?
Official Bitwarden Self-hosted and Vaultwarden are separate projects. Vaultwarden is a compatible implementation, not the official Bitwarden server stack. That determines which documentation, configuration model, upgrade procedure, and support boundary apply. The official self-host repository uses Docker Compose and generated configuration; a smaller container footprint does not make another implementation official.
Start with the product requirement. If the team requires official Bitwarden Self-hosted, follow the official Linux deployment documentation and its upstream materials. If the goal is a compatible password-server implementation, evaluate Vaultwarden on OpenAlt separately.
Naming matters when support, procurement, internal controls, or compliance evidence must identify the software being operated. Do not describe Vaultwarden as Bitwarden Self-hosted, and do not combine procedures from both projects.
Capacity and prerequisites
Use the official system requirements as the baseline, then reserve headroom for users, organizations, attachments, backups, and maintenance.
Before installation, confirm:
- A supported Linux host meets the documented CPU, memory, storage, and operating-system requirements.
- Docker Compose is available as required by the official deployment.
- Persistent storage exists for the service, with a separate backup destination.
- DNS resolves the chosen hostname, and firewall rules are understood.
- Someone owns updates, backups, alerts, and recovery.
| Area | Decision | Consequence |
|---|---|---|
| Host | Where the stack runs | Maintenance access and failure domain |
| Storage | Where data and backups live | Recovery options and retention |
| Access | Who administers host and service | Incident ownership |
| Which provider or relay sends messages | Invitations, verification, recovery | |
| Support | Which official path applies | Service versus infrastructure obligations |
The smallest host that meets the published requirements is not automatically the best production choice. Leave room for maintenance and recovery artifacts, and keep backups independent of the primary host where practical.
Domain, TLS, and mail
Choose the final public hostname before configuring users or clients. Confirm DNS points to the intended service and that the TLS plan matches how traffic reaches the host. Changing the hostname later creates avoidable cleanup.
Mail is part of readiness. Invitations, verification, and account recovery can depend on delivery. Configure the mail settings required by the official deployment, then test delivery to representative addresses before onboarding the team.
Record the canonical hostname, TLS termination point, authorized mail provider or relay, recognizable sender identity, and owners for DNS, certificates, and mail credentials.
The Linux installation guide is the controlling reference for the supported sequence. A reachable container is not proof that the public service is ready; hostname, certificate, and mail behavior also matter.
Installation flow
Prepare the host and inputs first, then run the official installer and validate the generated deployment.
- Complete preflight. Confirm requirements, DNS, TLS, mail, storage, access ownership, and backup destination.
- Use the official path. Follow the Linux guide and official self-host repository, not a Vaultwarden guide or unrelated container tutorial.
- Provide configuration. The official repository uses Docker Compose and generated configuration. Preserve the generated files and record their location.
- Start the deployment. Use the documented installer procedure for the selected release and environment. Do not invent flags, service names, or substitutions.
- Complete administration. Open the service at the intended hostname and configure the required organization and administrator access.
- Test onboarding. Send a controlled invitation or verification message and confirm the recipient can complete the flow.
- Document the result. Record the hostname, host owner, configuration and backup locations, and recovery owner.
The Bitwarden self-host repository is the authoritative source for the Compose-based deployment structure and generated configuration. Use its documented workflow and treat the resulting configuration as an operational asset.
Organization and licensing boundary
Self-hosting changes where the service runs; it does not automatically resolve licensing, organization features, support, or labor costs. Identify the users, organizations, and administrative controls required, then confirm the applicable official plan and terms before production use.
Assign responsibility for the host, application, backups, and incidents. Record what Bitwarden covers and what remains the operator’s responsibility. This belongs in the deployment plan, especially when official support or compliance evidence matters.
Verification
Verification should prove that administrators and ordinary users can use the service, not merely that containers started.
After installation:
- Open the final HTTPS hostname and confirm its certificate.
- Check the administrative interface for hostname or mixed-content confusion.
- Test a controlled account’s login and logout.
- Test an invitation or verification email.
- Confirm organization permissions and client reachability.
- Confirm the operator can locate generated configuration and backup instructions.
- Record the date, tester, hostname, and result.
Treat a mail failure, certificate warning, or incorrect hostname as a release blocker. Keep the record with the deployment documentation so future operators know what “working” meant.
Backup
Use the official on-premise backup guidance to define required data, configuration, schedule, storage, retention, and restoration. Do not assume one visible directory is a complete backup.
A dependable plan states what is backed up, where copies are stored, how long they are retained, who can access them, how success is confirmed, who performs recovery, and when restoration was last rehearsed. Keep at least one recovery copy independent of the primary host and protect backup access as carefully as the service itself.
Upgrade and rollback
Upgrade only when the current version is known, the documented backup is complete, and the team can recover to a known-good state.
Before an upgrade:
- Confirm the deployment is healthy.
- Capture the backup required by official guidance.
- Preserve generated configuration and deployment records.
- Choose a maintenance window and assign an operator and validator.
- Define success checks for HTTPS, login, mail, organizations, and client reachability.
Repeat those checks afterward. If the result is unacceptable, stop onboarding and use the documented recovery path. Rollback means restoring a known-good backup or returning to a documented previous state, not deleting data and guessing at configuration. Keep upgrades consistent with the official self-host repository.
When Vaultwarden is the better fit
Vaultwarden is the better fit when you intentionally want a separate compatible implementation and accept its distinct operational boundary. Choose it only when that project matches the team’s constraints, support expectations, and compatibility requirements.
Choose official Bitwarden Self-hosted when the upstream stack, official deployment path, and support or compliance boundary are priorities. Choose Vaultwarden when its separate implementation matches the requirements. Keep installation, backup, upgrade, and troubleshooting procedures specific to the selected project.
Start with Bitwarden Server on OpenAlt for official Bitwarden Self-hosted, Vaultwarden for the separate compatible implementation, or the password-manager directory for the wider category. Select the right project, meet requirements, configure hostname/TLS/mail, preserve generated configuration, verify real user flows, and assign backup and rollback ownership.
Frequently Asked Questions
Is self-hosted Bitwarden free?
Not necessarily. Self-hosting moves operation to your infrastructure but does not automatically settle licensing, organization features, support, or labor costs. Confirm the applicable Bitwarden terms before production use.
Is Vaultwarden the same as official Bitwarden Self-hosted?
No. Vaultwarden is a separate compatible implementation, while official Bitwarden Self-hosted is the full upstream server stack. Evaluate and document them as different projects.
Does the official deployment require Docker Compose?
The official self-host repository uses Docker Compose and generated configuration. Follow the official installer and deployment documentation instead of substituting commands from another project.
What should be backed up?
Use Bitwarden’s official on-premise backup guidance to determine the required data, configuration, storage, retention, and restoration process. Do not assume a single directory copy is complete.
What should be verified after installation?
Verify the final HTTPS hostname and certificate, administrator and user login, invitation or verification mail, organization permissions, client reachability, and access to generated configuration and backup instructions. Record the results before onboarding the team.