Mga Gabay

Ni Matt Connor 2026-07-15 · Na-update 2026-08-31

Vaultwarden sa VPS: Sariling Password Manager

Q: Kailangan ko ba talaga ng HTTPS, o maaari ko itong patakbuhin gamit ang http sa LAN ko?

Kailangan mo ng HTTPS para sa lahat maliban sa localhost test. Ginagamit ng Bitwarden web vault at mga extension ang Web Crypto API ng browser, na available lamang sa secure context. Kaya kapag plain http ang gamit, naglalabas ang client ng Cannot read properties of undefined at hindi kailanman nakakapag-login. Ang tanging http address na gumagana ay http://localhost, kaya gumagamit ng SSH tunnel ang restore test sa Step 8.

Q: Paano ko pipigilan ang mga hindi kilalang tao na mag-register sa server ko?

Itakda ang SIGNUPS_ALLOWED: "false" sa Compose file at patakbuhin ang docker compose up -d kaagad pagkatapos mong gumawa ng sarili mong account. Pagkatapos nito, magdagdag ng mga bagong user gamit ang Invite User button sa /admin. Kailangan nito ng naka-configure na SMTP para matanggap nila ang invitation link. Paminsan-minsan, suriin ang listahan ng admin user upang matiyak na walang hindi inaasahang account na nadagdag.

Q: Paano ko iba-back up ang Vaultwarden vault ko?

Pansamantalang ihinto ang container at i-archive ang buong vw-data volume, db.sqlite3, attachments/, sends/, config.json, at ang mga rsa_key.* file. Pagkatapos, kopyahin ang archive palabas ng server, kung maaari ay gamit ang nightly cron. Kapag kinopya ang live SQLite file habang tumatakbo ang server, maaaring maging corrupt ang snapshot, kaya gawin ito kapag nakahinto ang server. Pinakamahalaga, i-restore ito nang isang beses sa isang throwaway container at mag-login, para makumpirma mong tunay na gumagana ang backup bago ka umasa rito.

I-deploy ang Vaultwarden gamit ang Docker sa VPS: HTTPS muna, admin token, Fail2ban, at backup na nasubukan ang restore. Kailangan lang ng humigit-kumulang 100 MB RAM.

Mga itinatayo mo

Isang password manager na ganap mong pagmamay-ari: Vaultwarden na tumatakbo sa isang maliit na container sa likod ng reverse proxy na nagte-terminate ng HTTPS, at ang mga official Bitwarden app sa iyong phone, laptop, at browser ay nakaturo rito. Muling ipinapatupad ng Vaultwarden sa Rust ang Bitwarden server API at ginagamit nito ang parehong protocol ng bitwarden.com. Kaya gumagana rito ang bawat official client nang walang pagbabago, pero humigit-kumulang 100 MB lang ng RAM ang kailangan nito sa halip na ang official stack na binubuo ng maraming container.

Ang mismong installation ay isang dosenang linya ng Compose. Ito ang tatlong bagay na talagang mahalaga at kadalasang nagdudulot ng problema: dapat may TLS bago mo buksan ang web vault, dapat isara ang public signups sa sandaling magawa na ang sarili mong account, at dapat ma-backup at ma-test-restore ang data volume dahil nasa iisang directory na iyon ang lahat ng password na pagmamay-ari mo.

Mga prerequisite at mahahalagang limitasyon

Isang VPS na may Docker Engine at Compose plugin, gamit ang bagong Ubuntu 24.04 KVM box na may root o sudo. Sapat talaga ang 512 MB ng RAM; mas kumportable ang 1 GB. Isa ito sa pinakamagaang application na maaari mong patakbuhin, at kabilang ito sa nangungunang mga serbisyong sulit i-self-host. Gayunman, i-size ang box batay sa iba pang serbisyong gagamit nito: kung maglalagay ka ng self-hosted photo library gaya ng PhotoPrism o Immich sa parehong VPS, aabot sa ilang gigabytes ang minimum RAM, samantalang bahagya lang itong madadagdagan ng Vaultwarden. Pareho ang kalkulasyon para sa mga media front end na idaragdag mo kalaunan, dahil ang pag-aayos sa Jellyfin library para magmukhang mapupuntahang 90s rental store ay nangangailangan ng isa pang always-on container at sapat na headroom para sa transcoding sa parehong budget.
Isang domain na may A record (at AAAA kung mayroon kang IPv6) na nagtuturo vault.example.com sa VPS. Para sa eksaktong pangalang ito ibinibigay ang TLS certificate, kaya dapat ma-resolve ng DNS ang domain bago ka magsimula.
Dapat bukas sa internet ang ports 80 at 443 at dapat itong i-terminate ng reverse proxy, hindi kailanman ng Vaultwarden nang direkta. Ginagamit lamang ang port 80 para sa ACME certificate challenge at sa HTTP-to-HTTPS redirect.
Ito ang pinakamahalagang limitasyon: ayaw kumonekta ng Bitwarden clients sa server na hindi gumagamit ng HTTPS. Walang opsyong “subukan muna ito sa http”; hindi gagana ang paraang iyon sa isang tiyak na dahilan na ipapaliwanag sa susunod.

