著者 VaultwardenとBitwarden self-hostedの違いと選び方
Bitwarden standardは約12個のコンテナと2 GBのRAMを必要とします。1コンテナとSQLiteで動くVaultwardenとの違いを、機能、保守、バックアップから比較します。
Vaultwarden と Bitwarden self-hosted の実態
Vaultwarden と Bitwarden self-hosted の違いは、2 つのパスワードマネージャーから選ぶことではありません。同じクライアント API に対応する 2 つのサーバーから選ぶことです。Bitwarden の公式スタックは、nginx の背後で約 12 個のコンテナを動かし、すべてのデータを Microsoft SQL Server に保存します。また、メールアドレスで登録する installation ID にひも付けられます。Vaultwarden は、Bitwarden のクライアント API を非公式に再実装したもので、Rust で記述されています。1 つのコンテナで、1 つの SQLite ファイルを使用して動作します。ブラウザー拡張機能とスマートフォンは、両者を区別できません。どちらも同じエンドポイントに応答するためです。
どちらを選んでも、暗号化の仕組みは同じです。Bitwarden クライアントは、デバイスからデータを送信する前に vault を暗号化します。そのため、サーバーには読み取れない blob が保存されます。どちらの場合も、vault の形式は Bitwarden のものです。違うのは、必要なマシンの規模、コードを保守する主体、有料になる機能、バックアップが必要な対象です。
Vaultwarden の README には、その位置付けが明記されています。「このプロジェクトは Bitwarden または Bitwarden, Inc. とは関係ありません」。これはボランティアによるプロジェクトで、サポート窓口も保証もありません。現役の maintainer の 1 人は Bitwarden に勤務し、個人の時間を使って貢献しています。ただし、これは好意によるものであり、Bitwarden による推奨を意味しません。
インストールできる3つのスタック
多くの比較では、Bitwarden に異なる2つのセルフホスト製品がある点が見落とされています。
Bitwarden standard。 shell script で動作する、ベンダー提供のデプロイ方式です。
curl -Lso bitwarden.sh "https://func.bitwarden.com/api/dl/?app=self-host&platform=linux" \
&& chmod 700 bitwarden.sh
./bitwarden.sh installインストーラーでは、ドメイン、Let's Encrypt 証明書を要求するかどうか、メールアドレスを入力して https://bitwarden.com/host から取得する installation ID と key、地域（US または EU）を指定します。./bitwarden.sh start がイメージを取得し、スタックを起動します。Bitwarden は最小要件として RAM 2 GB とストレージ 12 GB、推奨要件として RAM 4 GB とストレージ 25 GB、さらに Compose plugin を備えた Docker Engine 26 以降を記載しています。データベースには MSSQL Express image を使用します。Bitwarden の資料では、リレーショナルデータベースの最大サイズは 10 GB とされています。これでは小さすぎる場合は、外部データベースを使うようにデプロイ先を指定できます。
Bitwarden lite。 以前は Bitwarden Unified と呼ばれていたデプロイ方式です。2025年12月に beta を終了し、名称が変更されました。アプリケーションコンテナ1つと、任意のデータベースを組み合わせます。
services:
bitwarden:
depends_on:
- db
env_file:
- settings.env
image: ghcr.io/bitwarden/lite
restart: always
ports:
- "80:8080"
volumes:
- bitwarden:/etc/bitwarden
db:
environment:
MARIADB_USER: "bitwarden"
MARIADB_PASSWORD: "super_strong_password"
MARIADB_DATABASE: "bitwarden_vault"
MARIADB_RANDOM_ROOT_PASSWORD: "true"
image: mariadb:10
restart: always
volumes:
- data:/var/lib/mysql
volumes:
bitwarden:
data:MariaDB または MySQL、PostgreSQL、SQLite、MSSQL を使用でき、必要な RAM は 200 MB、ストレージは 1 GB です。Bitwarden の公式ドキュメントには、2つの注意点があります。対象は business use ではなく personal use と home labs であり、データベースの自動バックアップ機能もありません。そのため、バックアップはすべて自分で行う必要があります。
Vaultwarden。 プロジェクトの README からそのまま使える、1つのコンテナによる構成です。
docker run --detach --name vaultwarden \
--env DOMAIN="https://vw.domain.tld" \
--volume /vw-data/:/data/ \
--restart unless-stopped \
--publish 127.0.0.1:8000:80 \
vaultwarden/server:latestpublish 行では port 8000 を loopback のみに bind しています。これは意図した設定です。Vaultwarden は plain HTTP を提供し、前段の reverse proxy に TLS (transport layer security) の終端を任せます。ここで TLS は必須です。web vault はブラウザーの WebCrypto API を使って暗号化しますが、ブラウザーがこの API を公開するのは secure context の場合だけです。そのため plain http では、サーバーに処理が届く前にブラウザー上の login page が失敗します。Vaultwarden の完全なインストール手順では、proxy と証明書について説明しています。
Bitwarden self-hosted と併用した場合、Vaultwarden はどの程度の RAM を使用しますか？
ベンダーが示す最小要件は、インストーラーが実行を拒否しないための条件であり、ソフトウェアの実際の使用量ではありません。以下の値は、RAM 4 GB の Ubuntu 24.04 上で、各ソフトウェアをアイドル状態で実行した場合の docker stats --no-stream に基づいています。ユーザーは各 1 人、Vault は小規模、添付ファイルはありません。ディスク使用量は、初回起動に成功した後のイメージとデータディレクトリの合計です。
このグラフのデータ
[
{
"label": "Vaultwarden (SQLite)",
"idle_ram_mb": 58,
"containers": 1,
"disk_gb": 0.4
},
{
"label": "Bitwarden lite + MariaDB",
"idle_ram_mb": 470,
"containers": 2,
"disk_gb": 1.6
},
{
"label": "Bitwarden standard (MSSQL)",
"idle_ram_mb": "2,400",
"containers": 12,
"disk_gb": 6.5
}
]Vaultwarden は単一のコンテナでアイドル状態にすると 58 MB でした。標準の Bitwarden stack は 2,400 MB 前後を 12 個のコンテナで使用し、その大部分を MSSQL コンテナが占めました。Bitwarden lite は MariaDB コンテナと合わせて 470 MB でした。これらの値をそのまま信用する前に、自分のサーバーで同じコマンドを実行してください。使用量はユーザー数、添付ファイル、同期トラフィックによって変わります。また、MSSQL は稼働時間が長くなるほどワーキングセットが増加します。
小規模な VPS で考える場合、SQLite を使用する Vaultwarden は 1 GB プランで問題なく動作しますが、標準の Bitwarden stack はその容量では起動しません。2 GB プランでは標準 stack の文書化された最小要件を満たしますが、オペレーティングシステムに残るメモリは非常に少なくなります。そのため、kernel の out of memory killer が実際に動作する可能性があります。発動すると、dmesg が強制終了したプロセス名を含む行を出力します。この stack では通常、対象は sqlservr です。標準 deployment には 4 GB を割り当ててください。同じ VPS に Vault 以外のサービスも配置する場合は、プランを選ぶ前に各サービスに必要な最低容量を確認してください。PhotoPrism や Immich などの写真サーバーは、Vaultwarden よりはるかに多くのメモリを必要とします。ただし、すべてのサービスが同じようにメモリを消費するわけではありません。Jellyfin のライブラリを 90 年代のレンタルショップ風に表示する Halcyonのようなサービスは、独自のデータベースを持つのではなく、接続先のメディアサーバーに依存するブラウザフロントエンドです。確認すべき最低要件はメモリだけでもありません。リモートデスクトップセッション用の RustDesk relayは docker stats ではほとんどメモリを使用せず、その代わりにプランの帯域幅を消費します。
Vaultwarden ではどの有料機能を無料で使えますか？
Bitwarden のサーバーは無料で運用できますが、ライセンスファイルをアップロードするまで有料機能はロックされています。セルフホストできる有料プランである Premium 個人アカウントと Families、Enterprise の有料組織プランには、ライセンスファイルが必要です。Bitwarden では Teams にセルフホストの選択肢はありません。個人の場合はクラウドの Web ボルトで Settings、次に Subscription を開き、組織の場合は Admin Console で Billing、次に Subscription を開いてライセンスをダウンロードし、自分のインスタンスへアップロードします。組織のライセンスは、./bwdata/env/global.override.env に保存されたインストール ID に対して発行されます。そのため、セルフホストの組織でも有料サブスクリプションを保持し、請求処理のために Bitwarden のクラウドへ接続します。
Vaultwarden では、ライセンスもサブスクリプションも必要なく、同じ機能を有効にできます。プロジェクト Wiki には次の機能が記載されています。
- 組織、コレクション、グループ
- ファイル添付
- email、Duo、YubiKey、FIDO2 による 2 段階ログイン
- Emergency Access
- Bitwarden Send
- 個人 API キー
- OpenID Connect による SSO
SSO はこれらの中で最も新しい機能で、SSO_ENABLED、SSO_AUTHORITY、SSO_CLIENT_ID、SSO_CLIENT_SECRET を使用して設定します。これはログインだけを認証します。Wiki には、マスターパスワードが引き続き必要であり、ID プロバイダーでは管理されないことが明記されています。マスターパスワードから、ボルトを復号する鍵が生成されるためです。SSO_AUTHORITY に セルフホストした Authentik ID プロバイダーの discovery issuer を指定すると、ユーザーはそこでサインインし、その後マスターパスワードでロックを解除します。この値は、discovery エンドポイントが返す issuer フィールドと一致している必要があります。末尾の /.well-known/openid-configuration サフィックスは付けません。
Vaultwarden で利用できないのは、ベンダーによる支援です。Bitwarden は SOC 2 Type 2 と ISO 27001 を取得し、第三者による監査報告書を公開しています。また、非公開の HackerOne バグバウンティプログラムも運営しています。これらは Bitwarden のコードとサービスを対象とするもので、インストールしたサーバーを対象とするものではありません。それでも、監査人がパスワードマネージャーの提供元として明確なベンダーを求める場合、ボランティアによる再実装を採用していることの説明は難しくなります。
公式の Bitwarden アプリは Vaultwarden と連携できますか？
はい。Vaultwarden はクライアント API を実装しているため、ブラウザー拡張機能、デスクトップアプリ、モバイルアプリ、付属の Web vault はすべて Vaultwarden に接続して利用できます。各クライアントでは、ログインする前に環境設定画面でセルフホストサーバーの URL を設定します。ログイン後に設定するのではありません。
追加設定が必要な機能が 1 つあります。モバイルアプリへのプッシュ通知です。プッシュ通知がない場合、アプリは開いたとき、または独自のタイマーに従って同期します。そのため、ノートパソコンで変更したパスワードは、スマートフォンで確認するまで反映されません。Vaultwarden は Bitwarden のプッシュリレーを利用できます。そのため、公式インストーラーが使用するものと同じ https://bitwarden.com/host ページから、インストール ID とキーを取得する必要があります。
PUSH_ENABLED=true
PUSH_INSTALLATION_ID=<your installation id>
PUSH_INSTALLATION_KEY=<your installation key>EU リージョンのサーバーでは PUSH_RELAY_URI=https://api.bitwarden.eu と PUSH_IDENTITY_URI=https://identity.bitwarden.eu も必要です。この問題を 1 時間かけて調査する前に、wiki に記載された注意点を 2 つ確認してください。F-Droid または Neo Store からインストールしたアプリは Firebase をサポートしていないため、サーバー側の設定に関係なくプッシュ通知を受信できません。Vaultwarden 1.30.2 より前に接続したアプリでは、プッシュトークンを登録し直すためにアプリのデータを消去する必要があります。
再実装はどの程度安全ですか？
Bitwarden の監査履歴は長く、公開されています。Cure53 は 2018、2021、2022、2023、2024、2025 年にレビューを実施しました。2025 年のレビューでは、ブラウザー拡張機能と autofill overlay、core application、desktop application、web vault、RustCrypto crate および library が対象になりました。IOActive と Mandiant は 2024 年にクライアントをレビューし、Fracture Labs は 2024 年と 2025 年に Web およびネットワークの評価を実施しました。Unit 42 は 2025 年にモバイルアプリを評価し、ETH Zurich Applied Cryptography Group は 2025 年に暗号技術をレビューしました。
Vaultwarden も外部の専門家による調査を受けています。誰も調査していないと思っている人には意外かもしれません。ドイツ連邦情報セキュリティ庁 (BSI) は、Caos 3.0 code analysis project の一環として、mgm security partners に 2024 年 2 月から 5 月まで調査を実施させました。このレビューでは、2 件の指摘が high と評価されました。別途、ERNW は 1.32.5 未満のバージョンに影響する authentication bypass (CVE-2024-55225) を報告しました。この問題は 2024 年 11 月に修正されました。2026 年 7 月の Version 1.37.0 では、icon endpoint を介した SSRF (server side request forgery)、組織をまたぐ cipher access、directory imports における organization policy bypass の修正が提供されました。2026 年 10 月の Version 1.37.4 では、さらに複数の問題が修正されました。中心となったのは、organization member revocation に関する high rated flaw です。two factor authentication、organization invitations、attachments に関する問題も含まれていました。
この履歴から、脆弱性の報告と修正が機能しているプロジェクトであることが分かります。同時に、繰り返し問題の対象となっている領域も分かります。それは admin page です。そのため、admin page を機密性の高い対象として扱ってください。ADMIN_TOKEN が設定されていない限り、このページは無効になっています。平文の token ではなく、hash を保存してください。
docker run --rm -it vaultwarden/server /vaultwarden hashこのコマンドは Argon2 PHC string (password hashing competition format) を出力します。これを ADMIN_TOKEN に貼り付けます。admin page を有効にする前に HTTPS を有効にしてください。token はリクエストに含めて送信されるため、平文の HTTP 接続では経路上のあらゆる対象から読み取られる可能性があります。実際のリスクは暗号技術よりも、この token と backup file にあります。稼働中のインスタンスを強化する手順では、その両方を確認します。可能であれば /admin を public internet から隔離し、サーバー上の SSH access を制限する手順など、通常の host hardening も組み合わせてください。
公式 API の変更で発生する問題
これは過小評価されがちなリスクです。Bitwarden は client を提供しており、client は app store から夜間に自動更新されます。Vaultwarden はその変更に追従する必要があります。client の release で API contract が変更されると、更新していない Vaultwarden はすでに変更後の client と接続することになります。その結果、操作していないデバイスで login や sync が失敗し始めます。
release notes には具体例があります。Vaultwarden 1.37.0 には、「2026.7.0 以降の version の client をサポートするには、この update が必要です。問題を報告する前に update してください」と記載されています。その1か月後、2026年8月22日に公開された 1.37.2 でも、2026.8.0 以降の client について同じ警告が繰り返されました。つまり、1.37.0 または 1.37.1 のままのサーバーは、すでに app より遅れています。2026年10月27日時点の current release は 1.37.4 です。これは、2026年9月13日の 1.37.3 に続いて、2026年10月5日に公開されました。
この問題を単純に保つには、2つの習慣が役立ちます。まず、latest の代わりに特定の image tag を固定します。これにより、無人の pull によって午前3時にサーバーが勝手に更新されることを防げます。次に、release feed を監視し、notes を先に読んだうえで、意図的に upgrade します。breaking changes はそこに告知されるためです。1.37.2 の警告はプロジェクトの GitHub Discussions にも掲載されました。そこには、server upgrade 後も正常に動作しない client の復旧手順も示されています。まず log out してから再度 log in し、次に app または extension の cache を clear します。mobile app または extension の reinstall は最後の手段にしてください。たとえば version 1.35.5 では、upgrade 時に既存の two factor remember token がすべて無効化されました。その結果、保存したつもりだった手順から user が log out されました。
標準の Bitwarden deployment では、これと逆の問題が発生します。upgrade は ./bitwarden.sh updateself と ./bitwarden.sh update を通じて実行され、update によって database migration が適用されます。migration 前に取得した backup は、migration 後の schema に対する rollback にはなりません。そのため、backup を取得し、取得時点の version を記録してください。
バックアップで実際に vault を失うケース
Vaultwarden では、データディレクトリがサーバーそのものです。次を保持してください。
db.sqlite3rsa_key*ファイル一式（rsa_key.pemとrsa_key.derを含む）attachments/config.jsonsends/
コンテナの稼働中に cp で db.sqlite3 をコピーしないでください。SQLite は書き込み途中の場合があるため、コピー先が正常に見えても、復元時にデータベースが破損していることがあります。代わりに、オンラインバックアップ API を使用してください。
sqlite3 data/db.sqlite3 ".backup '/path/to/backups/db-$(date '+%Y%m%d-%H%M').sqlite3'"1.32.1 以降は、イメージに組み込まれた /vaultwarden backup コマンドも使用できます。どちらの方法でも、スナップショットを移動するまでは元データと同じディスク上に残ります。そのため、オフサイトストレージへの restic スナップショットをスケジュール実行し、別のホストへ送信してください。バックアップジョブが気付かないうちに停止すると、最初から存在しなかった場合と区別できません。タイマー自身の失敗を、確実に確認できる場所へ通知させてください。そのために、systemd の OnFailure unit と連携したセルフホスト ntfy サーバーを使用します。rsa_key ファイルもデータベースと同じ程度に重要です。サーバーはこの鍵でセッショントークンに署名します。そのため、新しく生成した鍵と一緒にデータベースを復元すると、全員がログアウトされ、処理中だった組織への招待も機能しなくなります。
Bitwarden standard は、さらに多くのデータをバックアップします。mssql コンテナは、コンテナが稼働している限り、毎晩データベースのバックアップを ./bwdata/mssql/backups に保存し、30 日分を保持します。次のコマンドで手動実行もできます。
docker exec -i bitwarden-mssql /backup-db.sh保持するディレクトリは ./bwdata/env（データベースと証明書のパスワードを含む環境変数）、./bwdata/core/attachments、./bwdata/mssql/data、./bwdata/core/aspnet-dataprotection です。最後のディレクトリは忘れられがちです。ここには、認証トークンや一部のデータベース列を含む、フレームワークレベルのデータ保護情報が格納されています。これを含めずにデータベースを復元すると、保護対象の列を読み取れなくなります。Bitwarden lite は自動バックアップを一切作成しません。そのため lite を選択する場合は、Vaultwarden と同じようにダンプのスケジュールを自分で管理する必要があります。
どちらの方向でも移行する
移行はサーバーではなくクライアントを介して行います。エクスポートとインポートはクライアントの機能だからです。そのため、どちらの方向でも手順は同じです。
各ユーザーが web vault または desktop app からエクスポートし、新しいサーバーでアカウントを作成してからインポートします。形式にはプレーンテキストの .json、プレーンテキストの .csv、暗号化された .json、個別の vault の JSON とファイル添付を格納する .zip があります。カード、ID、保存された passkey、SSH key は JSON 形式でのみ引き継がれるため、CSV による移行ではこれらが警告なく失われます。どのエクスポート形式にも trash の項目や Sends は含まれません。また、組織が所有するデータは個人のエクスポートには含まれません。
プレーンテキストのエクスポートは、実際にそうであるため、使用中の Secret と同じように扱ってください。ディスク上に vault 全体が平文で保存されるからです。エクスポート、インポート、削除を同じ作業中に行います。メールや chat で送信してはいけません。
移行中に問題になりやすい点があります。アカウントに紐付いた暗号化エクスポートは、別のアカウントにはインポートできません。サーバーを移行すると、必ず別のアカウントになります。代わりに、パスワードで保護されたエクスポートを選択してください。こちらは移植できます。
Vaultwarden から Bitwarden standard への移行は、より難しい方向です。組織の構成はエクスポートに含まれないためです。新しいサーバーで組織を再作成し、ユーザーを再度招待して、各ユーザーが自分の vault をインポートします。この点に移行当日になって気付かないよう、あらかじめメンテナンス時間を確保してください。
どれを実行すべきか
1 GB または 2 GB の VPS で個人、家族、ホームラボ向けに運用するなら、Vaultwarden を実行します。Organisations、Emergency Access、Send が無料で使え、アイドル時のメモリ使用量はおおむねブラウザーのタブ 1 つ分です。バックアップも SQLite ファイルと小さなディレクトリだけで済みます。この組み合わせが、セルフホスト型パスワード管理で Vaultwarden が広く使われている理由です。
他の利用者が業務で依存する場合は、Bitwarden 独自のサーバーを実行します。たとえば、サポート契約が必要な企業、ベンダー名が明記されたコンプライアンス要件がある場合、またはすでに料金を支払っているエンタープライズ機能を利用する場合です。標準構成には 4 GB を割り当て、ライセンスファイルとインストール ID を書類ではなく、デプロイメントの一部として扱います。
Bitwarden lite は中途半端な位置付けです。ベンダー提供のコードを、より小さな規模で利用できる点は非常に魅力的です。しかし、Bitwarden は個人利用とホームラボ向けとして説明しており、自動バックアップもありません。Vaultwarden の無料機能セットなしで、Vaultwarden と同じ運用上の負担を抱えることになります。機能よりもベンダー提供のコードを重視し、データベースを自分で運用できる場合に選びます。
このサーバーで他に何をホストするかまだ決めていない場合は、セルフホスト候補の全体一覧で、同じ RAM を取り合う他のサービスとこの選択肢を比較できます。
FAQ
Vaultwarden は実用的なパスワードマネージャーとして十分安全ですか？
個人や家族で使う場合は、条件付きで安全です。クライアントは vault をサーバーへ送る前に暗号化するため、Vaultwarden が master password や平文データを参照することはありません。外部レビューも実施されています。BSI は mgm security のパートナーに 2024 年 2 月から 5 月までテストを依頼し、ERNW は認証バイパスを報告しました。この問題は 1.32.5 で修正されています。バージョンを最新に保ち、admin page を無効にするか Argon2 でハッシュ化した ADMIN_TOKEN の背後に置き、HTTPS 経由でのみ提供してください。ベンダーサポートや監査資料が必要な企業は、Bitwarden 純正のサーバーを運用してください。
Vaultwarden に必要な RAM は、Bitwarden self-hosted と比べてどの程度ですか？
docker stats --no-stream を使用してアイドル状態のインストール環境を測定したところ、SQLite を使用する Vaultwarden は 1 つのコンテナで約 58 MB でした。一方、Bitwarden の標準構成は 12 個のコンテナ全体で約 2,400 MB でした。その大部分は MSSQL データベースが占めます。Bitwarden は標準スタックの最小要件として 2 GB、推奨値として 4 GB、Bitwarden lite では 200 MB を案内しています。Vaultwarden は 1 GB の VPS でも十分な余裕を持って動作します。
self-hosted で運用する場合、Bitwarden の licence は必要ですか？
無料の個人用 vault には必要ありません。サーバーの運用も無料です。premium の個人機能と有料の organisation plan を有効にするには licence file が必要です。また、Bitwarden が self-hosted を許可している organisation plan は Families と Enterprise だけです。licence file は cloud web vault からダウンロードしてインスタンスへアップロードします。organisation licence は ./bwdata/env/global.override.env に保存された installation ID に対して発行されます。Vaultwarden に licence は不要で、organisation 機能も自動的に有効になります。
後から Vaultwarden から Bitwarden へ、またはその逆へ移行できますか？
はい。どちらの方向にも、クライアントを使用して移行できます。各ユーザーが web vault または desktop app から自分の vault をエクスポートし、新しいサーバーでアカウントを作成してからインポートします。.zip 形式のエクスポートには個人用 vault の添付ファイルが含まれます。JSON 形式には cards、identities、passkeys、SSH keys が含まれます。Trash items と Sends はどのエクスポート形式にも含まれません。また、organisation 所有のアイテムは owner が個別にエクスポートする必要があります。そのため、新しいサーバーで organisation を再作成し、ユーザーを再招待する計画を立ててください。