Vaultwarden vs Bitwarden self-hosted: alin ang tama?

Ano talaga ang Vaultwarden at Bitwarden self-hosted

Ang Vaultwarden vs Bitwarden self-hosted ay pagpili sa pagitan ng dalawang server na gumagamit ng parehong client API, hindi pagpili sa pagitan ng dalawang password manager. Ang sariling stack ng Bitwarden ay nagpapatakbo ng humigit-kumulang isang dosenang container sa likod ng nginx, nag-iimbak ng lahat sa Microsoft SQL Server, at nakatali sa isang installation ID na nirerehistro mo gamit ang email address. Ang Vaultwarden ay isang hindi opisyal na muling implementasyon ng Bitwarden client API, na isinulat sa Rust at tumatakbo bilang isang container gamit ang isang SQLite file. Hindi sila mapaghihiwalay ng browser extension at ng iyong phone dahil pareho nilang sinasagot ang parehong endpoint.

Magkapareho ang encryption sa alinmang opsyon. Ine-encrypt ng Bitwarden clients ang vault bago may anumang umalis sa device, kaya nag-iimbak ang server ng mga blob na hindi nito mabasa. Pagmamay-ari rin ng Bitwarden ang vault format sa parehong kaso. Ang nagkakaiba ay kung gaano kalaking machine ang kailangan mong rentahan, kung sino ang nagpapanatili ng code, aling mga feature ang may bayad, at kung ano ang kailangan mong i-back up.

Direkta ang pahayag ng Vaultwarden README tungkol sa status nito: "This project is not associated with Bitwarden or Bitwarden, Inc." Volunteer project ito na walang support desk at walang warranty. Nagtatrabaho sa Bitwarden ang isang aktibong maintainer at nag-aambag siya sa sarili niyang oras. Kagandahang-loob ito, hindi pag-eendorso.

Ang tatlong stack na maaari mong i-install

Madalas hindi napapansin sa mga paghahambing na may dalawang magkaibang self-hosted product ang Bitwarden.

Bitwarden standard. Ito ang deployment mula sa vendor na pinapatakbo gamit ang shell script.

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

Hinihingi ng installer ang iyong domain, kung hihiling ng Let's Encrypt certificate, pangalan ng database, at installation ID at key na kinokolekta mo mula sa https://bitwarden.com/host sa pamamagitan ng paglalagay ng email address. Pagkatapos, kumukuha ang ./bitwarden.sh start ng mga image at sinisimulan ang stack. Tinutukoy ng Bitwarden ang 2 GB RAM at 12 GB storage bilang minimum, at 4 GB RAM at 25 GB storage bilang inirerekomenda. Kailangan din ang Docker Engine 26 o mas bago, kasama ang Compose plugin. MSSQL Express image ang database, at nililimitahan ng edition na iyon sa 10 GB ang relational database maliban kung ituro mo ang deployment sa external database.

Bitwarden lite. Ito ang deployment na dating tinatawag na Bitwarden Unified. Lumabas ito sa beta at pinalitan ang pangalan noong December 2025. Binubuo ito ng isang application container at database na ikaw ang pipili:

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:

Tumatanggap ito ng MariaDB o MySQL, PostgreSQL, SQLite, at MSSQL. Nangangailangan ito ng 200 MB RAM at 1 GB storage. May dalawang caveat sa sariling documentation ng Bitwarden. Nakadokumento ito para sa personal na paggamit at home lab, hindi para sa business use. Wala rin itong automatic database backup, kaya ikaw ang ganap na responsable sa gawaing iyon.

Vaultwarden. Isang container ito, direkta mula sa README ng project:

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

Ang publish line ay nagba-bind ng port 8000 sa loopback lamang, at sinadya iyon. Plain HTTP ang ginagamit ng Vaultwarden, at inaasahan nitong isang reverse proxy ang mag-terminate ng TLS (transport layer security) sa harap nito. Hindi optional ang TLS dito. Ginagamit ng web vault ang browser's WebCrypto API para sa encryption nito. Inilalantad lamang ito ng mga browser sa secure context, kaya sa plain http ay nagfa-fail ang login page sa browser bago pa ito makapag-request sa server. Saklaw ng kumpletong walkthrough sa pag-install ng Vaultwarden ang proxy at certificate.

Gaano karaming RAM ang ginagamit ng Vaultwarden kumpara sa self-hosted na Bitwarden?

Ipinapakita ng vendor minimum kung kailan tatangging tumakbo ang installer, hindi kung gaano kalaki ang aktuwal na konsumo ng software. Ang mga row sa ibaba ay mula sa docker stats --no-stream sa mga idle install, tig-iisang user, maliit na vault, at walang attachment, gamit ang Ubuntu 24.04 server na may 4 GB RAM. Ang disk usage ay binubuo ng images at data directory matapos ang unang matagumpay na pagsisimula.