Bakit Vaultwarden, hindi ang opisyal na Bitwarden stack

Pareho ang mga client, pero mas kaunti ang resource na kailangan. Ang opisyal na self-hosted Bitwarden ay inilalabas bilang bundle ng mga container (MSSQL, Nginx, Identity, Api, Admin at iba pa) at nangangailangan ng humigit-kumulang 2 GB ng RAM. Ang Vaultwarden ay isang binary lamang. Bilang default, iniimbak nito ang lahat sa isang SQLite database at gumagamit lamang ng ilang dosenang megabyte kapag idle. Para sa isang tao, pamilya, o maliit na team, ito ang malinaw na praktikal na pagpipilian. Dahil tapat nitong ipinapatupad ang Bitwarden API, nananatiling portable ang data mo sa pagitan nito at ng bitwarden.com.

Ang kapalit nito ay ang malaking bahagi ng enterprise functionality: walang SCIM provisioning, bagama't available na ang experimental OpenID Connect SSO sa 1.35.0. Ikaw ang operator, kaya responsibilidad mo ang paglalapat ng patches, HTTPS, at backups. Ang gabay na ito ay tungkol sa tatlong gawaing iyon.

Bakit hindi opsyonal ang HTTPS

Dini-derive ng Bitwarden web vault at mga browser extension ang iyong encryption key sa browser gamit ang Web Crypto API (window.crypto.subtle). Ipinapakita lamang ng mga browser ang crypto.subtle sa isang secure context, gaya ng HTTPS, o sa espesyal na kaso ng http://localhost. Sa plain http://vault.example.com, ito ay undefined, kaya nagkakaroon agad ng error kapag nagdi-derive ang app ng key, at ipinapakita ng console ang:

Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'importKey')

Nananatiling naka-hang ang page o nagpapakita ng generic crypto error, at walang makakapag-log in. May sarili nilang check ang desktop, mobile, at browser client laban sa self-hosted URL. Kapag http o hindi reachable ang endpoint, tinatanggihan nila ito at ipinapakita ang:

This is not a recognized Bitwarden server. You may need to check with your provider or update your server.

Pareho ang sanhi ng dalawang error: walang valid na HTTPS. Kaya TLS muna ang ise-set up natin, at hindi kailanman bubuksan ang vault gamit ang http, kahit isang beses lang para sa mabilis na pagtingin.

Hakbang 1, DNS at reverse proxy (TLS muna)

Ituro ang record sa iyong VPS at tiyaking nagre-resolve ito sa tamang address:

dig +short vault.example.com

Ang line na ipinapakita nito ay dapat na IP ng iyong VPS. Kung blangko o mali ito, ayusin ang DNS at hintayin ang TTL. Nabibigo ang pag-issue ng certificate kapag hindi nagre-resolve ang pangalan.

Para sa HTTPS front end, Traefik ang ginagamit ng gabay na ito. Awtomatiko itong nag-i-issue at nagre-renew ng Let's Encrypt certificates at direktang isinasama sa Compose. Kung hindi mo pa ito pinapatakbo, sundin muna ang setup ng Traefik reverse proxy at awtomatikong TLS. Gumagawa ito ng external Docker network (proxy sa ibaba) at ACME resolver (letsencrypt) na pagdudugtungan ng Vaultwarden service. Gumagana rin sa panig ng Vaultwarden ang plain nginx na may manu-manong ini-issue na certificate.

