Vaultwarden vs Bitwarden 셀프 호스팅 비교 및 선택 가이드

Vaultwarden과 Bitwarden self-hosted의 실체

Vaultwarden과 Bitwarden self-hosted 사이의 선택은 두 개의 서로 다른 비밀번호 관리자 중 하나를 고르는 것이 아니라, 동일한 클라이언트 API를 사용하는 두 서버 중 하나를 선택하는 문제입니다. Bitwarden 공식 스택은 nginx 뒤에서 약 12개의 컨테이너를 실행하고, 모든 데이터를 Microsoft SQL Server에 저장하며, 이메일 주소로 등록한 설치 ID에 종속됩니다. 반면 Vaultwarden은 Rust로 작성된 Bitwarden 클라이언트 API의 비공식 재구현체이며, 하나의 SQLite 파일과 연동되는 단일 컨테이너로 실행됩니다. 두 서버 모두 동일한 엔드포인트에 응답하므로 브라우저 확장 프로그램이나 스마트폰 앱은 이 둘을 구분할 수 없습니다.

암호화 방식은 어느 쪽을 선택하든 동일합니다. Bitwarden 클라이언트는 데이터가 기기를 떠나기 전에 볼트를 암호화하므로, 서버는 내용을 읽을 수 없는 데이터 덩어리(blob)만 저장하게 됩니다. 따라서 볼트 형식은 두 경우 모두 Bitwarden의 규격을 따릅니다. 차이점은 필요한 서버 자원의 규모, 코드 유지보수 주체, 유료 기능의 범위, 그리고 백업해야 할 대상입니다.

Vaultwarden의 README는 해당 프로젝트의 상태를 다음과 같이 명확히 밝히고 있습니다: "이 프로젝트는 Bitwarden 또는 Bitwarden, Inc.와 관련이 없습니다." 이는 지원 데스크나 보증이 제공되지 않는 자원봉사자 중심의 프로젝트입니다. 현재 활동 중인 한 명의 메인테이너가 Bitwarden에서 근무하며 개인 시간을 할애해 기여하고 있으나, 이는 공식적인 보증이 아닌 개인적인 호의에 해당합니다.

설치할 수 있는 3가지 스택

대부분의 비교에서는 Bitwarden이 서로 다른 2가지 self-hosted 제품을 제공한다는 점을 놓친다.

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와 storage 12 GB를, 권장 사양으로 RAM 4 GB와 storage 25 GB를 문서화하고 있다. Docker Engine 26 이상과 Compose plugin도 필요하다. 데이터베이스는 MSSQL Express image이며, Bitwarden 문서에는 관계형 데이터베이스의 최대 크기가 10 GB라고 되어 있다. 이 크기가 부족하면 외부 데이터베이스를 사용하도록 배포를 구성할 수 있다.

Bitwarden lite. 이전에 Bitwarden Unified라고 불리던 배포 방식이다. 2025년 12월에 beta를 종료하고 이름을 변경했다. 애플리케이션 container 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와 storage 1 GB가 필요하다. Bitwarden 자체 문서에는 2가지 주의 사항이 있다. 이 배포 방식은 business use가 아니라 personal use와 home lab을 대상으로 문서화되어 있다. 또한 데이터베이스를 자동으로 백업하지 않으므로 백업은 전적으로 직접 관리해야 한다.

Vaultwarden. project README에서 바로 가져와 사용하는 container 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

publish line은 port 8000을 loopback에만 바인딩한다. 이는 의도된 설정이다. Vaultwarden은 plain HTTP를 제공하며, 앞단의 reverse proxy가 TLS(transport layer security)를 종료하기를 기대한다. 여기서 TLS는 선택 사항이 아니다. web vault는 browser의 WebCrypto API로 암호화를 수행하며, browser는 secure context에서만 이 API를 제공한다. 따라서 plain http에서는 서버에 요청이 전달되기 전에 browser에서 login page가 실패한다. Vaultwarden 전체 설치 안내에서 proxy와 certificate 설정을 다룬다.

Vaultwarden은 Bitwarden 셀프 호스팅 대비 RAM을 얼마나 사용합니까?