[
  {
    "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
  }
]

Umabot sa 58 MB ang Vaultwarden kapag idle sa iisang container. Ang standard Bitwarden stack ay umabot sa humigit-kumulang 2,400 MB sa 12 containers, at ang MSSQL container ang kumokonsumo ng karamihan nito. Ang Bitwarden lite ay nasa pagitan ng dalawa, sa 470 MB kasama ang MariaDB container nito. Patakbuhin ang parehong command sa sarili mong server bago umasa sa alinman sa mga figure na ito, dahil nagbabago ang mga ito batay sa dami ng user, attachment, at sync traffic. Lumalaki rin ang working set ng MSSQL habang mas matagal itong tumatakbo.

Para sa maliit na VPS, ganito ang praktikal na interpretasyon: komportable ang Vaultwarden na gumagamit ng SQLite sa 1 GB plan, samantalang hindi roon magsisimula ang standard Bitwarden stack. Sa 2 GB plan, natutugunan ng standard stack ang documented minimum ngunit kakaunti na lamang ang natitirang memory para sa operating system. Dahil dito, maaaring aktuwal na ma-trigger ang out-of-memory killer ng kernel. Kapag nag-trigger ito, nagpi-print ang dmesg ng linyang naglalaman ng pangalan ng prosesong pinatay nito. Sa stack na ito, karaniwan itong sqlservr. Maglaan ng 4 GB para sa standard deployment.

Aling paid features ang libre sa Vaultwarden?

Walang bayad ang pagpapatakbo ng server ng Bitwarden, pero nananatiling naka-lock ang mga paid feature hanggang mag-upload ka ng licence file. Kailangan nito ang premium individual account at lahat ng paid organisation tier (Families, Teams, Enterprise). Dina-download ito mula sa cloud web vault, sa Settings at pagkatapos ay Subscription para sa isang individual, o sa Admin Console, sa Billing at pagkatapos ay Subscription para sa isang organisation, at ina-upload sa sarili mong instance. Ibinibigay ang mga organisation licence batay sa installation ID na naka-store sa ./bwdata/env/global.override.env. Kaya ang self-hosted na organisation ay may paid subscription pa rin at kumokonekta pa rin sa cloud ng Bitwarden para sa billing.

Awtomatikong ino-on ng Vaultwarden ang parehong feature nang walang licence at subscription. Nakalista ang mga ito sa project wiki:

• organisations, collections at groups
• file attachments
• two-step login gamit ang email, Duo, YubiKey at FIDO2
• Emergency Access
• Bitwarden Send
• personal API keys
• SSO gamit ang OpenID Connect

Ang SSO ang pinakabago sa mga feature na ito at kino-configure gamit ang SSO_ENABLED, SSO_AUTHORITY, SSO_CLIENT_ID at SSO_CLIENT_SECRET. Login lamang ang ina-authenticate nito. Malinaw sa wiki na kailangan pa rin ang master password at hindi ito kinokontrol ng identity provider mo, dahil ginagamit ang password na iyon para buuin ang key na nagde-decrypt sa vault. Ituro ang SSO_AUTHORITY sa discovery issuer ng self-hosted na Authentik identity provider at doon mag-sign in ang mga user, pagkatapos ay i-unlock ang vault gamit ang kanilang master password. Dapat tumugma ang value sa field na issuer na ibinabalik ng discovery endpoint, nang wala ang suffix na /.well-known/openid-configuration sa dulo.

Ang hindi mo makukuha sa Vaultwarden ay isang vendor. May SOC 2 Type 2 at ISO 27001 ang Bitwarden, naglalabas ito ng third-party audit report, at nagpapatakbo ng pribadong HackerOne bug bounty. Saklaw ng mga ito ang code at service ng Bitwarden, hindi ang server na na-install mo. Pero kung kailangan ng auditor ng pinangalanang supplier sa likod ng password manager mo, mahirap ipagtanggol ang paggamit ng volunteer reimplementation.

Gumagana ba ang mga opisyal na Bitwarden app sa Vaultwarden?

Oo. Ipinapatupad ng Vaultwarden ang client API, kaya gumagana rito ang browser extensions, desktop app, mobile app, at bundled web vault. Sa bawat client, itakda ang self-hosted server URL sa environment screen bago mag-log in, hindi pagkatapos.