Mas gusto mo ba ang nginx at Certbot sa halip na Traefik? Ilagay ang Vaultwarden sa 127.0.0.1:8080 (idagdag ang ports: ["127.0.0.1:8080:80"] sa service at alisin ang Traefik labels), pagkatapos ay mag-issue ng certificate at mag-configure ng proxy papunta rito. Saklaw sa pag-issue ng Let's Encrypt certificates gamit ang Certbot at nginx ang bahagi ng certificate. Ang mahalagang dagdag ay ang WebSocket upgrade sa notifications path:

server {
    listen 443 ssl;
    server_name vault.example.com;

    client_max_body_size 525M;

    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;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Pansinin ang X-Real-IP line. Dahil dito, makikita ng Fail2ban ang tunay na attacker sa halip na 127.0.0.1. Pareho ang lahat ng iba pang hakbang sa gabay na ito, Traefik man o nginx ang nasa harapan.

Hakbang 2, ang Compose file

Gawin muna ang project directory. Ginagamit ng guide na ito ang /opt/vaultwarden, na nagtatakda sa pangalan ng Compose project at, dahil dito, sa data volume na vaultwarden_vw-data, para maging predictable ang mga ito. Nakadepende ang mga sumusunod na hakbang para sa Fail2ban at backup sa eksaktong pangalang ito.

sudo mkdir -p /opt/vaultwarden
cd /opt/vaultwarden

Gumawa ng .env para sa admin secret at ng Compose file sa directory na iyon.

# .env
ADMIN_TOKEN=paste-a-strong-token-here

I-generate ang token gamit ang openssl rand -base64 48 at i-paste ito. (Tatalakayin sa susunod ang mas secure na hashed form; sapat na muna ang mahabang random string.)

# docker-compose.yml
services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.example.com"
      SIGNUPS_ALLOWED: "true"          # closed in Step 4, keep true just to register
      ADMIN_TOKEN: "${ADMIN_TOKEN}"
      IP_HEADER: "X-Forwarded-For"     # X-Real-IP if your proxy sends that instead
      LOG_FILE: "/data/vaultwarden.log"
      LOG_LEVEL: "warn"
    volumes:
      - vw-data:/data
    networks:
      - proxy
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.vw.rule=Host(`vault.example.com`)"
      - "traefik.http.routers.vw.entrypoints=websecure"
      - "traefik.http.routers.vw.tls.certresolver=letsencrypt"
      - "traefik.http.services.vw.loadbalancer.server.port=80"

volumes:
  vw-data:

networks:
  proxy:
    external: true

Dalawang bagay sa file na ito ang bumubuo sa buong design. Walang ports: mapping, kaya maa-access ang Vaultwarden sa pamamagitan lamang ng Traefik at TLS nito. Kapag inilathala ang port nito sa host, maaaring aksidenteng ma-serve ang vault sa pamamagitan ng http. Dapat ding ang DOMAIN ang buong public HTTPS URL. Isinasama ito sa attachment links, WebAuthn 2FA, at notifications endpoint, kaya masisira ang mga iyon kapag mali o http ang value kahit naglo-load ang site. Ang latest tag ay sadyang eksepsiyon sa karaniwang patakarang huwag gumamit ng latest. Inilalabas ng Vaultwarden ang stable releases nito bilang iisang rolling image, habang hiwalay na pre-release channel ang :testing. Kaya mag-update nang sinasadya at basahin muna nang mabilis ang release notes bago mag-pull. Limitado ang eksepsiyong ito. Mas mainam para sa karamihan ng matagal nang tumatakbong container ang pag-pin sa eksaktong tag. Ito ang nagpapanatiling predictable sa isang palaging tumatakbong self-hosted agent sa parehong VPS sa bawat reboot at pull.

Paandarin ito at i-monitor ang log:

docker compose up -d
docker compose logs -f vaultwarden

Ang wastong pagsisimula ay nagtatapos sa linyang tulad ng Rocket has launched from http://0.0.0.0:80. Maghintay ng ilang segundo para makuha ni Traefik ang certificate, pagkatapos ay i-load ang https://vault.example.com. Dapat lumabas ang Bitwarden web vault na may valid na padlock at walang certificate warning.

Hakbang 3, isang matibay na ADMIN_TOKEN, at ang $$ trap

ADMIN_TOKEN ang nagpoprotekta sa /admin, ang panel na makakabasa sa bawat user at setting sa iyong instance, kaya ituring ito na parang root password. Dalawang anyo ang gumagana.

Ang simpleng anyo ay ang random string na ginawa mo na gamit ang openssl rand -base64 48. Dahil hindi kailanman naglalaman ang base64 ng $, maaari itong ilagay agad sa .env nang walang escaping.

Ang mas secure na anyo ay isang Argon2 PHC hash, kaya hindi kailanman nase-save sa disk ang plaintext token. Bumuo nito gamit ang parehong image:

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

Dalawang beses itong magpo-prompt at magpi-print ng string na nagsisimula sa $argon2id$v=19$.... Narito ang trap na umaabot nang isang oras sa pag-aayos: itinuturing ng Docker Compose ang $ bilang variable interpolation, kaya kailangan mong i-double ang bawat $ upang maging $$ kapag ipinaste mo ang hash sa Compose file. Ilagay ito mismo sa ilalim ng environment:, hindi sa pamamagitan ng .env, at huwag itong lagyan ng quotes:

    environment:
      ADMIN_TOKEN: $$argon2id$$v=19$$m=19456,t=2,p=1$$c29tZXNhbHQ$$RdescudvJCsgt3ub+b+dWRWJTmaaJObG

Kung iiwan mo ang iisang $ signs, magpapakita ang Compose ng babalang The "argon2id" variable is not set at aalisin ang laman ng token, kaya tatanggihan ng /admin ang tamang password mo. Patakbuhin ang docker compose up -d, at itago sa sarili mong password store ang plaintext na inilagay mo sa prompt.

Hakbang 4, i-register ang iyong account, pagkatapos ay isara ang access

Gamit ang SIGNUPS_ALLOWED: "true", buksan ang https://vault.example.com, i-click ang Create account, at mag-register gamit ang iyong email at matibay na master password. Hindi na mare-recover ang master password na ito at walang reset option, kaya i-store muna ito sa isang matibay at ligtas na lugar.

Isara na ngayon ang access. I-edit ang Compose file para i-disable ang mga signup:

      SIGNUPS_ALLOWED: "false"

I-apply muli gamit ang docker compose up -d. Hindi ito hardening na maaaring ipagpaliban. Kapag naka-enable ito, maaaring gumawa ng account sa server mo ang sinumang makahanap ng URL; ginagawa rin ito ng mga crawler. Hindi nila mababasa ang vault mo, pero kumokonsumo sila ng resources at ginagawa nilang open service ang private instance mo. Makikita mong naiwan itong naka-enable kapag naglilista ang /admin ng mga account na hindi mo ginawa.

Para magdagdag ng pamilya o mga ka-team sa ibang pagkakataon nang hindi muling binubuksan ang public signups, gamitin ang button na Invite User sa /admin. Kailangan naka-configure ang SMTP para matanggap ng iimbitahang user ang kanilang link.

Hakbang 5, pag-access sa /admin

Bisitahin ang https://vault.example.com/admin at ilagay ang plaintext admin token (ang random string o ang password na iyong ni-hash, hindi ang hash mismo). Dito, maaari mong ilista ang mga user, ayusin ang mga setting, magpadala ng test email, at gumawa ng database snapshot.

Kung ibinabalik ng page ang 404 Not Found, walang laman o hindi naka-set ang ADMIN_TOKEN, kaya ganap na hindi pinagana ang panel. Katanggap-tanggap itong configuration kung hindi mo ito kailanman kakailanganin. Kung naglo-load ang page pero tinatanggihan ang token mo, tingnan ang $$ escaping trap sa listahan ng mga failure sa ibaba. Nakalimutan mo ang token? Walang recovery prompt; i-edit ang .env o ang Compose file, magtakda ng bago, at docker compose up -d.

Hakbang 6, ikonekta ang mga Bitwarden client

Maaaring kumonekta ang bawat opisyal na client sa isang self-hosted server. I-install ang Bitwarden desktop, mobile, o browser client mula sa karaniwang app store. Hindi mo kailangan ng espesyal na Vaultwarden build.

Bago mag-log in, buksan ang settings gear sa login screen (may label na Self-hosted o Region → Self-hosted), itakda ang Server URL sa https://vault.example.com, at i-save ito. Pagkatapos, mag-log in gamit ang email at master password na ipinarehistro mo. Dapat agad kumonekta ang client at mag-alok na mag-fill at mag-save ng mga credential.

Kung ipinapakita ng client ang This is not a recognized Bitwarden server. You may need to check with your provider or update your server., mali ang URL, gumagamit ito ng http, o hindi pinagkakatiwalaan ang certificate. Suriing muli kung maayos na naglo-load sa browser ang https://vault.example.com. Ang mabagal na pag-update sa ibang device ay dulot ng WebSocket push, na tatalakayin sa ibaba.

Itinatala ng Vaultwarden ang bawat nabigong login sa file na itinakda ng LOG_FILE. Ito mismo ang kailangan ng brute-force guard. Kung hindi ka pa nagpapatakbo ng Fail2ban, nasa gabay sa SSH hardening gamit ang Fail2ban ang installation at mga pangunahing hakbang. Dito, magdaragdag tayo ng isang jail para sa vault.

Una, alamin kung saan nasa host ang named volume para mabasa ng Fail2ban ang log:

docker volume inspect vaultwarden_vw-data --format '{{ .Mountpoint }}'

Magpi-print ito ng ganito: /var/lib/docker/volumes/vaultwarden_vw-data/_data. Nasa loob nito ang log sa vaultwarden.log. Gawin ang filter:

# /etc/fail2ban/filter.d/vaultwarden.conf
[Definition]
failregex = ^.*Username or password is incorrect\. Try again\. IP: <ADDR>\. Username:.*$
ignoreregex =

At ang jail:

# /etc/fail2ban/jail.d/vaultwarden.local
[vaultwarden]
enabled   = true
filter    = vaultwarden
logpath   = /var/lib/docker/volumes/vaultwarden_vw-data/_data/vaultwarden.log
banaction = iptables-allports
chain     = DOCKER-USER
maxretry  = 5
findtime  = 600
bantime   = 3600

I-reload gamit ang sudo systemctl restart fail2ban at kumpirmahin gamit ang sudo fail2ban-client status vaultwarden.

Tatlong detalye sa Docker ang tumutukoy kung may mapoprotektahan ang configuration na ito. Una, kung ipinapakita ng log ang IP: 127.0.0.1 o ang address ng proxy sa bawat nabigong pagtatangka, ang proxy ang bina-ban ng Vaultwarden. Itakda ang IP_HEADER sa header na talagang ipinapadala ng iyong proxy: X-Forwarded-For para sa Traefik, X-Real-IP para sa nginx block sa itaas, at CF-Connecting-IP kapag nasa likod ng Cloudflare.

Ikalawa, nakadepende sa proxy ang tamang iptables chain. Kung tumatakbo ang Traefik bilang container na may published ports, dumadaan ang traffic sa FORWARD path ng Docker. Kaya dapat nasa DOCKER-USER ang ban, gaya ng nasa itaas. Ngunit kung pinili mo ang host-nginx option sa Hakbang 1, nagtatapos ang mga koneksyon sa nginx sa host na nasa INPUT chain. Hindi sila makikita ng DOCKER-USER ban. Sa kasong ito, tanggalin ang linyang chain = DOCKER-USER para gamitin ng Fail2ban ang default na INPUT chain.

Ikatlo, gamitin ang banaction = iptables-allports sa halip na default na nakabatay sa port. Walang tinutukoy na port ang jail na ito. Direktang hinaharang ng all-ports ban sa DOCKER-USER ang offender mula sa lahat ng published service sa server.

Hakbang 8, i-back up ang vault, pagkatapos ay aktuwal itong i-restore

Ang vw-data volume ang iyong password manager. Nasa loob nito ang db.sqlite3 (lahat ng entry), ang attachments/ at sends/ directories, ang rsa_key.* files na lumalagda sa login sessions, at ang config.json mula sa admin panel. Mabibigo ang backup kapag may alinman sa mga ito na hindi kasama.

Kapag kinopya ang db.sqlite3 habang nagsusulat ang Vaultwarden, maaaring makuha ang bahagyang naisulat at sirang file. Kaya gumawa ng cold snapshot; ilang segundo lang ang downtime:

#!/usr/bin/env bash
set -euo pipefail
STAMP=$(date +%F)
DEST=/root/vw-backups
VOL=$(docker volume inspect vaultwarden_vw-data --format '{{ .Mountpoint }}')
mkdir -p "$DEST"
docker compose -f /opt/vaultwarden/docker-compose.yml stop vaultwarden
tar czf "$DEST/vw-$STAMP.tgz" -C "$VOL" .
docker compose -f /opt/vaultwarden/docker-compose.yml start vaultwarden

Patakbuhin ito gabi-gabi mula sa cron at kopyahin ang .tgz palabas ng server. Ang backup na nasa server lang na pinoprotektahan mo ay hindi tunay na backup. Ang maayos na paraan ay isang nightly restic backup sa ibang server o object storage, na nag-e-encrypt ng archive at nagde-deduplicate ng paulit-ulit na snapshots para sa iyo. Maginhawa ang Backup Database button sa admin panel para sa hot snapshot ng SQLite file lamang, ngunit hindi nito kasama ang attachments at keys.

Ngayon, gawin ang hakbang na naghihiwalay sa tunay na backup mula sa backup na inaasahan mo lang: i-restore ito nang isang beses at patunayang gumagana ito:

mkdir -p /tmp/vw-restore
tar xzf /root/vw-backups/vw-2026-07-15.tgz -C /tmp/vw-restore
docker run --rm -p 127.0.0.1:8888:80 -v /tmp/vw-restore:/data vaultwarden/server

Mula sa iyong laptop, gumawa ng tunnel papunta rito gamit ang ssh -L 8888:127.0.0.1:8888 you@your-vps at buksan ang http://localhost:8888. Dahil secure context ang localhost, available ang crypto.subtle at nade-decrypt ang vault sa plain http dito—ito ang tanging lugar na pinapayagan ito. Mag-login gamit ang iyong master password at tiyaking naroon ang iyong mga entry. Kung naroon ang mga ito, matagumpay na na-restore ang iyong database, RSA keys, at master password, at maaari kang mag-rebuild sa bagong VPS sa loob ng ilang minuto. Ihinto ang container gamit ang Ctrl-C at i-delete ang /tmp/vw-restore. Panatilihin ang ganitong tunnel na paraan para sa iba pang admin UI sa server na hindi dapat direktang ma-access mula sa internet. Sa ganitong paraan mo rin maa-access ang isang self-hosted open-kritt security scanner sa port 5173.

Mga failure mode at mga string na makikita mo

Cannot read properties of undefined (reading 'importKey') sa browser console. Na-load ang vault gamit ang http, kaya undefined ang crypto.subtle; i-access lamang ito gamit ang https:// at idagdag ang HTTP-to-HTTPS redirect sa proxy.

This is not a recognized Bitwarden server... sa isang client. Ang Server URL ay http, mali ang pagkaka-type, o hindi pinagkakatiwalaan ang certificate; tiyaking nagpapakita ang https://vault.example.com ng valid na padlock, pagkatapos ay ilagay itong muli sa self-hosted settings ng client.

Tinatanggihan ng /admin ang tamang password. Nawala ang escaping ng Argon2 hash; dapat $$ ang bawat $ sa Compose, o nailagay mo ang hash sa halip na ang plaintext na kinakatawan nito.

Mabagal ang cross-device sync; ipinapakita ng console ang WebSocket connection to 'wss://vault.example.com/notifications/hub' failed. Hindi ipinapasa ng proxy ang mga header na Upgrade/Connection; awtomatikong ginagawa ito ng Traefik, samantalang kailangan ng nginx ang dalawang upgrade line mula sa Step 1. Gumagana pa rin ang vault, ngunit nagsi-sync lamang kapag binuksan. Wala na ang dating dedicated port 3012 mula noong v1.31.0, kaya hindi na kailangan ng hiwalay na WebSocket route.

Nag-uulat ang Fail2ban ng ban, ngunit patuloy na kumokonekta ang attacker. Bina-ban nito ang 127.0.0.1 dahil mali ang IP_HEADER, o nasa maling iptables chain ang ban; itakda ang chain = DOCKER-USER at banaction = iptables-allports.

Mga Upgrade

I-pull ang bagong image at i-recreate ang container; mananatili ang named volume at lahat ng iyong data:

docker compose pull
docker compose up -d

Madalas maglabas ng bagong release ang Vaultwarden. Subaybayan ang mga release note ng proyekto sa halip na mag-pin ng patch version, dahil may ilang release na may migration note. Gumawa ng bagong backup bago ang anumang major version upgrade; maaari kang mag-roll back sa pamamagitan ng pag-restore ng tarball sa bagong volume.

FAQ

Pareho ba ang Vaultwarden at Bitwarden?

Isa itong compatible at independent na server, hindi ang opisyal na server. Muling ipinapatupad ng Vaultwarden sa Rust ang Bitwarden server API, kaya gumagana rito ang mga opisyal na desktop, mobile, browser, at CLI client, habang mas kaunti ang kinakailangang resources kumpara sa opisyal na stack. Pareho ang vault format, kaya maaari kang mag-migrate sa alinmang direksiyon sa pamamagitan ng pag-export at pag-import.

Kailangan ko ba talaga ng HTTPS, o maaari ko itong patakbuhin gamit ang http sa LAN ko?

Kailangan mo ng HTTPS para sa lahat maliban sa localhost test. Ginagamit ng Bitwarden web vault at mga extension ang Web Crypto API ng browser, na available lamang sa secure context. Kaya kapag plain http ang gamit, naglalabas ang client ng Cannot read properties of undefined at hindi kailanman nakakapag-login. Ang tanging http address na gumagana ay http://localhost, kaya gumagamit ng SSH tunnel ang restore test sa Step 8.

Paano ko pipigilan ang mga hindi kilalang tao na mag-register sa server ko?

Itakda ang SIGNUPS_ALLOWED: "false" sa Compose file at patakbuhin ang docker compose up -d kaagad pagkatapos mong gumawa ng sarili mong account. Pagkatapos nito, magdagdag ng mga bagong user gamit ang Invite User button sa /admin. Kailangan nito ng naka-configure na SMTP para matanggap nila ang invitation link. Paminsan-minsan, suriin ang listahan ng admin user upang matiyak na walang hindi inaasahang account na nadagdag.

Paano ko iba-back up ang Vaultwarden vault ko?

Pansamantalang ihinto ang container at i-archive ang buong vw-data volume, db.sqlite3, attachments/, sends/, config.json, at ang mga rsa_key.* file. Pagkatapos, kopyahin ang archive palabas ng server, kung maaari ay gamit ang nightly cron. Kapag kinopya ang live SQLite file habang tumatakbo ang server, maaaring maging corrupt ang snapshot, kaya gawin ito kapag nakahinto ang server. Pinakamahalaga, i-restore ito nang isang beses sa isang throwaway container at mag-login, para makumpirma mong tunay na gumagana ang backup bago ka umasa rito.

Ligtas ba talaga ang self-hosting ng mga password ko?

Oo, kapag ginawa mo ang tatlong bagay na saklaw ng gabay na ito: tunay na HTTPS, saradong signup kasama ang malakas na admin token, at nasubok na mga backup. Ine-encrypt ang vault sa client side gamit ang iyong master password, kaya hindi kailanman nakikita ng server ang mga password mo nang plain text. Dahil dito, walang silbi ang ninakaw na db.sqlite3 kung wala ang master password. Ang kapalit ay ikaw na ang responsable sa pag-patch at pagba-back up. Kaya hindi optional dito ang Fail2ban at ang restore procedure. Kapag naipatupad na ang mga ito, ang mas masusing pagtingin sa mga aktuwal na puntirya ng pag-atake sa isang self-hosted vault ang kapaki-pakinabang na susunod na hakbang. Dahil naka-encrypt sa client ang mismong mga entry, ang kailangan mo na lamang ipagtanggol ay ang admin token at ang backup archive.

#vaultwarden #passwords #security #docker #self-hosting

Mga itinatayo mo

Mga prerequisite at mahahalagang limitasyon

Bakit Vaultwarden, hindi ang opisyal na Bitwarden stack

Bakit hindi opsyonal ang HTTPS

Hakbang 1, DNS at reverse proxy (TLS muna)

Hakbang 2, ang Compose file

Hakbang 3, isang matibay na ADMIN_TOKEN, at ang $$ trap

Hakbang 4, i-register ang iyong account, pagkatapos ay isara ang access

Hakbang 5, pag-access sa /admin

Hakbang 6, ikonekta ang mga Bitwarden client

Hakbang 7, Fail2ban jail para sa login endpoint

Hakbang 8, i-back up ang vault, pagkatapos ay aktuwal itong i-restore

Mga failure mode at mga string na makikita mo

Mga Upgrade

FAQ

Pareho ba ang Vaultwarden at Bitwarden?

Kailangan ko ba talaga ng HTTPS, o maaari ko itong patakbuhin gamit ang http sa LAN ko?

Paano ko pipigilan ang mga hindi kilalang tao na mag-register sa server ko?

Paano ko iba-back up ang Vaultwarden vault ko?

Ligtas ba talaga ang self-hosting ng mga password ko?