공급업체가 제시하는 최소 사양은 설치 프로그램이 실행을 거부하지 않는 하한선일 뿐, 소프트웨어가 실제로 점유하는 자원량을 의미하지는 않습니다. 아래 수치는 RAM 4 GB를 탑재한 Ubuntu 24.04 서버에서 사용자 1명, 작은 볼트, 첨부 파일 없음 상태로 유휴 설치된 환경을 docker stats --no-stream로 측정한 결과입니다. 디스크 사용량은 이미지와 첫 성공적인 시작 이후의 데이터 디렉터리를 합산한 값입니다.

[
  {
    "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 스택은 12 개의 컨테이너에서 2,400 MB 근처의 유휴 메모리를 점유했으며, 이 중 대부분은 MSSQL 컨테이너가 차지합니다. Bitwarden lite는 MariaDB 컨테이너를 포함하여 470 MB를 기록했습니다. 이 수치들은 사용자 수, 첨부 파일, 동기화 트래픽에 따라 변하며 MSSQL은 실행 시간이 길어질수록 작업 세트(working set)가 커지므로, 수치를 신뢰하기 전에 본인의 서버에서 직접 동일한 명령을 실행해 보시기 바랍니다.

소규모 VPS를 위한 실질적인 가이드는 다음과 같습니다. Vaultwarden과 SQLite 조합은 1 GB 플랜에서도 원활하게 작동하지만, 표준 Bitwarden 스택은 해당 사양에서 시작조차 하지 않습니다. 2 GB 플랜의 경우 표준 스택이 문서화된 최소 사양을 충족하기는 하나 운영체제가 사용할 자원이 거의 남지 않아, 커널의 OOM(Out of Memory) killer가 작동하는 상황이 발생합니다. OOM killer가 작동하면 dmesg는 종료시킨 프로세스 이름을 출력하며, 이 스택에서는 보통 sqlservr가 해당됩니다. 표준 배포판에는 4 GB를 할당하십시오. 만약 동일한 VPS에서 볼트 외의 다른 서비스도 운영할 계획이라면, PhotoPrism이나 Immich와 같은 사진 서버는 Vaultwarden보다 훨씬 많은 메모리를 필요로 하므로 플랜을 선택하기 전에 다른 서비스들의 최소 요구 사양을 먼저 계산해야 합니다. 물론 모든 서비스가 메모리를 많이 점유하는 것은 아닙니다. 예를 들어 Jellyfin 라이브러리를 90년대 대여점 스타일로 재구성하는 Halcyon은 자체 데이터베이스를 구축하는 대신 연결된 미디어 서버에 의존하는 브라우저 프론트엔드입니다. 메모리만이 유일한 확인 대상은 아닙니다. 원격 데스크톱 세션을 위한 RustDesk 릴레이는 docker stats에서 거의 자원을 점유하지 않는 대신 플랜의 대역폭 허용량을 소모하기 때문입니다.

Vaultwarden에서 무료로 제공되는 유료 기능은 무엇입니까?

Bitwarden 서버를 운영하는 것 자체는 비용이 들지 않지만, 라이선스 파일을 업로드하기 전까지는 유료 기능이 잠겨 있습니다. 개별 프리미엄 계정과 자체 호스팅이 가능한 유료 조직 플랜인 Families 및 Enterprise(Bitwarden은 Teams 플랜에 대해 자체 호스팅 옵션을 제공하지 않음)는 라이선스가 필요합니다. 라이선스는 클라우드 웹 볼트의 설정(Settings) 내 구독(Subscription) 메뉴(개인 계정) 또는 관리자 콘솔(Admin Console)의 결제(Billing) 내 구독(Subscription) 메뉴(조직 계정)에서 다운로드하여 자신의 인스턴스에 업로드합니다. 조직 라이선스는 ./bwdata/env/global.override.env에 저장된 설치 ID를 기준으로 발급됩니다. 따라서 자체 호스팅 조직이라 하더라도 유료 구독 상태를 유지해야 하며, 결제를 위해 Bitwarden 클라우드와 통신해야 합니다.

Vaultwarden은 라이선스나 구독 없이도 동일한 기능을 활성화합니다. 프로젝트 위키에 나열된 기능은 다음과 같습니다.

• 조직, 컬렉션 및 그룹
• 파일 첨부
• 이메일, Duo, YubiKey 및 FIDO2를 이용한 2단계 로그인
• 긴급 접근(Emergency Access)
• Bitwarden Send
• 개인 API 키
• OpenID Connect를 통한 SSO

SSO는 이 중 가장 최근에 추가된 기능이며 SSO_ENABLED, SSO_AUTHORITY, SSO_CLIENT_ID 및 SSO_CLIENT_SECRET를 사용하여 구성합니다. SSO는 로그인 인증만 수행합니다. 위키에서는 마스터 비밀번호가 여전히 필요하며, 이 비밀번호는 볼트를 복호화하는 키를 생성하는 데 사용되므로 ID 공급자가 제어할 수 없음을 명시하고 있습니다. SSO_AUTHORITY을 자체 호스팅 Authentik ID 공급자의 디스커버리 발급자(discovery issuer)로 지정하면 사용자가 해당 공급자에서 로그인한 뒤 마스터 비밀번호로 볼트를 잠금 해제합니다. 이 값은 디스커버리 엔드포인트가 반환하는 issuer 필드와 일치해야 하며, 끝에 /.well-known/openid-configuration 접미사가 포함되어서는 안 됩니다.

Vaultwarden을 사용할 때 얻을 수 없는 것은 공식 벤더 지원입니다. Bitwarden은 SOC 2 Type 2 및 ISO 27001 인증을 보유하고 있으며, 제3자 감사 보고서를 공개하고 비공개 HackerOne 버그 바운티 프로그램을 운영합니다. 이는 사용자가 설치한 서버가 아닌 Bitwarden의 코드와 서비스에 대한 것이지만, 감사인이 비밀번호 관리자의 배후에 명시된 공급자를 요구할 경우 자원봉사자가 재구현한 소프트웨어에 대해 설명하기는 어렵습니다.

공식 Bitwarden 앱이 Vaultwarden과 호환됩니까?

네, 호환됩니다. Vaultwarden은 클라이언트 API를 구현하므로 브라우저 확장 프로그램, 데스크톱 앱, 모바일 앱 및 번들로 제공되는 웹 볼트 모두 정상적으로 작동합니다. 각 클라이언트에서 로그인하기 전에 환경 설정 화면에서 직접 호스팅하는 서버 URL을 설정해야 합니다. 로그인 후에는 설정할 수 없습니다.

푸시 알림 기능은 모바일 앱에서 사용하기 위해 추가 설정이 필요합니다. 이 설정을 하지 않으면 앱을 열거나 자체 타이머가 작동할 때만 동기화되므로, 노트북에서 변경한 비밀번호가 휴대폰에 즉시 나타나지 않습니다. 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 설정도 필요합니다. 위키에는 디버깅에 시간을 낭비하기 전에 알아두어야 할 두 가지 주의 사항이 문서화되어 있습니다. F-Droid나 Neo Store에서 설치한 앱은 Firebase를 지원하지 않으므로 서버 설정과 관계없이 푸시 알림을 받을 수 없습니다. Vaultwarden 1.30.2 이전 버전에서 연결했던 앱은 푸시 토큰을 새로 등록하기 위해 앱 데이터를 삭제해야 합니다.

재구현은 얼마나 안전한가?

Bitwarden은 오랜 기간 공개된 감사 이력을 보유하고 있습니다. Cure53은 2018년, 2021년, 2022년, 2023년, 2024년, 2025년에 걸쳐 감사를 수행했으며, 2025년에는 브라우저 확장 프로그램 및 자동 완성 오버레이, 핵심 애플리케이션, 데스크톱 애플리케이션, 웹 볼트, RustCrypto 크레이트 및 라이브러리를 검토했습니다. IOActive와 Mandiant는 2024년에 클라이언트를 검토했고, Fracture Labs는 2024년부터 2025년까지 웹 및 네트워크 평가를 수행했으며, Unit 42는 2025년에 모바일 앱을, ETH Zurich Applied Cryptography Group은 2025년에 암호화 방식을 검토했습니다.

Vaultwarden 또한 외부 전문가들의 검토를 거쳤으며, 이는 아무도 살펴보지 않을 것이라 예상하는 사람들에게 놀라움을 줍니다. 독일 연방 정보 보안청(BSI)은 Caos 3.0 코드 분석 프로젝트의 일환으로 2024년 2월부터 5월까지 mgm security partners를 통해 테스트를 진행했으며, 해당 검토에서 두 가지 항목이 높은 위험 등급으로 분류되었습니다. 별도로 ERNW는 1.32.5 미만 버전에서 발생하는 인증 우회 취약점(CVE-2024-55225)을 보고했으며, 이는 2024년 11월에 수정되었습니다. 2026년 7월에 릴리스된 1.37.0 버전에서는 아이콘 엔드포인트를 통한 SSRF(서버 측 요청 위조), 조직 간 암호 접근, 디렉터리 가져오기 시 조직 정책 우회 문제에 대한 수정 사항이 포함되었습니다. 2026년 10월의 1.37.4 버전에서는 조직 구성원 권한 취소와 관련된 높은 등급의 결함을 비롯하여 2단계 인증, 조직 초대, 첨부 파일 관련 문제 등 일련의 취약점이 수정되었습니다.

이러한 이력은 해당 프로젝트가 정상적인 보안 공개 절차를 갖추고 있음을 보여줍니다. 또한 관리자 페이지와 같이 지속적으로 문제가 발생하는 공격 표면을 지적하기도 합니다. 따라서 해당 페이지는 민감한 영역으로 간주해야 합니다. ADMIN_TOKEN이 설정되지 않은 경우 관리자 페이지는 비활성화 상태로 유지되며, 일반 텍스트 토큰 대신 해시값을 저장해야 합니다.

docker run --rm -it vaultwarden/server /vaultwarden hash

이 명령은 ADMIN_TOKEN에 붙여넣을 Argon2 PHC 문자열(비밀번호 해싱 경쟁 형식)을 출력합니다. 토큰이 요청에 포함되어 전송되므로, 일반 HTTP 연결에서 평문 토큰을 사용하면 경로상의 모든 주체가 이를 읽을 수 있습니다. 따라서 관리자 페이지를 활성화하기 전에 반드시 HTTPS를 먼저 활성화하십시오. 실질적인 위험은 암호화 자체보다는 해당 토큰과 백업 파일에 존재하며, 실행 중인 인스턴스에 대한 보안 강화를 통해 이 두 가지 위험을 모두 관리할 수 있습니다. 가능한 한 /admin은 공용 인터넷에 노출하지 말고, 서버의 SSH 접근 제한과 같은 일반적인 호스트 보안 강화 조치를 병행하십시오.

공식 API가 변경될 때 발생하는 문제

이 위험은 과소평가되기 쉽다. Bitwarden이 client를 제공하고, client는 밤사이 app store에서 자동으로 업데이트된다. Vaultwarden은 이 변경을 따라가야 한다. client release에서 API contract가 변경되면, 아직 업그레이드하지 않은 Vaultwarden이 이미 변경된 client와 통신하게 된다. 그러면 직접 조작하지 않은 device에서 login이나 sync가 실패하기 시작한다.

release notes에는 구체적인 사례가 있다. Vaultwarden 1.37.0에는 다음과 같이 적혀 있다. "This update is required for support with clients with version 2026.7.0+, please update before reporting any issues with them." 한 달 후 2026년 8월 22일에 publish된 1.37.2도 2026.8.0 이상 client에 대해 같은 경고를 반복했다. 따라서 1.37.0 또는 1.37.1에 머물러 있는 server는 이미 app보다 뒤처진 상태다. 2026년 10월 27일 기준 current release는 1.37.4다. 2026년 10월 5일에 publish되었으며, 그 전에는 2026년 9월 13일에 1.37.3이 publish되었다.

다음 2가지 습관을 지키면 관리가 단순해진다. latest 대신 특정 image tag를 고정한다. 그러면 unattended pull이 새벽 3시에 server를 예기치 않게 변경하지 못한다. 그런 다음 release feed를 확인하고, notes를 먼저 읽은 뒤 계획적으로 업그레이드한다. breaking change는 release notes에 공지되기 때문이다. 1.37.2의 경고는 project의 GitHub Discussions에도 게시되었다. server를 업그레이드한 뒤에도 문제가 계속되는 client의 복구 절차도 함께 안내되었다. 먼저 logout한 뒤 다시 login하고, app 또는 extension cache를 지운다. mobile app 또는 extension 재설치는 마지막 수단으로만 사용한다. 예를 들어 Version 1.35.5는 업그레이드 시 기존의 two factor remember token을 모두 무효화했다. 그 결과 사용자가 저장해 두었다고 생각한 단계에서 logout되었다.

표준 Bitwarden 배포에는 정반대의 문제가 있다. 업그레이드는 ./bitwarden.sh updateself 및 ./bitwarden.sh update을 통해 실행되며, update 과정에서 database migration이 적용된다. migration 전에 만든 backup은 migration 이후 schema에 대한 rollback 수단이 아니다. 따라서 backup을 만들고 생성 당시의 version을 기록해야 한다.

백업, 사용자가 실제로 볼트를 잃어버리는 지점

Vaultwarden의 데이터 디렉터리가 곧 서버 그 자체입니다. 다음 항목을 보관하십시오.

• db.sqlite3
• rsa_key.pem 및 rsa_key.der를 포함한 모든 rsa_key* 파일
• attachments/
• config.json
• sends/

컨테이너가 실행 중일 때 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 유닛에 연결된 자가 호스팅 ntfy 서버를 사용할 수 있습니다. rsa_key 파일은 데이터베이스만큼 중요합니다. 서버는 해당 키로 세션 토큰에 서명하므로, 새로 생성된 키와 함께 데이터베이스를 복구하면 모든 사용자의 로그아웃이 발생하고 진행 중이던 조직 초대 기능이 작동하지 않게 됩니다.

Bitwarden 표준 버전은 더 많은 데이터를 백업합니다. 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 라이트 버전은 자동 백업을 제공하지 않으므로, 라이트 버전을 선택했다면 Vaultwarden과 마찬가지로 직접 덤프 일정을 관리해야 합니다.

양방향 마이그레이션

내보내기와 가져오기는 클라이언트 기능이므로 마이그레이션은 서버가 아닌 클라이언트를 통해 수행됩니다. 따라서 양방향 모두 동일한 절차를 따릅니다.

각 사용자는 웹 볼트나 데스크톱 앱에서 데이터를 내보낸 뒤, 새 서버에 계정을 생성하고 가져오기를 진행합니다. 지원되는 형식은 일반 텍스트 .json, 일반 텍스트 .csv, 암호화된 .json, 그리고 개별 볼트의 JSON과 파일 첨부 항목을 포함하는 .zip입니다. 카드, 신원 정보, 저장된 패스키, SSH 키는 JSON 형식으로만 유지되므로 CSV 마이그레이션 시에는 해당 데이터가 누락됩니다. 어떤 내보내기 형식도 휴지통 항목이나 Sends 데이터를 포함하지 않으며, 조직 소유 데이터는 개인 내보내기에 포함되지 않습니다.

일반 텍스트 내보내기 파일은 그 자체로 전체 볼트가 평문으로 디스크에 저장된 상태이므로, 살아있는 비밀 정보로 취급해야 합니다. 내보내기, 가져오기, 삭제 과정을 한 번에 완료하십시오. 이메일이나 채팅을 통해 파일을 전송해서는 안 됩니다.

마이그레이션 도중 흔히 발생하는 실수가 있습니다. 계정에 귀속된 암호화된 내보내기 파일은 다른 계정으로 가져올 수 없으며, 서버를 옮기는 것은 정의상 다른 계정을 사용하는 것을 의미합니다. 대신 이식성이 있는 암호 보호 내보내기 옵션을 선택하십시오.

Vaultwarden에서 Bitwarden 표준으로 이전하는 것이 더 까다로운데, 이는 내보내기 파일에 조직 구조가 포함되지 않기 때문입니다. 새 서버에서 조직을 다시 생성하고 사용자를 다시 초대해야 하며, 각 사용자가 자신의 볼트를 직접 가져와야 합니다. 당일에 문제를 발견하기보다 미리 유지보수 시간을 계획하십시오.

어떤 것을 실행해야 할까요?

1 GB 또는 2 GB VPS를 사용하는 개인, 가족, 또는 홈랩 환경이라면 Vaultwarden을 실행하십시오. Organisations, Emergency Access, Send 기능을 무료로 사용할 수 있으며, 유휴 메모리 점유율은 브라우저 탭 하나 정도에 불과합니다. 백업은 SQLite 파일 하나와 작은 디렉터리 하나면 충분합니다. 이러한 장점 덕분에 Vaultwarden은 셀프 호스팅 비밀번호 관리 분야에서 압도적인 점유율을 차지하고 있습니다.

전문적인 환경에서 다른 사람들이 해당 서비스를 이용해야 한다면 Bitwarden 공식 서버를 실행하십시오. 기술 지원 계약이 필요한 기업, 특정 벤더를 명시해야 하는 규정 준수 요구 사항이 있거나, 이미 비용을 지불하고 있는 엔터프라이즈 기능이 필요한 경우가 이에 해당합니다. 표준 배포 환경에는 4 GB의 메모리를 할당하고, 라이선스 파일과 installation ID는 단순한 서류가 아닌 배포의 필수 구성 요소로 취급하십시오.

Bitwarden lite는 다소 애매한 위치에 있습니다. 벤더의 코드를 사용하면서도 가볍다는 점은 분명 매력적이지만, Bitwarden 측에서는 이를 개인 및 홈랩 용도로 명시하고 있으며 자동 백업 기능을 제공하지 않습니다. 즉, Vaultwarden의 무료 기능 세트는 누리지 못하면서 운영 부담은 그대로 떠안게 됩니다. 기능보다 벤더의 코드가 더 중요하고, 데이터베이스를 직접 운영하는 데 문제가 없다면 이 선택지를 고려하십시오.

서버에서 무엇을 더 운영할지 결정 중이라면, 더 넓은 범위의 셀프 호스팅 목록에서 동일한 RAM 자원을 두고 경쟁하는 다른 서비스들과 이 선택지를 비교해 볼 수 있습니다.

FAQ

Vaultwarden은 실제 비밀번호 관리자로 사용하기에 충분히 안전합니까?

개인 및 가족용으로는 조건부로 안전합니다. 클라이언트가 서버에 도달하기 전에 볼트를 암호화하므로, Vaultwarden은 마스터 비밀번호나 평문 데이터를 전혀 볼 수 없습니다. 외부 보안 검토도 거쳤습니다. BSI는 2024년 2월부터 5월까지 mgm security partners를 통해 테스트를 진행했으며, ERNW는 1.32.5 버전에서 수정된 인증 우회 취약점을 보고한 바 있습니다. 항상 최신 버전을 유지하고, 관리자 페이지는 비활성화하거나 Argon2로 해시된 ADMIN_TOKEN 뒤에 배치하며, 반드시 HTTPS를 통해서만 서비스하십시오. 벤더 지원이나 감사 문서가 필요한 기업 환경이라면 Bitwarden에서 제공하는 공식 서버를 운영해야 합니다.

Vaultwarden은 Bitwarden 자체 호스팅과 비교하여 RAM을 얼마나 사용합니까?

docker stats --no-stream로 측정한 유휴 상태의 설치 환경에서, SQLite를 사용하는 Vaultwarden은 컨테이너 하나당 약 58 MB를 점유했습니다. 반면 Bitwarden 표준 배포판은 12개의 컨테이너에 걸쳐 약 2,400 MB를 점유했으며, 이 중 대부분은 MSSQL 데이터베이스가 차지했습니다. Bitwarden은 표준 스택의 최소 사양으로 2 GB, 권장 사양으로 4 GB를 명시하고 있으며, Bitwarden lite의 경우 200 MB를 요구합니다. Vaultwarden은 1 GB VPS에서도 여유 있게 구동됩니다.

자체 호스팅을 하려면 Bitwarden 라이선스가 필요합니까?

무료 개인 볼트 사용 시에는 필요하지 않습니다. 서버 운영 자체는 무료입니다. 프리미엄 개인 기능이나 유료 조직 플랜을 잠금 해제하려면 라이선스 파일이 필요하며, Bitwarden이 자체 호스팅을 허용하는 조직 플랜은 Families와 Enterprise뿐입니다. 클라우드 웹 볼트에서 라이선스를 다운로드하여 자신의 인스턴스에 업로드하면 되며, 조직 라이선스는 ./bwdata/env/global.override.env에 저장된 설치 ID를 기준으로 발급됩니다. Vaultwarden은 별도의 라이선스가 필요 없으며 조직 기능을 자체적으로 활성화합니다.

나중에 Vaultwarden에서 Bitwarden으로, 혹은 그 반대로 이동할 수 있습니까?

네, 클라이언트를 통해 양방향 모두 가능합니다. 각 사용자는 웹 볼트나 데스크톱 앱에서 볼트를 내보낸(export) 뒤, 새 서버에 계정을 생성하고 가져오기(import)를 수행하면 됩니다. .zip 내보내기 형식은 개인 볼트의 첨부 파일을 포함하며, JSON 형식은 카드, 신원 정보, 패스키, SSH 키를 포함합니다. 휴지통 항목과 공유 항목(Sends)은 내보내기 형식에 포함되지 않으며, 조직 소유 항목은 소유자가 별도로 내보내야 합니다. 따라서 새 서버에서 조직을 다시 구성하고 사용자를 재초대할 계획을 세워야 합니다.