Kailangan ng karagdagang configuration para sa isang feature: push notifications sa mobile app. Kapag wala nito, nagsi-sync ang app kapag binuksan mo ito o batay sa sarili nitong timer. Kaya kung binago ang password sa laptop, hindi ito lalabas sa phone hangga't hindi mo binubuksan ang app. Maaaring gamitin ng Vaultwarden ang push relay ng Bitwarden. Kailangan nito ang installation ID at key mula sa parehong https://bitwarden.com/host page na ginagamit ng opisyal na installer.

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

Kailangan din ng mga server sa EU region ang PUSH_RELAY_URI=https://api.bitwarden.eu at PUSH_IDENTITY_URI=https://identity.bitwarden.eu. Tinutukoy ng wiki ang dalawang problemang dapat malaman bago ka mag-debug nang isang oras. Ang app na na-install mula sa F-Droid o Neo Store ay walang Firebase support at hindi kailanman makatatanggap ng push, anuman ang gawin ng server. Ang app na unang kumonekta bago ang Vaultwarden 1.30.2 ay kailangang i-clear ang data nito upang makapag-register ito ng push token.

Gaano kaligtas ang isang reimplementation?

Mahaba at pampubliko ang audit history ng Bitwarden. Sinuri ito ng Cure53 noong 2018, 2021, 2022 at 2023. Sinuri ng IOActive at Mandiant ang mga client noong 2024, sinaklaw ng Fracture Labs ang web at network assessment sa buong 2024 at 2025, tinasa ng Unit 42 ang mobile app noong 2025, at sinuri ng ETH Zurich Applied Cryptography Group ang cryptography noong 2025.

Sinuri rin ng mga external na reviewer ang Vaultwarden, na ikinagugulat ng mga taong nag-aakalang walang tumitingin dito. Pinatest ng Germany's Federal Office for Information Security (BSI) sa mgm security partners ang Vaultwarden mula February hanggang May 2024 bilang bahagi ng Caos 3.0 code analysis project, at itinuring ng review na high ang dalawang finding. Hiwalay dito, nag-ulat ang ERNW ng authentication bypass na nakaapekto sa mga version na mas mababa sa 1.32.5 (CVE-2024-55225), na inayos noong November 2024. Ang Version 1.37.0, na inilabas noong July 2026, ay naglaman ng mga fix para sa SSRF (server side request forgery) sa pamamagitan ng icon endpoint, cross-organisation cipher access, at pag-bypass sa organisation policy sa directory imports.

Ipinapakita ng history na ito na may maayos na proseso ang proyekto para sa security disclosure. Ipinapakita rin nito ang surface na paulit-ulit na lumilitaw sa mga finding: ang admin page. Kaya ituring ang page na ito bilang sensitibong bahagi ng system. Mananatili itong naka-off maliban kung nakatakda ang ADMIN_TOKEN, at hash ang dapat mong i-store sa halip na plaintext token.

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

Nagpi-print ito ng Argon2 PHC string (password hashing competition format) na ilalagay sa ADMIN_TOKEN. I-enable ang HTTPS bago i-enable ang admin page, dahil ipinapadala ang token sa request at mababasa ng anumang nasa network path ang plaintext token kapag plain HTTP connection ang ginagamit. Kung maaari, huwag ilantad sa public internet ang /admin, at gamitin ito kasama ng karaniwang host hardening, gaya ng pag-lock down sa SSH access sa server.

Ano ang nasisira kapag nagbago ang opisyal na API

Ito ang panganib na minamaliit ng mga tao. Ang Bitwarden ang nagre-release ng mga client, at awtomatikong nag-a-update ang mga client na iyon mula sa app stores habang gabi. Kailangang makasabay ang Vaultwarden. Kapag binago ng isang client release ang API contract, makakaharap ang hindi pa na-upgrade na Vaultwarden sa client na naunang lumipat, kaya maaaring magsimulang mabigo ang login o sync sa mga device na hindi mo ginalaw.

May kongkretong halimbawa sa release notes. Nakasaad sa Vaultwarden 1.37.0: "Kailangan ang update na ito para masuportahan ang mga client na may version 2026.7.0 pataas; mag-update muna bago mag-report ng anumang issue sa mga ito." Noong August 2026, ang kasalukuyang release ay 1.37.1, na inilathala noong 29 July 2026.

Dalawang nakagawian ang nagpapanatiling simple sa prosesong ito. Mag-pin ng partikular na image tag sa halip na latest, para hindi mailipat ng unattended pull ang server mo nang 3am. Pagkatapos, i-monitor ang release feed at sadyang isagawa ang upgrade. Basahin muna ang notes, dahil doon at wala nang iba lumalabas ang breaking changes. Halimbawa, in-invalid ng version 1.35.5 ang lahat ng umiiral na two-factor remember token kapag nag-upgrade, kaya na-log out ang mga user sa isang hakbang na akala nila ay na-save na nila.

