【2026年】Vaultwarden パスワード管理セルフホスト｜Bitwarden互換の決定版

最後に Docker のインストールと更新を行います。これにより、最新かつ安定したバージョンの Docker Engine が導入されます。

sudo apt update && sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

インストール後は、Docker サービスが正しく起動しているか確認します。また、ユーザー権限を付与することで sudo なしで Docker コマンドを実行できるように設定することも推奨されます。これにより、後続のコンテナ操作がスムーズに行えます。さらに、サーバーにはファイアウォールとして UFW（Uncomplicated Firewall）を設定し、不要なポートへのアクセスをブロックしておきます。Vaultwarden を運用する際、外部からの不正アクセスを防ぐためにも、SSH 接続用のポート 22 以外の通信は原則ブロックするか、リバースプロキシ経由のみ許可する設定が必須です。

データベース選定：SQLite と PostgreSQL の比較

Vaultwarden のバックエンドストレージには、主に SQLite、PostgreSQL、MySQL の三つの選択肢があります。これらのデータベースエンジンは、それぞれ異なる特性を持っており、利用環境や運用方針に応じて適切に選択する必要があります。特に、サーバーのディスク容量やパフォーマンス要件、そして将来のスケーラビリティを考慮することが重要です。SQLite はファイルベースのデータベースであり、設定が最もシンプルです。テーブル構造が単一のバイナリファイルに保存されるため、バックアップや移行も非常に容易で、小規模な環境での利用に適しています。

一方、PostgreSQL や MySQL などのクライアント/サーバー型データベースは、複数のプロセスから同時にデータへのアクセスを効率的に行う設計になっています。これにより、多数のユーザーが同時にログインしたり、大量の Vault Items を更新したりする状況でも、パフォーマンスが低下しにくいというメリットがあります。2026 年時点では、PostgreSQL が最も推奨される選択肢の一つとなっています。特に、Vaultwarden の拡張機能や高負荷な運用において、トランザクションの整合性を保ちつつ、高い処理能力を発揮します。SQLite を使用した場合、バックアップ中にデータベースがロックされて読み取り不能になるリスクがありますが、PostgreSQL ではそのような問題は発生しません。

以下の表は、主要な三つのデータベースエンジンの特徴を比較したものです。自身の運用環境に合わせて判断材料としてください。

SQLite を選ぶ場合、data.db ファイルの保存場所を外部ストレージに設定し、定期的なスナップショット取得が必須となります。バックアップ戦略が甘くなるリスクがあるため、この点は理解しておく必要があります。PostgreSQL を導入する場合も、Vaultwarden 側で接続情報（ユーザー名、パスワード、データベース名）を環境変数として指定する必要があるため、Docker Compose の設定ファイルに追記する必要があります。

また、2026 年時点のセキュリティ要件として、データベースレベルでの暗号化や監査ログ機能も考慮されることがあります。PostgreSQL を使用する場合、ディスク暗号化（LUKS）と組み合わせることで、物理的なサーバーへの不正アクセスからもデータを保護できます。MySQL については、既存のシステムで MySQL を管理している場合の移行コストが低いという利点がありますが、Vaultwarden の開発コミュニティにおけるサポートやドキュメントの充実度では PostgreSQL にやや劣ります。したがって、新規構築であれば SQLite（簡易用）または PostgreSQL（推奨）を選択するのが賢明です。

Vaultwarden サーバーの Docker 導入手順

本節では、実際に Vaultwarden を Docker Compose でデプロイする具体的な手順を解説します。まず、インストールディレクトリを作成し、その中に設定ファイルを配置します。例えば /opt/vaultwarden というパスが一般的です。このディレクトリには docker-compose.yml ファイルと .env 設定ファイルが必要となります。.env ファイルは環境変数を定義するためのもので、パスワードやドメイン名などをここで管理し、ソースコードに直接記述しないことでセキュリティを担保します。Vaultwarden のバージョン指定は、必ず最新安定版を使用するよう努めますが、例として 1.32.x を想定した設定を記載します。

docker-compose.yml ファイルの内容は、コンテナの定義とボリュームのマウント、そして環境変数の引き渡しを行います。以下の構成は、PostgreSQL バックエンドを利用し、Caddy リバースプロキシも同梱する標準的な構成です。ファイル作成後、所有者を root にせず、必要に応じて適切なユーザー権限で実行しますが、Docker コンテナ内部の動作は Root 権限で行われることが多いため注意が必要です。

