Vaultwarden自己ホスト完全ガイド:月額数百円でBitwardenを自前運用する手順
TL;DR
パスワードの金庫を他社クラウドに預けず、自分のサーバー(VPS)に置きたい——その方法が Vaultwarden のセルフホストです。月額は VPS 代のみ(安ければ数百円〜)で、Bitwarden の公式アプリがそのまま使えます。
構築の流れはシンプルです。
- Docker で Vaultwarden コンテナを起動
- Nginx でリバースプロキシを設定し、HTTPS 化
- Bitwarden アプリの接続先を自前サーバーに切り替える
- データのバックアップを仕込む
難しいのは「動かすこと」より、引っかかりやすい罠を知ることです。この記事ではその罠を先に説明してから手順に入ります。
Vaultwarden・Bitwarden・Dockerとは(初出用語まとめ)
手順に入る前に、この記事で出てくる用語を整理します。
Bitwarden(ビットウォーデン)とは、パスワードを安全に保管・同期するサービスです。ブラウザ拡張・スマホアプリが無料で使え、知名度の高いパスワードマネージャーの一つです。公式版は Bitwarden社のクラウドに保管します。
Vaultwarden(ヴォールトウォーデン)とは、Bitwarden サーバーの非公式・軽量互換実装です。Rust で書かれたオープンソースソフトウェアで、Bitwarden の公式アプリ(iOS・Android・Chrome拡張・デスクトップ)がそのまま繋がります。無料で使えます。これを自分の VPS で動かすことで、パスワードの保管場所が自分のサーバーになります。
Docker(ドッカー)とは、ソフトウェアを「コンテナ」という箱に入れて動かす仕組みです。OS の違いを吸収して、どこでも同じように動かせます。Vaultwarden の公式イメージが配布されているので、数行のコマンドで起動できます。
リバースプロキシとは、外からのアクセスを一度受け取り、後ろで動いているアプリ(ここでは Vaultwarden)に転送する中継役です。Nginx をリバースプロキシとして使い、HTTPS の処理もここで担います。
構築前に知っておく3つの罠
手順の後で「なぜ動かないか」を調べるより、先に知っておくほうが効率的です。
罠1:最近の Bitwarden クライアントはHTTPS必須
http:// のアドレスで Vaultwarden を立てても、Bitwarden のブラウザ拡張やアプリが接続を弾きます。「安全でない接続は許可しない」という制約がクライアント側に入っているためです。
ローカル環境でも HTTPS が要ります。 VPS で運用する場合も、https://vault.example.com のように、SSL 証明書を取得してドメインに当てる必要があります。証明書は Let’s Encrypt(無料)で取れます。
罠2:アプリのログイン先が初期値は本家クラウドのまま
Bitwarden のアプリをインストールして、そのままユーザー名とパスワードを入力しても「パスワードが違います」と怒られます。実際はパスワードが違うのではなく、繋ぎ先が自前サーバーになっていないのが原因です。
ログイン画面の「サーバーURL」または「セルフホスティング」の設定を開き、自前の Vaultwarden の URL(例:https://vault.example.com)を入力してから認証してください。このひと手間を忘れると、自前サーバーに作ったアカウントには一切繋がりません。
罠3:SIGNUPS_ALLOWED=true のまま放置は厳禁
初期設定で SIGNUPS_ALLOWED=true(誰でも登録可能)のまま放置すると、公開サーバーの場合は不特定多数がアカウントを作れます。自分と関係者のアカウントを作り終えたら、すぐに false に変更してコンテナを再起動してください。
必要なもの
- VPS:Ubuntu 22.04 以上・1vCPU・1GB RAM 以上(512MB でも動くが余裕を持って)
- ドメイン:
vault.example.comなど(HTTPS 化に必要。ドメインがなければ取得が先) - Docker・Docker Compose:VPS に導入済みであること
- Nginx:リバースプロキシとして使用
Step 1:ディレクトリ作成と docker-compose.yml
mkdir -p /opt/vaultwarden && cd /opt/vaultwarden
docker-compose.yml:
services:
vaultwarden:
image: vaultwarden/server:latest
container_name: vaultwarden
restart: unless-stopped
ports:
- "127.0.0.1:8080:80"
volumes:
- vw-data:/data
env_file:
- .env
volumes:
vw-data:
127.0.0.1:8080 にバインドすることで、Vaultwarden はリバースプロキシ経由でのみアクセス可能になります。インターネットから直接叩けない構成です。
Step 2:.env ファイルの設定
# .env
DOMAIN=https://vault.example.com
SIGNUPS_ALLOWED=true # 初期アカウント作成後に false に変更
ADMIN_TOKEN= # 後述の手順で Argon2 ハッシュを生成して入れる
ENABLE_WEBSOCKET=true # リアルタイム同期に必要
管理者トークンの生成(Argon2id):
docker run --rm -it vaultwarden/server /vaultwarden hash
# パスワードを入力するとArgon2ハッシュが出力される
# 出力された文字列を ADMIN_TOKEN に設定する
平文パスワードをそのまま ADMIN_TOKEN に入れないでください。Argon2 ハッシュのみ有効です。
Step 3:Nginx リバースプロキシ設定
server {
listen 443 ssl;
server_name vault.example.com;
ssl_certificate /etc/letsencrypt/live/vault.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/vault.example.com/privkey.pem;
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
# WebSocket(リアルタイム同期に必要)
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
}
server {
listen 80;
server_name vault.example.com;
return 301 https://$host$request_uri;
}
現行バージョンでは、WebSocket は通常 HTTP ポートと同じポートで処理されます。旧バージョンで必要だった /notifications/hub 用の別ロケーションブロックは不要です。
SSL 証明書は Certbot(Let’s Encrypt)で取得します。
certbot --nginx -d vault.example.com
Step 4:起動と初期設定
docker compose up -d
docker compose logs -f # ログでエラーがないか確認
初期設定の手順:
vault.example.com は説明用の仮ドメインです。実際にブラウザで開くときは、Step 2で .env の DOMAIN に設定した自分のドメインに読み替えてください(例のまま開いても表示されません)。
https://vault.example.com(=自分のドメイン)でアカウントを作成- 全員のアカウント作成が終わったら
.envのSIGNUPS_ALLOWED=falseに変更 docker compose restartでコンテナ再起動https://vault.example.com/admin(=自分のドメイン +/admin)に管理者パスワードでログイン → 設定を確認
Step 5:Bitwarden アプリの接続先を切り替える
これは Bitwarden クライアントを初めて設定するときに必ず必要な手順です(罠2の回避策)。
ブラウザ拡張・スマホアプリ共通で、ログイン画面の「自己ホスト」または「サーバーURL」欄に https://vault.example.com(自前のアドレス)を入力します。この設定をしてからアカウントにログインしてください。
設定の場所はクライアントのバージョンで若干異なりますが、ログインボタン付近に「サーバーURL を変更」または歯車アイコンがある場合が多いです。見当たらない場合はアプリ内の設定 → アカウント → サーバー URL の順に探してください。
Step 6:バックアップ設定(最重要)
パスワードマネージャーはバックアップが止まった瞬間に運用失敗です。3-2-1ルール(3コピー・2種類のメディア・1拠点外)を最低限守ってください。
バックアップ対象のデータは Docker ボリューム vw-data に入っています。
SQLite のバックアップ(実行中のコンテナから安全に取得):
# 直接ファイルをコピーしない(破損リスクがある)
# 必ず .backup コマンドを使う
docker exec vaultwarden sqlite3 /data/db.sqlite3 \
".backup '/data/db-backup.sqlite3'"
# バックアップファイルをホストにコピー
docker cp vaultwarden:/data/db-backup.sqlite3 /backup/vaultwarden/
バックアップ対象のファイル:
db.sqlite3— メインDB(パスワード全件)attachments/— 添付ファイルsends/— Send 機能のデータrsa_key.pem/rsa_key.pub.pem— 暗号化キーconfig.json— 設定
cron で毎日自動バックアップ:
# crontab -e
0 3 * * * docker exec vaultwarden sqlite3 /data/db.sqlite3 \
".backup '/data/db-backup.sqlite3'" && \
cp /var/lib/docker/volumes/vaultwarden_vw-data/_data/db-backup.sqlite3 \
/backup/vaultwarden/db-$(date +\%Y\%m\%d).sqlite3
バックアップは VPS の外(クラウドストレージ・手元のマシン)にも転送してください。VPS 内だけのバックアップは、VPS ごと壊れた場合に無意味です。
Cloudflare Tunnel との連携(ポート開放なしで公開)
VPS のポートを直接インターネットに公開したくない場合、Cloudflare Tunnel を使うと UFW でポートを閉じたままセキュアに公開できます。
Cloudflare Tunnel って何? Cloudflare(CDN・DNS 管理で知られるサービス)が提供する、ポート開放なしにサーバーを外部公開する仕組みです。VPS 上で
cloudflaredというエージェントを動かすと、Cloudflare のネットワーク経由でトンネルが張られます。個人利用は無料枠の範囲で使えます。
# cloudflared インストール(Ubuntu)
curl -L https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb -o cloudflared.deb
dpkg -i cloudflared.deb
# 認証
cloudflared tunnel login
# トンネル作成
cloudflared tunnel create vaultwarden
# トンネル設定ファイル (~/.cloudflared/config.yml)
tunnel: <TUNNEL_ID>
credentials-file: /root/.cloudflared/<TUNNEL_ID>.json
ingress:
- hostname: vault.example.com
service: http://127.0.0.1:8080
- service: http_status:404
注意点: Cloudflare Tunnel 経由のトラフィックは Cloudflare で一度復号化されます。パスワードデータ自体は Bitwarden の暗号化(AES-256)で保護されているため、Cloudflare はデータの内容を読めません。ただし「自分のサーバーとクライアントの間を誰も通したくない」というポリシーがある場合は、Tunnel を使わず直接 HTTPS を提供する構成を選んでください。
まとめ:コスト比較
| 項目 | 1Password Business | Vaultwarden |
|---|---|---|
| 50人・月額 | 約60,000円 | 約1,500円(VPS) |
| 50人・年額 | 約720,000円 | 約18,000円 |
| クライアントアプリ | 専用 | Bitwarden公式(全OS) |
| サポート | 公式24/7 | コミュニティ・自己責任 |
| 運用負荷 | ゼロ | バックアップ・アップデート |
運用負荷が増える分、コストが下がる構造です。社内に Linux/Docker を触れる担当者がいるかどうかが、導入判断の分かれ目になります。個人・小規模チームで「クラウドに預けたくない」場合は、自己ホストの選択肢は十分に現実的です。
この続きはメンバー限定です
メールアドレスを登録すると、本記事の続き(設定ファイル・コード)と全 6 本のメンバー限定記事がその場で読めます。無料・いつでも解除可。