Ang standard na Bitwarden deployment ay may kabaligtarang anyo ng problemang ito. Isinasagawa ang mga upgrade sa pamamagitan ng ./bitwarden.sh updateself at ./bitwarden.sh update, at inilalapat ng update ang database migrations. Ang backup na ginawa bago ang migration ay hindi rollback para sa schema pagkatapos nito. Kaya gawin ang backup at itala ang version kung saan ito ginawa.

Mga backup, kung saan talaga nawawala ang mga vault

Ang data directory ng Vaultwarden ang mismong server. Itago ang mga ito:

• db.sqlite3
• bawat rsa_key* file, kasama ang rsa_key.pem at rsa_key.der
• attachments/
• config.json
• sends/

Huwag kopyahin ang db.sqlite3 gamit ang cp habang tumatakbo ang container. Maaaring kasalukuyang nagsusulat ang SQLite, kaya maaaring maging corrupt ang kopya kahit mukhang maayos ito hanggang sa i-restore mo. Gamitin na lang ang online backup API:

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

Mula sa 1.32.1, mayroon ding built-in na /vaultwarden backup command sa image. Sa alinmang paraan, mananatili ang snapshot sa parehong disk ng orihinal hanggang sa ilipat mo ito. Kaya i-push ito palabas ng server gamit ang restic snapshots sa off-site storage ayon sa schedule. Mahalaga ang rsa_key files tulad ng database: ginagamit ng server ang key na ito para i-sign ang session tokens nito. Kaya kung ire-restore ang database kasabay ng bagong-generate na key, ma-la-log out ang lahat at masisira ang mga organization invitation na kasalukuyang ipinapadala.

Mas marami sa sariling data nito ang bina-backup ng Bitwarden standard. Nagsusulat ang mssql container ng nightly database backups sa ./bwdata/mssql/backups at pinananatili ang mga ito nang 30 araw, basta tumatakbo ang container. Maaari kang magpatakbo ng backup nang manu-mano:

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

Ang mga directory na dapat itago ay ./bwdata/env (environment variables, kasama ang database at certificate passwords), ./bwdata/core/attachments, ./bwdata/mssql/data, at ./bwdata/core/aspnet-dataprotection. Ang huli ang madalas nakalilimutan. Naglalaman ito ng framework-level data protection material, kasama ang authentication tokens at ilang database column. Kaya kung ire-restore ang database nang wala ito, hindi na mababasa ang mga column na pinoprotektahan nito. Walang automatic backup ang Bitwarden lite. Kaya kung lite ang pipiliin mo, ikaw ang kailangang magpatakbo ng dump schedule, gaya ng sa Vaultwarden.

Paglipat sa alinmang direksiyon

Isinasagawa ang migration sa pamamagitan ng mga client, hindi sa mga server, dahil mga feature ng client ang export at import. Dahil dito, pareho ang procedure sa parehong direksiyon.

Ang bawat user ay nag-e-export mula sa web vault o desktop app, gumagawa ng account sa bagong server, at nag-i-import. Ang mga format ay plaintext .json, plaintext .csv, encrypted .json, at .zip na naglalaman ng JSON kasama ang mga file attachment para sa mga indibidwal na vault. Nananatili lamang ang mga card, identity, stored passkey, at SSH key sa mga JSON form, kaya tahimik na mawawala ang mga ito kapag CSV migration ang ginamit. Walang export format na may kasamang mga item sa trash o Sends, at hindi kasama sa indibidwal na export ang data na pagmamay-ari ng organisation.

Ituring ang plaintext export bilang live secret, dahil iyon mismo ito: ang buong vault mo na nasa clear text sa disk. I-export ito, i-import, at i-delete sa iisang session. Huwag itong ipadala sa email o chat.

May isang trap na madalas nakakahuli sa mga user habang isinasagawa ang migration. Ang encrypted export na naka-bind sa iyong account ay hindi maaaring i-import sa ibang account, at ang paglipat ng server ay nangangahulugang ibang account ito ayon sa depinisyon. Piliin sa halip ang password-protected export option, dahil portable ito.

Mas mahirap ang direksiyong Vaultwarden papunta sa Bitwarden standard, dahil hindi naililipat ang organisation structure sa export. Gawin muli ang organisation sa bagong server, imbitahang muli ang mga user, at ipa-import sa bawat user ang sarili nilang vault. Magplano ng maintenance window para rito sa halip na matuklasan ito sa mismong araw ng migration.

Alin ang dapat mong patakbuhin?