version: '3.5'
services:
  vaultwarden:
    container_name: vaultwarden
    image: vaultwarden/server:latest
    restart: always
    ports:
      - "127.0.0.1:8080:80"
    volumes:
      - /opt/vaultwarden/data:/data
      - /opt/vaultwarden/config/.env:/config/.env:ro
    environment:
      - ROCKET_ENV=production
      - DOMAIN=https://vault.example.com
      - SIGNUPS_ALLOWED=false
      - WEBSOCKET_ENABLED=true
      - ADMIN_TOKEN=<生成された管理用トークン>

  caddy:
    container_name: caddy
    image: caddy:latest
    restart: always
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /opt/vaultwarden/data/Caddyfile:/etc/caddy/Caddyfile
      - /opt/vaultwarden/data/caddy_data:/data
      - /opt/vaultwarden/data/caddy_config:/config

この設定で注意すべき点は、ポートマッピングとボリュームパスです。127.0.0.1:8080:80 は、Vaultwarden の内部ポート 80 をローカルホストの 8080 にバインドしています。これはセキュリティ上の理由から推奨される設定で、外部からの直接アクセスを防ぎ、リバースプロキシ（Caddy）を介してのみ接続できるようにします。また、ADMIN_TOKEN は管理画面へのログインに必要となるトークンであり、強力で一意な文字列を設定する必要があります。これを取得するには、Vaultwarden 初回起動時にコンテナのログを確認するか、API を利用して生成します。

.env ファイルには、より詳細な設定項目が記述されます。例えば SIGNUPS_ALLOWED=false とすることで、登録画面を無効化し、既存ユーザーのみがログインできる封闭型環境にできます。これはセキュリティリスクを低減する有効な手段です。また、SMTP サーバーの設定も必要になります。メール通知機能（2FA リセットや緊急アクセス通知など）を使用するためには、Gmail や自社の SMTP サーバーの情報を .env に記述する必要があります。パスワード管理ツールにおいて、アカウント復旧は生命線となるため、この設定は必須です。

# .env ファイル例
DOMAIN=https://vault.example.com
ROCKET_ENV=production
SIGNUPS_ALLOWED=false
ADMIN_TOKEN=xxxxxxxxxxxxxxxxxxxxxx
[email protected]
SMTP_SERVER=smtp.gmail.com
SMTP_PORT=587
[email protected]
SMTP_PASSWORD=<アプリパスワード>

これらの設定ファイルが揃った後、docker-compose up -d コマンドを実行してコンテナを起動します。この際、エラーが発生しないかログを監視することが重要です。Vaultwarden は Rust で書かれているため、起動は非常に高速ですが、データベース接続エラーや SSL 証明書の生成ミスなどが発生しうるポイントです。正常に起動すると、Caddy が自動的に Let's Encrypt から TLS 証明書を取得し始めます。これにより、HTTPS 接続が自動で有効化され、ブラウザのアドレスバーに鍵マークが表示されるようになります。

リバースプロキシ設定と TLS/SSL 証明書

Vaultwarden を外部から安全にアクセスさせるためには、リバースプロキシサーバーと TLS/SSL 証明書の設定が不可欠です。直接 Docker コンテナのポートを公開するのではなく、Caddy や Traefik などのソフトウェアを介してアクセスを処理します。これにより、ポート転送の設定を複雑に行わずとも、ドメイン名ベースで SSL 接続を確立できます。2026 年現在、Let's Encrypt は無料かつ信頼性の高い証明書発行機関として標準的に利用されており、Caddy を用いた設定は自動化機能が特に優れています。

Caddy の設定ファイル Caddyfile は非常に簡潔に記述できます。Vaultwarden のドメイン名を指定し、バックエンドのコンテナへの転送ルールを設定するだけで十分です。以下の構成は、HTTPS 接続を強制し、HTTP から HTTPS へのリダイレクトも自動で行う設定例です。

vault.example.com {
    reverse_proxy localhost:8080 {
        header_up Host {host}
        header_up X-Forwarded-For {remote}
        header_up X-Forwarded-Proto {scheme}
    }
}

