Bitwarden is now listed in the AWS Marketplace and Azure Marketplace, which means a working Bitwarden self-host server is about fifteen minutes away from a single marketplace listing click. The deployment is real, the install is scripted, and the cost is whatever AWS or Azure charges you for the underlying VM (virtual machine, a rented slice of a physical server in someone else’s data center). The sovereignty story is also more complicated than the marketing page suggests, and the complications are worth understanding before you commit a team to the setup.
What the marketplace listing actually gives you
Both the AWS AMI (Amazon Machine Image, a pre-built server template that runs on EC2) and the Azure VM image come pre-loaded with Ubuntu LTS, Docker, Docker Compose, and the Bitwarden installation script. The price for the listing itself is zero. You still pay the cloud vendor for compute, storage, and bandwidth at their normal rates.
The setup wizard walks you through the standard inputs you would expect: pick a resource group or security group, name the VM, create a username and SSH key. After the VM is up, you SSH in, the Bitwarden setup wizard takes over, and you configure the rest through a console. The whole process from marketplace click to working Bitwarden instance is the same half-hour that the Bitwarden documentation suggests for a manual Linux install, minus the manual install part.
Once the instance is running, you set your domain, point DNS at the public IP, retrieve your installation ID and key from bitwarden.com/host, configure SSL (Secure Sockets Layer, the encryption protocol that makes HTTPS work) via Let’s Encrypt (a free, automated certificate authority) or an existing certificate, and finish the environment configuration for SMTP (Simple Mail Transfer Protocol, the standard way email gets sent) and other settings. Bitwarden services start when setup completes.
The setup is the same as a manual Bitwarden self-host install. The marketplace listing just packages the prerequisites.
The case for putting Bitwarden in a hyperscaler
If your organisation already operates in AWS or Azure, deploying Bitwarden from the marketplace keeps the password manager inside the same environment as the rest of the stack. That is the headline argument, and it has real weight.
Access controls stay unified. You can use AWS IAM (Identity and Access Management) or Azure Entra ID (the renamed Azure Active Directory, a role-based access system) to gate who can reach the Bitwarden admin console. Network policies, security groups, and audit logging all live in the same place as the rest of your infrastructure. For a security team already drowning in dashboards, fewer consoles is genuinely better than more.
Billing consolidates. The VM cost shows up on the same invoice as the rest of your cloud spend, with the same cost-allocation tags, the same internal chargeback, and the same finance approval flow. Standing up a separate DigitalOcean droplet or Hetzner server introduces a new vendor, a new invoice, and a new line item to justify annually.
Network latency to other cloud-hosted services is lower. If your application servers are in eu-west-1, putting Bitwarden in eu-west-1 means the auth API calls do not leave the AWS network backbone. That is faster and more predictable than round-tripping to a Hetzner box in Germany or a DigitalOcean droplet in New York.
For most teams operating in AWS or Azure already, the marketplace listing is the path of least resistance. The setup is faster than the manual install, the operational surface is smaller, and the integration story is cleaner.
The sovereignty questions worth asking
The same convenience that makes the marketplace listing appealing also creates the sovereignty questions. Self-hosting a password manager is usually framed as a privacy win. You control the data, the keys, the backups. Running that self-hosted instance on AWS or Azure changes the threat model in ways that are not always obvious.
Data residency is the first question. AWS and Azure offer regional control. If you provision in eu-central-1 or westeurope, the data should stay in that region. Verify the regional commitment in the vendor’s current terms of service, because it is the kind of detail that quietly shifts. Regional commitments are contractual, not architectural, and they have changed in the past.
Subpoena exposure is the second question. A self-hosted Bitwarden on a Hetzner box in Germany is subject to German law and a German court order. A self-hosted Bitwarden on AWS in Frankfurt is subject to German law for the data, and to US law for the AWS account that holds the encryption keys. The CLOUD Act (a 2018 US law that lets US authorities compel US providers to hand over data stored on foreign servers) is the relevant US statute. This is not a hypothetical. US law enforcement has used the CLOUD Act to compel US providers for data in EU data centres. Whether this matters for your threat model is a question only your security team can answer.
Operational dependency is the third question. If AWS has a regional outage, your password manager is down with the rest of the stack. If your AWS bill goes unpaid, the instance terminates and the disk volume is deleted. The “self-hosted” part means you control the application and the data, but it does not mean you control the substrate.
Trust boundary is the fourth question. Bitwarden staff do not have access to your vault, and the Bitwarden source code is open for review. That does not change when Bitwarden runs on AWS. The trust boundary is between your vault and Bitwarden the company, not between your vault and the cloud vendor. AWS staff with administrative access to the underlying host could in principle read the unencrypted disk image, but they would need to bypass both the AWS access controls and the Bitwarden application-level encryption. That is a much higher bar than just reading a database.
What the right threat model looks like for the marketplace
A team with regulated healthcare data has a different answer than a team running standard SaaS dashboards. The questions below cover the common cases. Pick the row that matches your situation, and the rest of the decision follows.
- You are sensitive to CLOUD Act exposure. A hyperscaler is the wrong fit. A Hetzner dedicated server in Germany, a Scaleway dedicated server in France, or an on-premise server in your own data centre is the cleanest match. The Bitwarden install is the same on all three, and the self-host documentation is comprehensive.
- You want your passwords off someone else’s computer and the answer to “someone else” was “the Bitwarden company”. A marketplace listing on AWS or Azure is a fine answer. The threat was the vendor holding the keys, not the cloud vendor holding the disk. You are still holding the keys.
- You are somewhere in between. A careful read of the AWS or Azure data processing addendum, a clear understanding of which jurisdiction you are operating in, and a documented decision on which threats you are actually defending against is the cleanest next step. The marketplace listing does not force the answer, but it also does not absolve you of having to make the decision.
- You are running a small team and the Bitwarden is the only piece of regulated data in your stack. The marketplace listing is the cleanest path. The sovereignty questions are real, but for a four-person team, the answers to those questions are usually “we will worry about it when we have to.” For a fifty-person team, the answer is more often “we have a dedicated host already and we are not moving.” Match the deployment to the team size.
Trade-offs
A marketplace-deployed Bitwarden instance is the fastest path to a self-hosted password manager, and for most teams it is the right one. The setup is well-documented, the operational surface is small, and the integration with the rest of an AWS or Azure deployment is clean.
The cost is sovereignty. A self-hosted password manager on a hyperscaler is still self-hosted, but it is self-hosted on infrastructure that is subject to a legal regime you do not control. For most teams, that trade is fine. For teams with regulated data, government customers, or a threat model that includes state-level adversaries, the sovereignty question is the one that matters, and the marketplace listing does not solve it.
In our case, a small team running standard SaaS applications on AWS would do well with the marketplace listing, and the sovereignty questions are not load-bearing. A team with HIPAA-regulated healthcare data or FINRA-regulated financial data has a different conversation, and the sensible default is probably a non-hyperscaler host.
The migration from a manual install to the marketplace is a non-event. The migration from the marketplace to a non-hyperscaler host is a few hours of work, and the Bitwarden export and import tools handle the data side. Both directions are easy, which is part of why the marketplace listing is a reasonable starting point.
Bottom line
If you are already operating in AWS or Azure and you have been putting off the Bitwarden self-host install because the manual setup felt like a weekend you did not have, the marketplace listing is the answer. Click, name, deploy, configure, done. The sovereignty questions are real but they are not blocking for most teams.
Bottom line: the marketplace listing is a packaging improvement, not a major shift in what self-hosting means. The same Bitwarden self-host you would have installed on a Linux box is now installable on a hyperscaler in a few minutes. Use it if the hyperscaler is already your home, and look elsewhere if it is not.