Patakbuhin ang Vaultwarden kung ikaw ay isang tao, isang pamilya, o nagpapatakbo ng home lab sa isang 1 GB o 2 GB VPS. Libre ang Organisations, Emergency Access, at Send. Humigit-kumulang isang browser tab ang memory na ginagamit nito kapag idle. Ang backup ay isang SQLite file at isang maliit na directory. Dahil sa kombinasyong ito, nangingibabaw ito sa self-hosted password management.

Patakbuhin ang sariling server ng Bitwarden kapag may ibang taong propesyonal na umaasa rito: isang kumpanyang nangangailangan ng support contract, isang compliance requirement na partikular na tumutukoy sa vendor, o enterprise features na binabayaran mo na. Maglaan ng 4 GB para sa standard deployment. Ituring ang licence file at installation ID bilang bahagi ng deployment, hindi simpleng paperwork.

Nasa mahirap na gitnang posisyon ang Bitwarden lite. Vendor code ito na mas maliit nang malaki, kaya talagang kaakit-akit. Gayunman, itinatala ng Bitwarden na para ito sa personal at home lab use, at wala itong automatic backups. Ikaw ang sasagot sa operational load ng Vaultwarden nang wala ang libreng feature set nito. Piliin ito kapag mas mahalaga sa iyo ang vendor code kaysa sa mga feature, at handa kang ikaw mismo ang magpatakbo ng database.

Kung pinagpapasyahan mo pa kung ano pa ang iho-host ng server, inilalagay ng mas malawak na self-hosting shortlist ang pagpipiliang ito kasabay ng iba pang serbisyong nakikipag-agawan sa parehong RAM.

FAQ

Sapat bang ligtas ang Vaultwarden para sa aktuwal na password manager?

Para sa personal at pampamilyang paggamit, oo, basta may ilang kondisyon. Ine-encrypt ng mga client ang vault bago ito makarating sa server, kaya hindi kailanman nakikita ng Vaultwarden ang iyong master password o anumang plaintext. Sinuri rin ito ng mga external na tagasuri: ipinagawa ng BSI sa mga kasosyo nitong mgm security ang testing mula February hanggang May 2024, at iniulat ng ERNW ang isang authentication bypass na inayos sa 1.32.5. Panatilihing updated ang version, panatilihing disabled ang admin page o protektado sa likod ng isang Argon2-hashed na ADMIN_TOKEN, at ihatid ito sa HTTPS lamang. Dapat gumamit ang negosyong nangangailangan ng vendor support o audit documentation ng sariling server ng Bitwarden.

Gaano karaming RAM ang kailangan ng Vaultwarden kumpara sa self-hosted na Bitwarden?

Sa mga idle install na sinukat gamit ang docker stats --no-stream, ang Vaultwarden na may SQLite ay gumamit ng humigit-kumulang 58 MB sa isang container, samantalang ang standard deployment ng Bitwarden ay gumamit ng halos 2,400 MB sa 12 containers, at ang malaking bahagi nito ay para sa MSSQL database. Itinakda ng Bitwarden ang 2 GB bilang minimum at 4 GB bilang inirerekomenda para sa standard stack, at 200 MB para sa Bitwarden lite. Tumatakbo ang Vaultwarden sa isang 1 GB VPS na may sapat pang natitirang resources.

Kailangan ko ba ng Bitwarden licence para sa self-hosting?

Hindi para sa libreng individual vault. Libre ang pagpapatakbo ng server. Kailangan ng licence file para ma-unlock ang premium individual features at anumang paid organisation plan, na sumasaklaw sa Families, Teams, at Enterprise. Ida-download mo ito mula sa cloud web vault at ia-upload sa iyong instance, at ibinibigay ang mga organisation licence batay sa installation ID na naka-store sa ./bwdata/env/global.override.env. Hindi nangangailangan ng licence ang Vaultwarden at awtomatiko nitong ine-enable ang mga organisation feature.

Maaari ba akong lumipat mula Vaultwarden patungo sa Bitwarden sa hinaharap, o bumalik?

Oo, parehong direksiyon ay posible gamit ang mga client. Ie-export ng bawat user ang kanilang vault mula sa web vault o desktop app at ii-import ito sa bagong server matapos gumawa roon ng account. Kasama sa .zip export ang mga attachment para sa mga individual vault, at kasama sa JSON form ang mga card, identity, passkey, at SSH key. Walang export format para sa mga item sa Trash at Sends, at dapat hiwalay na i-export ng owner ang mga item na pagmamay-ari ng organisation. Kaya planuhing muling likhain ang organisation at muling mag-imbita ng mga user sa bagong server.