この設定により、Caddy コンテナが外部からの 80 番および 443 番ポートのトラフィックを受け取り、Vaultwarden の内部ポート 8080 に転送します。header_up ディレクティブは、クライアントの真正な IP アドレスやプロトコル情報を Vaultwarden に渡すために必要であり、ログ記録やセキュリティ監査に役立ちます。Vaultwarden はこのヘッダー情報を使って、ユーザーの所在地や不正ログイン検知のロジックに利用可能です。

また、SSL 証明書の有効期限管理についても考慮する必要があります。Let's Encrypt の証明書は通常 90 日間の有効期間を持ちますが、Caddy は自動的に更新処理を行うため、手動での更新作業は不要です。ただし、Caddy コンテナ内のデータ（caddy_data）が消えないようにボリュームマウントを正しく設定しておくことが重要です。万が一コンテナが破損しても証明書情報が保持されるため、再発行の手間を省けます。

以下に、主要なリバースプロキシツールの比較表を示します。Caddy が最も手軽ですが、他のツールを使用する際のメリットも理解しておきましょう。

Nginx を利用する場合、certbot プラグインを使用して証明書を発行・更新する必要があります。これはより柔軟な制御が可能ですが、設定の複雑さが増すため、Vaultwarden のような単一サービス向けには Caddy が推奨されます。Traefik はマイクロサービス構成や多くのサービスを管理する環境で威力を発揮しますが、単体の Vaultwarden サーバーであればややオーバースペックかもしれません。いずれにせよ、プロキシ層が TLS 終端を行うことで、Vaultwarden 本体は暗号化復号の負荷を減らし、アプリケーション処理に集中できるようになります。

クライアント接続と各種機能の設定

サーバー構築が完了したら、次はクライアント側の設定です。Vaultwarden は Bitwarden との互換性を維持しているため、公式のデスクトップアプリやブラウザ拡張機能を使用できます。しかし、初期状態では Bitwarden のクラウドサーバーに接続するようになっているため、設定変更が必要です。例えば、Chrome ブラウザの場合は「Bitwarden」拡張機能をインストールし、設定画面から「カスタムサーバー URL」を入力します。この際、入力するのは https://vault.example.com のような形式になります。

モバイルアプリ（iOS/Android）の場合も同様に、アプリの設定メニューにある「Vault 構成」または「カスタムサーバー」オプションを選択し、先ほど準備したドメイン URL を入力して保存します。接続に成功すると、ユーザー名とマスターパスワードの入力を求められます。ここで注意すべき点は、マスターパスワードの再設定がサーバー側では不可能であるということです。Vaultwarden はゼロ知識アーキテクチャを採用しているため、サーバー管理者ですらマスターパスワードをリセットできません。したがって、強力なマスターパスワードの設定と、それを安全に記憶しておくことが不可欠となります。

クライアント接続後の機能利用についても確認が必要です。特に「Send」機能（ファイル送信）や「Organizations」機能は、設定によって制限されている場合があります。Vaultwarden の .env ファイルで SEND_ENABLED=true に設定することで、ユーザー間でファイルを暗号化して送信できる機能が有効になります。また、「Organizations」機能を使用するには、サーバー管理者としてログインし、Admin Panel から組織を作成する必要があります。これにより、チームメンバーを招待し、共有 Vault やコレクション機能を管理できるようになります。

デスクトップ版の自動ロック機能や、クリップボードからの自動削除設定も推奨されます。セキュリティ向上のためには、長時間ロックされたまま放置しないことが有効です。また、Bitwarden の CLI ツールを利用したバッチ処理や自動化スクリプトの実行も可能であり、技術者層にとって有用な機能です。

各クライアントは独立して動作するため、どのデバイスでも同一の Vault データにアクセス可能です。ただし、複数のデバイスで同時に編集した場合の競合処理については、クラウド同期と同様にサーバー側で管理されます。2026 年時点では、オフラインでの編集機能も強化されており、ネットワーク接続がない環境でもパスワードの閲覧やコピーが可能になっています。これにより、飛行機内などの機密情報取り扱い時にも Vaultwarden を安全に使用できます。

セキュリティ強化と MFA/WebAuthn の活用

Vaultwarden のセキュリティ強度を最大限引き出すためには、多要素認証（MFA）の設定が必須となります。パスワードのみの認証は、フィッシングやブルートフォース攻撃に対して脆弱であるためです。Vaultwarden では、TOTP（Time-based One-Time Password）と WebAuthn/FIDO2 標準に対応しています。TOTP は Google Authenticator や Authy などのアプリを使用して生成される 6 桁のコードを利用する方式で、導入が容易です。設定方法は Vaultwarden の Admin Panel またはユーザーのプロフィール画面から行います。

