Vaultwarden czy Bitwarden self-hosted: co wybrać?

Czym w rzeczywistości są Vaultwarden i Bitwarden self-hosted

Wybór między Vaultwarden a Bitwarden self-hosted to wybór między dwoma serwerami obsługującymi to samo API klienckie, a nie między dwoma różnymi menedżerami haseł. Oficjalny stos technologiczny Bitwarden uruchamia około tuzina kontenerów za Nginx, przechowuje dane w Microsoft SQL Server i jest powiązany z identyfikatorem instalacji rejestrowanym za pomocą adresu e-mail. Vaultwarden to nieoficjalna reimplementacja API klienta Bitwarden, napisana w Rust, która działa jako pojedynczy kontener korzystający z jednego pliku SQLite. Rozszerzenie przeglądarki oraz aplikacja mobilna nie rozróżniają tych rozwiązań, ponieważ oba odpowiadają na te same punkty końcowe.

Szyfrowanie jest identyczne w obu przypadkach. Klienci Bitwarden szyfrują bazę haseł, zanim jakiekolwiek dane opuszczą urządzenie, więc serwer przechowuje jedynie obiekty typu blob, których nie może odczytać. Format bazy haseł w obu przypadkach należy do Bitwarden. Różnice dotyczą zasobów sprzętowych, podmiotu utrzymującego kod, płatnych funkcji oraz procedur tworzenia kopii zapasowych.

Plik README projektu Vaultwarden jasno określa jego status: "Ten projekt nie jest powiązany z Bitwarden ani Bitwarden, Inc.". Jest to projekt wolontariacki, pozbawiony wsparcia technicznego i gwarancji. Jeden z aktywnych opiekunów projektu pracuje w Bitwarden i wnosi wkład w ramach czasu prywatnego, co stanowi wyraz dobrej woli, a nie oficjalne poparcie.

Trzy stosy, które można zainstalować

Większość porównań pomija fakt, że Bitwarden oferuje dwa różne produkty do samodzielnego hostowania.

Bitwarden standard. Wdrożenie dostawcy, sterowane skryptem powłoki.

curl -Lso bitwarden.sh "https://func.bitwarden.com/api/dl/?app=self-host&platform=linux" \
  && chmod 700 bitwarden.sh
./bitwarden.sh install

Instalator pyta o domenę, chęć uzyskania certyfikatu Let's Encrypt, nazwę bazy danych oraz identyfikator i klucz instalacji, które pobiera się z https://bitwarden.com/host po podaniu adresu e-mail. ./bitwarden.sh start następnie pobiera obrazy i uruchamia stos. Bitwarden określa 2 GB pamięci RAM i 12 GB miejsca na dysku jako minimum, a 4 GB i 25 GB jako zalecane parametry, przy użyciu Docker Engine 26 lub nowszego z wtyczką Compose. Bazą danych jest obraz MSSQL Express, a ta edycja ogranicza relacyjną bazę danych do 10 GB, chyba że wdrożenie zostanie skierowane na zewnętrzną bazę danych.

Bitwarden lite. Jest to wdrożenie, które wcześniej nazywało się Bitwarden Unified. Wyszło z fazy beta i zostało przemianowane w grudniu 2025. Jeden kontener aplikacji oraz wybrana baza danych:

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:

Obsługuje MariaDB lub MySQL, PostgreSQL, SQLite oraz MSSQL i wymaga 200 MB pamięci RAM oraz 1 GB miejsca na dysku. Dokumentacja Bitwarden wskazuje na dwa ograniczenia. Wdrożenie jest przeznaczone do użytku osobistego i domowych laboratoriów, a nie do zastosowań biznesowych, ponadto nie wykonuje automatycznych kopii zapasowych bazy danych, więc to zadanie spoczywa w całości na użytkowniku.

Vaultwarden. Jeden kontener, zgodnie z plikiem README projektu:

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

Linia publish wiąże port 8000 wyłącznie z interfejsem zwrotnym (loopback) i jest to działanie celowe. Vaultwarden obsługuje zwykły protokół HTTP i wymaga, aby przed nim znajdował się reverse proxy realizujący terminację TLS (transport layer security). TLS nie jest tutaj opcjonalny: sejf internetowy wykonuje szyfrowanie za pomocą interfejsu WebCrypto API przeglądarki, który przeglądarki udostępniają tylko w bezpiecznym kontekście, więc przez zwykłe http strona logowania nie załaduje się w przeglądarce, zanim serwer otrzyma jakiekolwiek zapytanie. Pełny przewodnik instalacji Vaultwarden omawia konfigurację proxy oraz certyfikatu.

