著者 VaultwardenとBitwarden self-hostedの違い
Bitwarden公式版は約12個のコンテナとRAM 2 GB以上が必要です。1コンテナで動くVaultwardenとの違いを比較し、VPSに合う構成を解説します。
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 を暗号化します。そのため、サーバーには読み取れないデータが保存されます。vault の形式も、どちらも Bitwarden のものです。異なるのは、必要なマシンの規模、コードの保守担当、有料の機能、そしてバックアップ対象です。
Vaultwarden の README には、その位置付けが明確に記載されています。「このプロジェクトは Bitwarden または Bitwarden, Inc. と関係ありません」。これはボランティアによるプロジェクトであり、サポート窓口も保証もありません。現在活動しているメンテナーの 1 人は Bitwarden に勤務し、個人の時間を使って貢献しています。ただし、これは便宜的な協力であり、Bitwarden による推奨を意味するものではありません。
インストールできる3つのスタック
多くの比較では、Bitwarden が2種類の異なるセルフホスト製品を提供している点が見落とされています。
Bitwarden standard。 シェルスクリプトで実行する、ベンダー提供のデプロイ方式です。
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 を指定します。./bitwarden.sh start がイメージを取得し、スタックを起動します。Bitwarden は、最小要件として RAM 2 GB とストレージ 12 GB、推奨要件として RAM 4 GB とストレージ 25 GB、Docker Engine 26 以降および Compose plugin を記載しています。データベースには MSSQL Express イメージを使用します。このエディションでは、外部データベースを指定しない限り、リレーショナルデータベースの容量が 10 GB に制限されます。
Bitwarden lite。 以前は Bitwarden Unified と呼ばれていたデプロイ方式です。2025年12月にベータ版を終了し、名称が変更されました。アプリケーションコンテナ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つの注意点があります。対象はビジネス用途ではなく、個人利用およびホームラボです。また、自動データベースバックアップは実行されないため、バックアップはすべて利用者が担当します。
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:latest公開設定では、ポート 8000 を loopback のみにバインドしています。これは意図した設定です。Vaultwarden は平文 HTTP を提供し、前段のリバースプロキシで TLS（transport layer security）を終端する構成を想定しています。ここで TLS は必須です。Web vault はブラウザーの WebCrypto API で暗号化しますが、ブラウザーがこの API を公開するのは secure context 内だけです。そのため、平文の http では、サーバーに要求が届く前にブラウザー上でログインページが失敗します。プロキシと証明書については、Vaultwarden の完全なインストール手順で説明します。
Bitwarden をセルフホストする場合、Vaultwarden はどの程度の RAM を使用しますか？
ベンダーが示す最低要件は、インストーラーが実行を拒否する下限であり、ソフトウェアが実際に必要とするメモリ量ではありません。以下の数値は、RAM 4 GB の Ubuntu 24.04 環境で、各インストールを 1 ユーザー、小規模な vault、添付ファイルなしの状態にしてアイドル状態で測定した docker stats --no-stream の結果です。ディスク使用量は、初回起動に成功した後のイメージとデータディレクトリの合計です。
The data behind this chart
[
{
"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 スタックは 2,400 MB 前後を 12 個のコンテナで使用し、その大半を MSSQL コンテナが占めます。Bitwarden lite は、MariaDB コンテナを含めて 470 MB でした。これらの数値をそのまま信頼する前に、自分の環境で同じコマンドを実行してください。使用量はユーザー数、添付ファイル、同期トラフィックによって変化し、MSSQL は稼働時間が長くなるほどワーキングセットが増えるためです。
小規模な VPS では、SQLite を使用する Vaultwarden は 1 GB プランで問題なく動作します。一方、標準の Bitwarden スタックはその環境では起動しません。2 GB プランでは、標準スタックは文書化された最低要件を満たしますが、OS に残るメモリはほとんどありません。そのため、kernel の out of memory killer が実際に動作する可能性があります。発動すると、dmesg が強制終了したプロセス名を含む行を出力します。このスタックでは通常、そのプロセスは sqlservr です。標準デプロイメントには 4 GB を割り当ててください。
Vaultwarden ではどの有料機能を無料で利用できますか
Bitwarden のサーバーを運用するだけなら費用はかかりませんが、ライセンスファイルをアップロードするまで有料機能は利用できません。Premium 個人アカウントと、すべての有料組織プラン（Families、Teams、Enterprise）にはライセンスファイルが必要です。個人の場合はクラウド Web ボルトで Settings、Subscription の順に開き、組織の場合は Admin Console で Billing、Subscription の順に開いてダウンロードします。その後、自分のインスタンスにアップロードします。組織のライセンスは、./bwdata/env/global.override.env に保存されているインストール ID に対して発行されます。そのため、セルフホストの組織でも有料サブスクリプションを保持し、課金のために Bitwarden のクラウドへ接続します。
Vaultwarden では、ライセンスもサブスクリプションも必要なく、同じ機能を有効にできます。プロジェクト wiki には次の機能が記載されています。
- 組織、コレクション、グループ
- ファイル添付
- メール、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 ボルトをすべて接続できます。各クライアントでは、ログイン前に環境設定画面でセルフホストサーバーの URL を設定します。ログイン後に設定することはできません。
追加設定が必要な機能が 1 つあります。モバイルアプリへのプッシュ通知です。プッシュ通知がない場合、アプリは開いたとき、または設定された間隔で同期します。そのため、ノートパソコンで変更したパスワードは、スマートフォンで確認するまで反映されません。Vaultwarden は Bitwarden のプッシュリレーを利用できます。そのためには、公式インストーラーが使用する同じ https://bitwarden.com/host ページから取得した installation ID と key が必要です。
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 も必要です。デバッグに長時間を費やす前に知っておくべき注意点が 2 つ、wiki に記載されています。F-Droid または Neo Store からインストールしたアプリには Firebase のサポートがないため、サーバー側の設定に関係なくプッシュ通知を受信できません。Vaultwarden 1.30.2 より前に接続したアプリでは、プッシュトークンを登録できるようにデータを消去する必要があります。
再実装はどの程度安全ですか？
Bitwarden の監査履歴は長く、公開されています。Cure53 は 2018 年、2021 年、2022 年、2023 年に監査を実施しました。IOActive と Mandiant は 2024 年にクライアントを監査し、Fracture Labs は 2024 年から 2025 年にかけて Web とネットワークを評価しました。Unit 42 は 2025 年にモバイルアプリを評価し、ETH Zurich Applied Cryptography Group は 2025 年に暗号技術をレビューしました。
Vaultwarden も外部の組織による調査を受けています。誰も調査していないと思っている人には意外かもしれません。ドイツ連邦情報セキュリティ庁（BSI）は、Caos 3.0 コード分析プロジェクトの一環として、2024 年 2 月から 5 月にかけて mgm security partners に Vaultwarden のテストを依頼しました。このレビューでは、2 件の指摘が high と評価されました。別途、ERNW は 1.32.5 未満のバージョンに影響する認証バイパス（CVE-2024-55225）を報告し、2024 年 11 月に修正されました。2026 年 7 月の Version 1.37.0 では、icon エンドポイントを介した SSRF（server side request forgery）、組織をまたぐ cipher へのアクセス、ディレクトリインポート時の組織ポリシーのバイパスに対する修正が提供されました。
この履歴から、脆弱性の報告と修正を機能させているプロジェクトであることが分かります。同時に、繰り返し問題になっている攻撃対象も示されています。それが admin page です。そのため、このページを機密性の高い機能として扱ってください。ADMIN_TOKEN が設定されていない限り無効になり、平文の token ではなく hash を保存する必要があります。
docker run --rm -it vaultwarden/server /vaultwarden hashこのコマンドは、ADMIN_TOKEN に貼り付ける Argon2 PHC 文字列（password hashing competition format）を出力します。admin page を有効にする前に HTTPS を有効にしてください。token はリクエストで送信されるため、平文の HTTP 接続では通信経路上の誰でも平文の token を読み取れるからです。可能な限り /admin をパブリックインターネットから隔離し、サーバー上の SSH アクセスを制限する など、通常のホスト強化策も併用してください。
公式 API の変更で何が壊れるか
これは過小評価されがちなリスクです。Bitwarden はクライアントをリリースし、各クライアントはアプリストアから夜間に自動更新されます。Vaultwarden はそれに追随する必要があります。クライアントのリリースで API の契約が変わると、更新していない Vaultwarden に、すでに新しい API へ移行したクライアントが接続することになります。その結果、手を加えていないデバイスでログインや同期が失敗し始めます。
リリースノートには具体例があります。Vaultwarden 1.37.0 には、「2026.7.0+ のバージョンのクライアントをサポートするには、この更新が必要です。クライアントに関する問題を報告する前に更新してください」と記載されています。2026 年 8 月時点の現行リリースは、2026 年 7 月 29 日に公開された 1.37.1 です。
この問題を単純に保つには、2 つの習慣が役立ちます。まず、latest の代わりに特定のイメージタグを固定します。これにより、無人の pull によって午前 3 時にサーバーが意図せず更新されることを防げます。次に、リリースフィードを監視し、ノートを先に読んだうえで、計画的にアップグレードします。互換性を壊す変更は、そこにしか記載されないためです。たとえば、バージョン 1.35.5 へのアップグレードでは、既存の 2 要素認証の「記憶する」トークンがすべて無効になりました。その結果、保存したつもりの手順からユーザーがログアウトされます。
標準の Bitwarden デプロイメントでは、この問題が逆向きに現れます。アップグレードは ./bitwarden.sh updateself と ./bitwarden.sh update を通じて実行され、更新時にデータベースのマイグレーションが適用されます。マイグレーション前に取得したバックアップは、変更後のスキーマをロールバックするためのものではありません。そのため、バックアップを取得し、取得時点のバージョンを記録してください。
バックアップで実際に Vaultwarden を失うケース
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 スナップショットをスケジュール実行して、別のホストへ転送してください。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 またはデスクトップアプリからエクスポートし、新しいサーバーにアカウントを作成してからインポートします。形式にはプレーンテキストの .json、プレーンテキストの .csv、暗号化された .json、および個別の vault の JSON とファイル添付を格納する .zip があります。カード、ID、保存済みの passkey、SSH key は JSON 形式でのみ保持されるため、CSV で移行するとこれらが通知なく失われます。どのエクスポート形式にもゴミ箱の項目や Sends は含まれません。また、組織が所有するデータは個人のエクスポートには含まれません。
プレーンテキストのエクスポートは、そのまま有効な Secret として扱ってください。ディスク上に vault 全体が平文で保存されるためです。エクスポート、インポート、削除を同じ作業中に行ってください。メールやチャットで送信してはいけません。
移行中に問題になりやすい落とし穴があります。アカウントに紐付いた暗号化エクスポートは、別のアカウントにはインポートできません。サーバーを移行すると、必ず別のアカウントになります。代わりに、パスワードで保護されたエクスポート形式を選択してください。こちらは移行先を限定しません。
Vaultwarden から Bitwarden standard への移行は、より難しい方向です。エクスポートでは組織構造が移行されないためです。新しいサーバーで組織を再作成し、ユーザーを再度招待して、各ユーザーが自分の vault をインポートします。この作業を当日に把握することがないよう、メンテナンス時間をあらかじめ確保してください。
どれを実行すべきですか？
1 人、家族、またはホームラボで 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 は実用的なパスワードマネージャーとして十分安全ですか？
個人や家族で使う場合は、条件付きで安全です。クライアントは保管庫をサーバーへ送る前に暗号化するため、Vaultwarden がマスターパスワードや平文データを見ることはありません。外部レビューも受けています。BSI は mgm security partners に 2024 年 2 月から 5 月にかけてテストを依頼し、ERNW は認証バイパスを報告しました。この問題は 1.32.5 で修正されています。バージョンを最新に保ち、管理ページを無効にするか 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 のライセンスは必要ですか？
無料の個人用保管庫であれば必要ありません。サーバーの運用は無料です。個人向けプレミアム機能や有料の組織プランを有効にするにはライセンスファイルが必要です。対象となるのは Families、Teams、Enterprise です。ライセンスファイルはクラウドの Web 保管庫からダウンロードして、インスタンスへアップロードします。組織ライセンスは、./bwdata/env/global.override.env に保存されたインストール ID に対して発行されます。Vaultwarden にライセンスは不要で、組織機能は自動的に有効になります。
後から Vaultwarden から Bitwarden へ、またはその逆へ移行できますか？
はい。どちらの方向にもクライアントを使って移行できます。各ユーザーが Web 保管庫またはデスクトップアプリから保管庫をエクスポートし、新しいサーバーでアカウントを作成してからインポートします。.zip 形式のエクスポートには個人用保管庫の添付ファイルが含まれます。JSON 形式にはカード、ID、パスキー、SSH キーが含まれます。ごみ箱の項目と Sends はどのエクスポート形式にも含まれません。また、組織が所有する項目は所有者が個別にエクスポートする必要があります。そのため、新しいサーバーで組織を再作成し、ユーザーを再招待する計画を立ててください。