WebAuthn と FIDO2 は、ハードウェアキー（YubiKey など）や生体認証（Touch ID / Face ID）を使用して認証を行う方式です。これらはフィッシング攻撃に対して極めて強い防御力を持ちます。なぜなら、ログイン時にサーバーが送信したチャレンジ文にハードウェアキーで署名を行うため、偽サイトへの入力を行っても正しく復号化できないからです。2026 年時点では、多くの OS やブラウザが WebAuthn を標準サポートしているため、導入コストは低く抑えられています。

# YubiKey の登録手順（Web ブラウザ上）
1. ユーザー設定 > セキュリティ > WebAuthn キー追加
2. デバイスを選択し、YubiKey のボタンを押下
3. 認証完了で登録終了

緊急アクセス（Emergency Access）機能も重要なセキュリティ対策の一つです。これは、ユーザーが死亡や重傷などで Vault にアクセスできなくなった場合に、信頼できる第三者が一定時間後に Vault を開けるための仕組みです。管理者権限を持つユーザーを「監視者」として設定し、待機時間を指定することで、万が一の際のデータ復旧を保証します。これにより、ビジネス継続性も維持されます。

また、サーバー側のセキュリティ強化として、定期的なパスワードの変更や、IP アドレスベースの制限も検討できます。ただし、Vaultwarden はクライアント側で暗号化されているため、サーバー管理者がパスワードを管理するわけではありません。重要なのは、コンテナ自体のセキュリティパッチを適用し続けることです。docker-compose pull && docker-compose up -d を定期的に実行することで、最新の脆弱性修正を含むイメージに更新されます。

2FA の設定は、マスターパスワード入力後に必須となるため、ロックアウトリスクも伴います。したがって、リカバリーコードの印刷や保存も併せて推奨します。また、ログイン試行回数制限の設定も可能であり、ブルートフォース攻撃への耐性を高めます。このように、多層的なセキュリティ対策を講じることで、Vaultwarden は最強のパスワード管理ツールとしての地位を確立します。

バックアップ戦略と災害復旧の手順

セルフホスト環境における最大のリスクは、サーバーのハードウェア故障やデータ損失です。Vaultwarden のデータを確実に保護するためには、定期的なバックアップと、それに基づくリカバリ手順の確立が不可欠です。Vaultwarden はデータベースファイル（SQLite の場合 .db ファイル）と、ユーザーがアップロードしたファイル（画像など）を保存しています。これらをすべて含めてバックアップする必要があります。

バックアップツールとしては、rclone が最も汎用性が高くおすすめです。rclone を使用することで、ローカルディスクから AWS S3、Google Drive、Backblaze B2 などのクラウドストレージへデータを転送・複製できます。スクリプトを組み合わせて cron job に登録すれば、自動的にバックアップが実行されます。

# rclone コマンド例（S3 バックアップ）
rclone copy /opt/vaultwarden/data remote:bucket_name/backup --delete-excluded

また、borg backup や restic などの圧縮・暗号化バックアップツールを使用して、ディスクイメージレベルの保護を行うことも可能です。これらのツールは差分バックアップに対応しており、容量効率が良いという利点があります。特に Vaultwarden のデータサイズが増大した場合、フルバックアップではなくインクリメンタルな手法が求められます。

リカバリ手順を事前にテストしておくことが重要です。例えば、別のサーバーに Vaultwarden をデプロイし、バックアップデータからリストアするシミュレーションを行います。特にデータベースファイルの整合性を保つために、コンテナ停止中にバックアップを行うのが安全です。docker-compose down で停止させ、tar czf backup.tar.gz data.db などでアーカイブを作成します。

また、バックアップデータの暗号化も忘れずに行う必要があります。クラウドストレージ上でも平文で保存されるリスクを排除するため、rclone の --cipher オプションや、borg のパスワード設定機能を活用します。万が一、マスターパスワードを失った場合のデータ復旧については、サーバー管理者は関与できませんが、バックアップデータから Vault ファイルを抽出できる仕組みがあれば、サポートセンターへの問い合わせなどで復元が可能な場合があります。

外部アクセス対策：Tailscale とポートフォワードリング