Ile pamięci RAM zużywa Vaultwarden w porównaniu do samodzielnie hostowanego Bitwarden?

Minimalne wymagania producenta określają warunki, w których instalator odmawia uruchomienia, a nie rzeczywiste zapotrzebowanie oprogramowania na zasoby. Poniższe dane pochodzą z docker stats --no-stream dla instalacji w stanie spoczynku, z jednym użytkownikiem, małym sejfem i bez załączników, na systemie Ubuntu 24.04 z 4 GB pamięci RAM. Dane dotyczące dysku obejmują obrazy oraz katalog danych po pierwszym poprawnym uruchomieniu.

[
  {
    "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 w pojedynczym kontenerze zużywał w stanie spoczynku 58 MB. Standardowy stos Bitwarden zużywał w stanie spoczynku około 2,400 MB w ramach 12 kontenerów, przy czym większość tego zasobu zajmuje kontener MSSQL. Wersja Bitwarden lite plasuje się pomiędzy nimi z wynikiem 470 MB wraz z kontenerem MariaDB. Przed zaufaniem tym wartościom należy uruchomić to samo polecenie na własnym serwerze, ponieważ zużycie zmienia się wraz z liczbą użytkowników, załącznikami i ruchem synchronizacyjnym, a MSSQL zwiększa swój zestaw roboczy wraz z czasem działania.

Praktyczne wnioski dla małego VPS: Vaultwarden z SQLite działa stabilnie w planie 1 GB, podczas gdy standardowy stos Bitwarden w takich warunkach się nie uruchomi. W planie 2 GB standardowy stos spełnia udokumentowane minimum, pozostawiając bardzo niewiele zasobów dla systemu operacyjnego, co sprawia, że mechanizm OOM (out of memory) killer staje się realnym zagrożeniem. Gdy zostanie on wywołany, dmesg wyświetli wiersz z nazwą procesu, który został zakończony; w przypadku tego stosu jest to zazwyczaj sqlservr. Dla standardowego wdrożenia należy zapewnić 4 GB pamięci RAM.

Które płatne funkcje są darmowe w Vaultwarden?

Uruchomienie serwera Bitwarden nic nie kosztuje, jednak płatne funkcje pozostają zablokowane do momentu wgrania pliku licencji. Wymagają jej konta Premium dla użytkowników indywidualnych oraz każdy płatny plan organizacji (Families, Teams, Enterprise). Licencję pobiera się z chmurowego web vault, w sekcji Settings, a następnie Subscription dla użytkownika indywidualnego, lub z Admin Console w sekcji Billing, a następnie Subscription dla organizacji, a następnie wgrywa na własną instancję. Licencje organizacji są wystawiane dla identyfikatora instalacji przechowywanego w ./bwdata/env/global.override.env. Organizacja hostowana samodzielnie nadal posiada więc płatną subskrypcję i nadal łączy się z chmurą Bitwarden w celu rozliczeń.

Vaultwarden odblokowuje te same funkcje bez licencji i bez subskrypcji. Wiki projektu wymienia je poniżej:

• organizacje, kolekcje i grupy
• załączniki plików
• logowanie dwuetapowe przez email, Duo, YubiKey oraz FIDO2
• Emergency Access
• Bitwarden Send
• osobiste klucze API
• SSO przez OpenID Connect

SSO jest najnowszą z tych funkcji i konfiguruje się ją za pomocą SSO_ENABLED, SSO_AUTHORITY, SSO_CLIENT_ID oraz SSO_CLIENT_SECRET. Uwierzytelnia ona wyłącznie proces logowania. Wiki wyraźnie zaznacza, że hasło główne jest nadal wymagane i nie jest kontrolowane przez dostawcę tożsamości, ponieważ to hasło wyprowadza klucz, który odszyfrowuje sejf. Należy wskazać SSO_AUTHORITY na punkt końcowy discovery samodzielnie hostowanego dostawcy tożsamości Authentik, gdzie użytkownicy się logują, a następnie odblokowują sejf hasłem głównym. Wartość musi być zgodna z polem issuer, które zwraca punkt końcowy discovery, bez przyrostka /.well-known/openid-configuration na końcu.

Tym, czego nie otrzymuje się w Vaultwarden, jest wsparcie dostawcy. Bitwarden posiada certyfikaty SOC 2 Type 2 oraz ISO 27001, publikuje raporty z audytów zewnętrznych i prowadzi prywatny program bug bounty w serwisie HackerOne. Obejmują one kod i usługę Bitwarden, a nie serwer, który został zainstalowany. Jeśli audytor wymaga wskazania konkretnego dostawcy stojącego za menedżerem haseł, dobrowolna reimplementacja oprogramowania może być trudnym tematem do wyjaśnienia.

Czy oficjalne aplikacje Bitwarden współpracują z Vaultwarden?

Tak. Vaultwarden implementuje API klienta, więc rozszerzenia przeglądarkowe, aplikacje desktopowe, aplikacje mobilne oraz wbudowany web vault działają z tym oprogramowaniem. W każdym kliencie adres URL serwera self-hosted należy ustawić na ekranie środowiska przed zalogowaniem, a nie po nim.

Jedna funkcja wymaga dodatkowej konfiguracji: powiadomienia push dla aplikacji mobilnych. Bez nich aplikacja synchronizuje się w momencie otwarcia lub zgodnie z własnym harmonogramem, więc hasło zmienione na laptopie nie pojawi się na telefonie, dopóki go nie sprawdzisz. Vaultwarden może korzystać z przekaźnika push Bitwarden, co wymaga identyfikatora instalacji (installation ID) oraz klucza z tej samej strony https://bitwarden.com/host, z której korzysta oficjalny instalator.

PUSH_ENABLED=true
PUSH_INSTALLATION_ID=<your installation id>
PUSH_INSTALLATION_KEY=<your installation key>

Serwery w regionie EU wymagają również PUSH_RELAY_URI=https://api.bitwarden.eu oraz PUSH_IDENTITY_URI=https://identity.bitwarden.eu. Wiki dokumentuje dwie pułapki, o których warto wiedzieć, zanim poświęcisz godzinę na debugowanie tego problemu. Aplikacja zainstalowana z F-Droid lub Neo Store nie posiada wsparcia dla Firebase i nigdy nie otrzyma powiadomienia push, niezależnie od działań serwera. W przypadku aplikacji, która łączyła się przed wersją Vaultwarden 1.30.2, należy wyczyścić dane, aby zarejestrować token push.

Jak bezpieczna jest reimplementacja?

Historia audytów Bitwarden jest długa i publicznie dostępna. Firma Cure53 przeprowadziła przeglądy w latach 2018, 2021, 2022 oraz 2023. IOActive i Mandiant sprawdziły klientów w 2024 roku, Fracture Labs przeprowadziło testy sieciowe i aplikacji webowych w latach 2024 i 2025, Unit 42 oceniło aplikacje mobilne w 2025 roku, a grupa Applied Cryptography Group z ETH Zurich dokonała przeglądu kryptografii w 2025 roku.

Vaultwarden również był badany przez podmioty zewnętrzne, co zaskakuje osoby zakładające brak zainteresowania projektem. Niemiecki Federalny Urząd ds. Bezpieczeństwa Informacji (BSI) zlecił firmie mgm security partners testy w okresie od lutego do maja 2024 roku w ramach projektu analizy kodu Caos 3.0; przegląd ten ocenił dwa znaleziska jako krytyczne. Niezależnie od tego, firma ERNW zgłosiła obejście uwierzytelniania wpływające na wersje poniżej 1.32.5 (CVE-2024-55225), co zostało naprawione w listopadzie 2024 roku. Wersja 1.37.0, wydana w lipcu 2026 roku, zawierała poprawki dla podatności SSRF (server side request forgery) w punkcie końcowym ikon, nieuprawnionego dostępu do szyfrów między organizacjami oraz obejścia polityki organizacji przy importach z katalogów.

Ta historia wskazuje na projekt z działającym procesem ujawniania podatności. Wskazuje również na obszar, w którym stale pojawiają się problemy: stronę administracyjną. Należy traktować tę stronę jako element o wysokim stopniu wrażliwości. Pozostaje ona wyłączona, dopóki nie zostanie ustawiona zmienna ADMIN_TOKEN, a w konfiguracji należy przechowywać skrót (hash), a nie token w postaci jawnej.

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

Powyższe polecenie generuje ciąg Argon2 PHC (format password hashing competition), który należy wkleić do ADMIN_TOKEN. Przed włączeniem strony administracyjnej należy skonfigurować HTTPS, ponieważ token jest przesyłany w żądaniu, a token w postaci jawnej przesyłany przez nieszyfrowane połączenie HTTP może zostać odczytany przez dowolny węzeł na ścieżce sieciowej. Należy ograniczyć dostęp do /admin z publicznego Internetu, jeśli to możliwe, oraz połączyć to ze standardowym utwardzaniem hosta, takim jak ograniczenie dostępu SSH do serwera.

Co ulega awarii przy zmianach oficjalnego API

To ryzyko jest często niedoceniane. Bitwarden wydaje klientów, którzy aktualizują się automatycznie ze sklepów z aplikacjami w nocy. Vaultwarden musi nadążać za tymi zmianami. Gdy nowa wersja klienta zmienia kontrakt API, nieaktualny Vaultwarden napotyka klienta, który już przeszedł na nową wersję. W efekcie logowanie lub synchronizacja przestają działać na urządzeniach, których użytkownik nawet nie dotykał.

Informacje o wydaniu zawierają konkretny przykład. Vaultwarden 1.37.0 podaje: "Ta aktualizacja jest wymagana do obsługi klientów w wersji 2026.7.0+, prosimy o aktualizację przed zgłaszaniem jakichkolwiek problemów z nimi". Według stanu na sierpień 2026 bieżące wydanie to 1.37.1, opublikowane 29 lipca 2026.

Dwa nawyki pozwalają uniknąć problemów. Przypnij konkretny tag obrazu zamiast latest, aby automatyczne pobieranie nie zaktualizowało serwera o 3 nad ranem. Następnie monitoruj kanał wydań i aktualizuj oprogramowanie świadomie, najpierw czytając informacje o zmianach, ponieważ to tam, i tylko tam, pojawiają się informacje o zmianach powodujących awarie. Wersja 1.35.5 na przykład unieważniła wszystkie istniejące tokeny zapamiętywania drugiego składnika uwierzytelniania podczas aktualizacji, co wylogowało użytkowników z etapu, który według nich był zapisany.

Standardowe wdrożenie Bitwarden ma lustrzane odbicie tego problemu. Aktualizacje przebiegają przez ./bitwarden.sh updateself oraz ./bitwarden.sh update, a proces stosuje migracje bazy danych. Kopia zapasowa wykonana przed migracją nie stanowi punktu przywracania dla schematu po jej zakończeniu, dlatego wykonaj kopię i zanotuj wersję, przy której została ona utworzona.

Kopie zapasowe, czyli miejsce, w którym użytkownicy faktycznie tracą swoje sejfy

Katalog danych Vaultwarden stanowi serwer. Należy zachować następujące elementy:

• db.sqlite3
• każdy plik rsa_key*, w tym rsa_key.pem oraz rsa_key.der
• attachments/
• config.json
• sends/

Nie należy kopiować db.sqlite3 za pomocą cp podczas działania kontenera. SQLite może być w trakcie zapisu, więc kopia może zawierać uszkodzoną bazę danych, która wygląda na poprawną aż do momentu przywracania. Zamiast tego należy użyć interfejsu API do kopii zapasowych online:

sqlite3 data/db.sqlite3 ".backup '/path/to/backups/db-$(date '+%Y%m%d-%H%M').sqlite3'"

Od wersji 1.32.1 w obrazie dostępna jest również wbudowana komenda /vaultwarden backup. W obu przypadkach migawka nadal znajduje się na tym samym dysku co oryginał, dopóki nie zostanie przeniesiona, dlatego należy ją wysyłać poza serwer za pomocą migawki restic do pamięci zewnętrznej zgodnie z harmonogramem. Pliki rsa_key są równie ważne co baza danych: serwer podpisuje nimi swoje tokeny sesji, więc baza danych przywrócona obok nowo wygenerowanego klucza wyloguje wszystkich użytkowników i unieważni oczekujące zaproszenia do organizacji.

Standardowa wersja Bitwarden wykonuje więcej kopii zapasowych we własnym zakresie. Kontener mssql zapisuje nocne kopie bazy danych w ./bwdata/mssql/backups i przechowuje je przez 30 dni, o ile kontener jest uruchomiony; można również wymusić wykonanie kopii:

docker exec -i bitwarden-mssql /backup-db.sh

Katalogi, które należy zachować, to ./bwdata/env (zmienne środowiskowe, w tym hasła do bazy danych i certyfikatów), ./bwdata/core/attachments, ./bwdata/mssql/data oraz ./bwdata/core/aspnet-dataprotection. Ten ostatni jest najczęściej pomijany. Przechowuje on dane ochrony na poziomie frameworka, w tym tokeny uwierzytelniające i niektóre kolumny bazy danych, więc przywrócenie bazy danych bez niego sprawia, że chronione przez niego kolumny stają się nieczytelne. Wersja Bitwarden lite nie wykonuje żadnych automatycznych kopii zapasowych, więc wybór wersji lite oznacza konieczność samodzielnego zaplanowania zrzutów danych, dokładnie tak jak w przypadku Vaultwarden.

Migracja w obu kierunkach

Migracja odbywa się za pośrednictwem klientów, a nie serwerów, ponieważ eksport i import są funkcjami klienckimi. Dzięki temu obie strony procesu przebiegają w ten sam sposób.

Każdy użytkownik wykonuje eksport z poziomu sejfu internetowego lub aplikacji desktopowej, tworzy konto na nowym serwerze i wykonuje import. Dostępne formaty to tekst jawny .json, tekst jawny .csv, format zaszyfrowany .json oraz .zip, który zawiera plik JSON wraz z załącznikami dla poszczególnych sejfów. Karty płatnicze, tożsamości, zapisane klucze dostępu (passkeys) oraz klucze SSH są zachowywane tylko w formatach JSON, dlatego migracja przez CSV powoduje ich bezpowrotną utratę. Żaden format eksportu nie obejmuje elementów w koszu ani funkcji Sends, a dane należące do organizacji nie są częścią eksportu indywidualnego.

Traktuj eksport w tekście jawnym jak aktywny sekret, ponieważ dokładnie tym jest: całym Twoim sejfem zapisanym w postaci czytelnej na dysku. Wykonaj eksport, zaimportuj dane i usuń plik w trakcie jednej sesji. Nigdy nie przesyłaj go pocztą elektroniczną ani komunikatorem.

Jedna pułapka często zaskakuje użytkowników w trakcie migracji. Eksport zaszyfrowany powiązany z Twoim kontem nie może zostać zaimportowany na inne konto, a zmiana serwera z definicji oznacza nowe konto. Wybierz opcję eksportu chronionego hasłem, która jest przenośna.

Przejście z Vaultwarden na standardowe Bitwarden jest trudniejszym kierunkiem, ponieważ struktura organizacji nie jest przenoszona w eksporcie. Należy odtworzyć organizację na nowym serwerze, ponownie zaprosić użytkowników, a każdy z nich musi samodzielnie zaimportować swój sejf. Zaplanuj na to okno serwisowe, zamiast odkrywać te wymagania w dniu migracji.

Które rozwiązanie wybrać?

Uruchom Vaultwarden, jeśli korzystasz z niego samodzielnie, w ramach rodziny lub w środowisku home lab na VPS z 1 GB lub 2 GB pamięci RAM. Funkcje Organisations, Emergency Access oraz Send są dostępne bezpłatnie, zużycie pamięci w stanie spoczynku odpowiada jednej karcie przeglądarki, a kopia zapasowa składa się z pliku SQLite oraz niewielkiego katalogu. To połączenie sprawia, że jest to dominujące rozwiązanie w kategorii samodzielnie hostowanych menedżerów haseł.

Uruchom serwer Bitwarden, gdy zależą od niego inne osoby w środowisku profesjonalnym: w firmie wymagającej wsparcia technicznego, przy wymogach zgodności wskazujących konkretnego dostawcę lub gdy korzystasz z płatnych funkcji enterprise. Standardowe wdrożenie wymaga 4 GB pamięci RAM, a plik licencji oraz installation ID należy traktować jako integralne elementy wdrożenia, a nie tylko dokumentację.

Bitwarden lite zajmuje niejednoznaczną pozycję pośrednią. Jest to kod dostawcy o znacznie mniejszym zapotrzebowaniu na zasoby, co jest atrakcyjne, jednak Bitwarden dokumentuje go jako rozwiązanie do użytku osobistego i w home labie, a ponadto nie posiada on automatycznych kopii zapasowych. Utrzymujesz obciążenie operacyjne typowe dla Vaultwarden, nie otrzymując w zamian jego bezpłatnego zestawu funkcji. Wybierz to rozwiązanie, jeśli kod dostawcy jest dla Ciebie ważniejszy niż funkcjonalność i akceptujesz samodzielne zarządzanie bazą danych.

Jeśli nadal zastanawiasz się, jakie inne usługi uruchomić na serwerze, szersza lista rekomendowanych rozwiązań self-hosting zestawia ten wybór z innymi usługami rywalizującymi o te same zasoby pamięci RAM.

FAQ

Czy Vaultwarden jest wystarczająco bezpieczny, aby pełnić rolę głównego menedżera haseł?

W zastosowaniach osobistych i rodzinnych tak, pod pewnymi warunkami. Klient szyfruje bazę haseł przed wysłaniem jej na serwer, więc Vaultwarden nigdy nie otrzymuje hasła głównego ani danych w postaci jawnej. Oprogramowanie przeszło audyty zewnętrzne: BSI zleciło firmie mgm security partners testy w okresie od lutego do maja 2024 roku, a ERNW wykryło błąd obejścia uwierzytelnienia, który został naprawiony w wersji 1.32.5. Należy dbać o aktualność wersji, wyłączyć stronę administracyjną lub zabezpieczyć ją hasłem z funkcją skrótu Argon2 ADMIN_TOKEN oraz udostępniać usługę wyłącznie przez HTTPS. Przedsiębiorstwa wymagające wsparcia producenta lub dokumentacji audytowej powinny korzystać z oficjalnego serwera Bitwarden.

Ile pamięci RAM zużywa Vaultwarden w porównaniu z samodzielnie hostowanym Bitwarden?

W stanie spoczynku, przy pomiarach wykonanych za pomocą docker stats --no-stream, Vaultwarden z bazą SQLite zajmował około 58 MB w jednym kontenerze, podczas gdy standardowe wdrożenie Bitwarden zużywało blisko 2,400 MB w ramach 12 kontenerów, z czego większość przypadała na bazę danych MSSQL. Bitwarden określa 2 GB jako minimum i 4 GB jako zalecaną ilość pamięci dla standardowego stosu, oraz 200 MB dla wersji Bitwarden lite. Vaultwarden działa na VPS z 1 GB pamięci RAM, pozostawiając wolne zasoby.

Czy do samodzielnego hostingu wymagana jest licencja Bitwarden?

Nie w przypadku darmowego konta indywidualnego. Uruchomienie serwera jest bezpłatne. Plik licencji jest wymagany do odblokowania funkcji premium dla użytkowników indywidualnych oraz płatnych planów organizacyjnych, takich jak Families, Teams i Enterprise. Licencję pobiera się z chmurowego web vault i wgrywa na własną instancję, a licencje organizacyjne są przypisywane do identyfikatora instalacji przechowywanego w ./bwdata/env/global.override.env. Vaultwarden nie wymaga licencji i automatycznie udostępnia funkcje organizacyjne.

Czy można później przenieść się z Vaultwarden na Bitwarden lub odwrotnie?

Tak, w obu kierunkach, za pośrednictwem aplikacji klienckich. Każdy użytkownik eksportuje swoją bazę haseł z web vault lub aplikacji desktopowej, a następnie importuje ją na nowy serwer po utworzeniu tam konta. Eksport w formacie .zip przenosi załączniki dla baz indywidualnych, a pliki JSON zawierają karty płatnicze, tożsamości, klucze dostępu (passkeys) oraz klucze SSH. Elementy w koszu oraz funkcje typu Sends nie są uwzględniane w żadnym formacie eksportu, a elementy należące do organizacji muszą zostać wyeksportowane oddzielnie przez właściciela, dlatego należy zaplanować ponowne utworzenie organizacji i zaproszenie użytkowników na nowym serwerze.