Vaultwarden をインターネット上に公開する場合、セキュリティリスクが高まります。ポート 80/443 を直接開放するポートフォワードリングは便利ですが、DDoS 攻撃や不正スキャンの標的になりやすいです。より安全な外部アクセス手段として、Tailscale などの VPN ツールの利用が推奨されます。Tailscale は WireGuard ベースのゼロトラストネットワークを提供し、サーバーとクライアント間のトンネルを自動的に確立します。

Tailscale を使用する場合、Vaultwarden サーバーに Tailscale クライアントを導入し、自分のアカウントにログインさせます。これにより、インターネット経由ではなく、Tailscale の管理下にある仮想 IP アドレス（100.x.x.x など）を通じて Vaultwarden にアクセスできるようになります。外部からポートを開ける必要がないため、ファイアウォール設定がシンプルになります。

# Tailscale インストール例 (Ubuntu)
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --accept-routes --advertise-exit-node

この構成では、クライアント側も Tailscale をインストールしておく必要があります。しかし、一度設定すれば、自宅からでも社外からでも、安全なトンネルを介して Vaultwarden にログインできます。また、Tailscale には MagicDNS という機能があり、IP アドレスの代わりにホスト名（例：vault.local）でアクセスできるため、管理も容易になります。

ポートフォワードリングを選ぶ場合でも、Cloudflare Tunnel や Nginx のレートリミット設定などを用いて攻撃を緩和する必要があります。2026 年時点では、ゼロトラストアーキテクチャの概念が浸透しており、ネットワーク境界に依存しないアクセス制御が標準となっています。Vaultwarden のような機密情報を扱うサービスでは、Tailscale を併用して「アクセス可能な IP を限定する」対策が最も効果的です。

主要パスワード管理ツールとの包括的比較

最後に、Vaultwarden が他の主要なパスワード管理ツールとどう異なるのかを徹底比較します。Bitwarden クラウド版はセキュリティと利便性のバランスが良いですが、月額費用が発生し、サーバー側でデータを保持することになります。1Password は UX が優れていますが、コストが高く、セルフホストには対応していません。Passbolt はグループウェア連携に強く、KeePassXC は完全ローカル型です。

以下の表は、主要な 4 つのツールを機能、リソース、料金、互換性の観点から比較したものです。これらを踏まえて、自身のニーズに最も適したツールを選択してください。

Vaultwarden の最大の強みは、「Bitwarden クライアントの互換性」と「完全なセルフホスト」を両立している点です。1Password は UX で優れていますが、サーバー側で管理できないためセキュリティリスクがゼロではありません。Passbolt はチーム運用に特化しており、Vaultwarden と似ていますが、よりエンタープライズ向けの機能に焦点を当てています。

KeePassXC はファイルベースの管理であり、クラウド同期機能が弱いため Vaultwarden のようなリアルタイム同期には向きません。しかし、完全なローカル管理を求めるユーザーには KeePassXC が最適です。Vaultwarden を選択することで、クラウド依存からの脱却と利便性の両立が可能となります。

まとめ

本記事では、2026 年時点のセキュリティ基準を踏まえた Vaultwarden のセルフホスト構築ガイドを解説しました。要点をまとめると以下の通りです。

• Vaultwarden の特徴: Rust 実装による軽量化と Bitwarden クライアントとの完全互換性が最大の特徴であり、低スペック環境でも運用可能。
• データベース選定: SQLite は簡易用、PostgreSQL は中規模以上向け。それぞれのリソース要件とバックアップ方法を理解して選択する必要がある。
• デプロイ方法: [Docker Compose](/glossary/pose-context-window-extension) を使用し、Caddy との組み合わせで TLS 自動証明書の発行を実現することで、設定を最小限に抑えられる。
• セキュリティ強化: MFA（TOTP/WebAuthn）の実装と緊急アクセス機能の利用により、アカウント盗難リスクを大幅に低減できる。
• バックアップ戦略: rclone や borg を活用した自動化されたバックアップと、リカバリテストの徹底が必須である。
• 外部アクセス: Tailscale による VPN 接続を活用することで、ポート開放なしで安全な外部アクセスを実現可能。
• 比較検討: 他ツール（1Password, Passbolt）と比較し、コストと機能のバランスを考慮して Vaultwarden を選定する価値が大きい。

Vaultwarden を導入することで、パスワード管理におけるプライバシーリスクを根本から改善できます。ただし、サーバーの管理責任は自分自身にあるため、適切な運用体制の構築が求められます。本ガイドが、安全で自由なデジタルライフの実現に貢献することを願っています。

よくある質問（FAQ）

Q1. Vaultwarden を Raspberry Pi で動かすことは可能でしょうか？ 結論から言うと、可能です。Vaultwarden は Rust 製でありメモリ消費が少ないため、Raspberry Pi 4 などの低スペック機でも動作します。ただし、データベースを [PostgreSQL にする場合、SQLite よりもリソースを消費するため、Pi Zero などでは避けたほうが無難です。Pi 3 以降であれば安定して動作し、家庭内サーバーとして最適です。

Q2. サーバーが故障した際、データは復元できますか？ はい、復元可能です。ただし、マスターパスワードを忘れている場合は、サーバー側から復旧することはできません。ゼロ知識アーキテクチャのため、サーバー管理者もデータを解読できないからです。そのため、バックアップファイル（.db ファイル）と、復号化に必要なマスターパスワードの両方があれば、どこでも Vaultwarden を再構築してデータを読み込めます。

Q3. Bitwarden クラウド版から Vaultwarden への移行方法は？ Bitwarden の公式クライアントで「カスタムサーバー URL」設定を行うことで直接移行可能です。ただし、データ転送機能はデフォルトでは提供されていないため、Export 機能で JSON ファイルをエクスポートし、Vaultwarden の Admin Panel からインポートする必要があります。ユーザー数が多ければスクリプトを利用した一括転送が推奨されます。

Q4. Docker を使わずに直接インストールできますか？ 技術的には可能ですが、非推奨です。Vaultwarden は Rust でコンパイルされたバイナリを提供していますが、依存関係や環境設定が複雑になるため、Docker コンテナ化により隔離された環境で動かすのが安全かつ確実です。特に Web サーバーとの連携を考えると、Docker のメリットは圧倒的です。

Q5. メール通知機能を使わずに Vaultwarden を運用できますか？ はい、可能です。.env ファイルの SMTP 設定をコメントアウトするか、無効化することでメール送信機能をオフにできます。ただし、緊急アクセス通知やパスワードリセット通知が来ないため、ユーザー管理を行うチーム環境では非推奨です。個人利用であれば問題ありません。

Q6. WebAuthn キーはどの種類に対応していますか？ Vaultwarden は FIDO2 標準および WebAuthn に対応しており、YubiKey、Nitrokey、Windows Hello などの認証デバイスが使用可能です。ブラウザ拡張機能経由でハードウェアキーを追加すると、サーバー側での検証が行われます。物理キーがない場合でも、生体認証（指紋/顔）に対応する OS の機能を利用可能です。

Q7. 複数台のサーバーで Vaultwarden を運用できますか？ はい、可能ですが同期には注意が必要です。Vaultwarden は単一データベースを想定しており、マルチマスター構成はサポートされていません。したがって、1 つのマスターサーバーを持ち、他のサーバーはバックアップ用として配置するのが一般的です。負荷分散を行う場合は、リバースプロキシでトラフィックを振り分けます。

Q8. Vault Items の容量制限はありますか？ Vaultwarden 自体には特に容量制限はありませんが、サーバーのディスク容量に依存します。また、ファイル転送機能（Send）では、サイズ制限を設定可能です。通常は数 GB 程度まで問題なく扱えますが、大容量ファイルを扱う場合はクラウドストレージとの連携を検討してください。

Q9. セルフホスト版とクラウド版でセキュリティ強度は異なりますか？ 理論上は同等です。暗号化アルゴリズム（Argon2id など）やプロトコルは同じです。しかし、サーバーの運用責任者が自分自身になるため、設定ミスによるリスクがユーザー側に転嫁されます。セキュリティ知識がある場合は同等以上ですが、初心者にはクラウド版の方が安全な場合もあります。

Q10. コストは完全無料ですか？ ソフトウェア自体はオープンソースで無料です。ただし、サーバーを維持するためのハードウェア代や電気代、ドメイン取得費、SSL 証明書（Let's Encrypt は無料）などのコストは自己負担となります。また、クラウドストレージを利用する場合はその利用料金も発生します。

Linkwarden を使ったセルフホストブックマーク管理を解説。Docker導入、自動アーカイブ、PDF / Screenshot保存、Raindrop.io との比較を詳しく紹介。