Mga Gabay

Ni Matt Connor 2026-07-15 · Na-update 2026-07-24

Paano mag-setup ng Vaultwarden sa VPS

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

Kailangan mo ng HTTPS maliban na lang kung para sa localhost test ito. Ginagamit ng Bitwarden web vault at extensions ang Web Crypto API ng browser. Ang API na ito ay available lamang sa isang secure context. Dahil dito, maglalabas ng error na Cannot read properties of undefined ang client at hindi makakapag-login kung plain http ang gamit. Ang tanging http address na gumagana ay ang http://localhost, kaya gumagamit ng SSH tunnel sa restore test sa Step 8.

Q: Paano ko mapipigilan ang pag-register ng mga hindi kakilala sa aking server?

I-set ang SIGNUPS_ALLOWED: "false" sa Compose file at i-run ang docker compose up -d agad pagkatapos gawin ang iyong sariling account. Pagkatapos nito, i-add ang mga bagong tao gamit ang Invite User button sa /admin. Kailangan ang SMTP configuration para matanggap nila ang invitation link. Suriin ang admin user list paminsan-minsan para masiguradong walang ibang account na nag-appear.

Matutong mag-self-host ng Bitwarden-compatible password manager gamit ang Docker sa VPS. Kasama ang guide para sa HTTPS, admin token, at backup ng data volume.

Ang iyong bubuuin

Isang password manager na kontrolado mo nang lubos: Vaultwarden na tumatakbo sa isang maliit na container sa likod ng isang reverse proxy na nag-e-encrypt ng HTTPS, gamit ang mga official Bitwarden apps sa iyong phone, laptop, at browser. Ang Vaultwarden ay re-implementation ng Bitwarden server API gamit ang Rust at gumagamit ng parehong protocol gaya ng bitwarden.com. Dahil dito, gagana ang lahat ng official client nang walang pagbabago — ngunit gumagamit lamang ito ng humigit-kumulang 100 MB ng RAM kumpara sa multi-container na official stack.

Ang installation ay binubuo lamang ng labindalawang linya ng Compose. Ang tatlong mahahalagang bagay — na madalas ding maging sanhi ng error — ay ang mga ito: dapat may TLS bago i-load ang web vault, dapat i-disable ang public signups kapag mayroon nang sariling account, at dapat i-back up at i-test ang data volume, dahil ang directory na ito ang naglalaman ng lahat ng iyong mga password.

Mga Prerequisites at ang mga dapat malaman

Isang VPS na may Docker Engine at Compose plugin, sa isang bagong Ubuntu 24.04 KVM box na may root o sudo access. Sapat na ang 512 MB ng RAM; mas mainam kung 1 GB. Isa ito sa pinakamagaan na serbisyong pwedeng patakbuhin — kabilang ito sa listahan ng mga serbisyong sulit i-self-host.
Isang domain na may A record (at AAAA kung may IPv6) na nakaturo sa vault.example.com sa VPS. Ang TLS certificate ay ibibigay para sa eksaktong pangalang ito, kaya dapat gumagana muna ang DNS bago magsimula.
Bukas ang mga port na 80 at 443 sa internet, at dapat dumaan sa iyong reverse proxy — huwag na huwag direktang sa Vaultwarden. Ang port 80 ay gagamitin lamang para sa ACME certificate challenge at HTTP-to-HTTPS redirect.
Ang pinakamalaking problema sa simula: hindi tatanggapin ng mga Bitwarden client ang server na hindi HTTPS. Walang "i-test muna via http" — hindi gagana ang paraang iyon dahil sa isang partikular na dahilan na tatalakayin sa susunod.

Bakit Vaultwarden, hindi ang official Bitwarden stack

Pareho ang mga client, pero mas magaan. Ang official self-hosted Bitwarden ay binubuo ng maraming containers (MSSQL, Nginx, Identity, Api, Admin, atbp.) at nangangailangan ng halos 2 GB na RAM. Ang Vaultwarden ay isang single binary na gumagamit ng SQLite database by default at gumagamit lamang ng ilang tens ng megabytes kapag idle. Para sa isang tao, pamilya, o maliit na team, ito ang mas mainam na pagpipilian. Dahil faithful ang implementation nito sa Bitwarden API, portable ang iyong data mula rito patungo sa bitwarden.com.

Ang mawawala sa iyo ay ang karamihan sa enterprise features: walang SCIM provisioning (bagaman may experimental OpenID Connect SSO na simula sa version 1.35.0), at ikaw ang magsisilbing operator, kaya responsibilidad mo ang patching, HTTPS, at backups. Ang guide na ito ay tungkol sa tatlong trabahong iyon.

Bakit hindi optional ang HTTPS

Ginagamit ng Bitwarden web vault at browser extensions ang Web Crypto API (window.crypto.subtle) para i-derive ang iyong encryption keys sa browser. Ie-expose lamang ng mga browser ang crypto.subtle sa isang secure context — ang HTTPS, o ang special case na http://localhost. Hindi ito gagana sa plain http://vault.example.com dahil sa undefined, kaya mag-e-error agad ang app kapag nag-derive ng key, at lalabas sa console ang:

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

Magha-hang ang page o magpapakita ng generic crypto error, at hindi magla-log in. Ang desktop, mobile, at browser clients ay may sariling check laban sa self-hosted URL. Kapag http (o unreachable) ang endpoint, mag-e-error ang mga ito:

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

Pareho ang sanhi ng dalawang ito: walang valid na HTTPS. Kaya dapat i-setup muna ang TLS at huwag kailanman bubuksan ang vault gamit ang http, kahit para sa mabilisang pagtingin lang.

Step 1 — DNS at ang reverse proxy (TLS muna)

Ituro ang record sa iyong VPS at kumpirmahin kung tama ang address na lumalabas:

dig +short vault.example.com

Dapat ang IP ng iyong VPS ang nakalimbag sa linya. Kung ito ay blanko o mali, ayusin ang DNS at hintayin ang TTL — mabibigo ang certificate issuance kung hindi nag-re-resolve ang pangalan.

Para sa HTTPS front end, Traefik ang ginagamit sa guide na ito. Awtomatikong nag-i-issue at nagre-renew ito ng Let's Encrypt certificates at direktang gumagana sa Compose. Kung hindi mo pa ito ginagamit, sundin muna ang Traefik reverse proxy at automatic TLS setup; gumagawa ito ng external Docker network (proxy sa ibaba) at isang ACME resolver (letsencrypt) kung saan nakakabit ang Vaultwarden service. Ang plain nginx na may hand-issued certificate ay may parehong epekto sa panig ng Vaultwarden.

Mas gusto ang nginx at Certbot kaysa sa Traefik? Ilagay ang Vaultwarden sa 127.0.0.1:8080 (magdagdag ng ports: ["127.0.0.1:8080:80"] sa service at tanggalin ang mga Traefik labels), pagkatapos ay mag-issue ng certificate at i-proxy ito. Ang tungkol sa certificate ay covered sa pag-issue ng Let's Encrypt certificates gamit ang Certbot at nginx. 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 na linya — ito ang nagpapahintulot sa Fail2ban na makita ang totoong attacker sa halip na 127.0.0.1. Ang lahat ng iba pang bahagi ng guide na ito ay pareho, Traefik man o nginx ang nasa harap.

Step 2 — ang Compose file

Gumawa muna ng project directory. Ginagamit ng guide na ito ang /opt/vaultwarden para maging predictable ang Compose project name — at ang data volume na vaultwarden_vw-data — dahil kailangan ang eksaktong pangalang ito para sa mga sumusunod na steps sa Fail2ban at backup.

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

Gumawa ng .env para sa admin secret at sa Compose file sa loob ng 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 malakas na hashed form; sapat na ang mahabang random string para sa simula.)

# 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 pundasyon ng buong design. Walang ports: mapping, kaya sa pamamagitan lamang ng Traefik at TLS ito ma-a-access ng Vaultwarden — ang pag-publish ng port nito sa host ang dahilan kung bakit aksidenteng naiseserve ang vault via http. At dapat ang DOMAIN ay ang buong public HTTPS URL: naka-embed ito sa attachment links, WebAuthn 2FA, at sa notifications endpoint, kaya masisira ang mga ito kapag mali o http ang value kahit pa gumagana ang site. Ang latest tag ay isang sadyang exception sa karaniwang never-latest rule — ang Vaultwarden ay naglalabas ng stable releases bilang isang single rolling image, habang ang :testing naman ang hiwalay na pre-release channel — kaya mag-update nang sadyang at basahin ang release notes bago mag-pull.

I-run ang container at i-monitor ang log:

docker compose up -d
docker compose logs -f vaultwarden

Ang matagumpay na start ay nagtatapos sa linyang katulad ng Rocket has launched from http://0.0.0.0:80. Bigyan ang Traefik ng ilang segundo para makuha 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.

Step 3 — isang malakas na ADMIN_TOKEN, at ang $$ trap

Pinoprotektahan ng ADMIN_TOKEN ang /admin, ang panel na may kakayahang magbasa ng lahat ng user at setting sa iyong instance, kaya ituring itong parang root password. May dalawang paraan para dito.

Ang simple form ay ang random string na na-generate mo na gamit ang openssl rand -base64 48. Dahil ang base64 ay hindi gumagamit ng $, maaari itong direktang ilagay sa .env nang walang escaping.

Ang hardened form ay isang Argon2 PHC hash, kaya hindi kailanman nakaimbak ang plaintext token sa disk. I-generate ang isa gamit ang parehong image:

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

Magtatanong ito nang dalawang beses at maglalabas ng string na nagsisimula sa $argon2id$v=19$.... Narito ang trap na nagpapatagal sa mga user ng isang oras: Itinuturing ng Docker Compose ang $ bilang variable interpolation, kaya dapat mong i-double ang bawat $ sa $$ kapag i-paste mo ang hash sa Compose file. Ilagay ito nang direkta 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 single $ signs, magbibigay ng warning ang Compose na The "argon2id" variable is not set at magiging blank ang token, kaya tatanggihan ng /admin ang iyong tamang password. I-run ang docker compose up -d, at i-save ang plaintext na tinype mo sa prompt sa iyong sariling password store.

Step 4 — i-register ang iyong account, pagkatapos ay i-lock ang pinto

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

Ngayon, isara ang pinto. I-edit ang Compose file para i-disable ang signups:

      SIGNUPS_ALLOWED: "false"

I-apply muli gamit ang docker compose up -d. Hindi ito mandatory na hardening at maaari itong ipagpaliban. Kung mananatiling bukas, kahit sino na makakahanap ng URL — kasama na ang mga crawler — ay makakagawa ng account sa iyong server. Hindi nila mababasa ang iyong vault, ngunit gagamit sila ng resources at gagawing open service ang iyong private instance. Ang senyales na nakabukas pa ito: ang /admin ay magpapakita ng mga account na hindi mo naman ginawa.

Para magdagdag ng pamilya o teammates sa hinaharap nang hindi muling binubuksan ang public signups, gamitin ang Invite User button sa /admin; kailangang naka-configure ang SMTP sa path na ito para matanggap ng invitee ang kanilang link.

Step 5 — pagpunta sa /admin

Pumunta sa https://vault.example.com/admin at i-enter ang plaintext admin token (ang random string, o ang password na iyong ni-hash — hindi ang hash mismo). Sa loob nito, maaari kang mag-list ng mga user, mag-adjust ng settings, magpadala ng test email, at kumuha ng database snapshot.

Kung ang page ay nag-return ng 404 Not Found, ang ADMIN_TOKEN ay empty o hindi naka-set, na nag-di-disable sa panel nang buo — isang valid na option kung hindi mo naman ito kailangan. Kung nag-load ito pero rejected ang iyong token, tingnan ang $$ escaping trap sa failure list sa ibaba. Nakalimutan ang token? Walang recovery prompt; i-edit ang .env o ang Compose file, mag-set ng bagong token, at docker compose up -d.

Step 6 — i-connect ang mga Bitwarden client

Ang bawat official client ay maaaring ituro sa isang self-hosted server. I-install ang Bitwarden desktop, mobile, o browser client mula sa mga standard na store — hindi mo kailangan ng special na Vaultwarden build.

Bago mag-login, i-click ang settings gear sa login screen (may label na Self-hosted o Region → Self-hosted), i-set ang Server URL sa https://vault.example.com, at i-save. Pagkatapos, mag-login gamit ang email at master password na iyong ni-register; dapat mag-connect agad ang client at mag-alok na i-fill at i-save ang mga credentials.

Kung nagpapakita ang client ng This is not a recognized Bitwarden server. You may need to check with your provider or update your server., mali ang URL, gumagamit ng http, o hindi trusted ang certificate — i-verify muna kung gumagana nang maayos ang https://vault.example.com sa isang browser. Ang mabagal na updates sa ibang devices ay dahil sa WebSocket push, na tatalakayin sa ibaba.

Nire-record ng Vaultwarden ang bawat failed login sa file na itinakda ng LOG_FILE — ito ang kailangan ng isang brute-force guard. Kung hindi ka pa gumagamit ng Fail2ban, ang installation at basics ay nasa the Fail2ban SSH hardening guide; dito ay magdadagdag tayo ng isang jail para sa vault.

Hanapin muna kung nasaan ang named volume sa host para mabasa ng Fail2ban ang log:

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

Maglalabas ito ng output na katulad ng /var/lib/docker/volumes/vaultwarden_vw-data/_data; ang log ay vaultwarden.log sa loob nito. I-create 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 i-confirm gamit ang sudo fail2ban-client status vaultwarden.

Tatlong Docker details ang magdidikta kung gagana ang proteksyon na ito. Una, kung ang log ay nagpapakita ng IP: 127.0.0.1 o ang address ng iyong proxy sa bawat failed attempt, ang iba-ban ng Vaultwarden ay ang proxy — i-set ang IP_HEADER sa header na ipinapadala ng iyong proxy (X-Forwarded-For para sa Traefik, X-Real-IP para sa nginx block sa itaas, CF-Connecting-IP kung nasa likod ng Cloudflare). Pangalawa, ang tamang iptables chain ay depende sa iyong proxy: kung ang Traefik ay tumatakbo bilang container na may published ports, dumadaan ang traffic sa Docker FORWARD path, kaya dapat nasa DOCKER-USER ang ban gaya ng nasa itaas; pero kung pinili mo ang host-nginx option mula sa Step 1, ang mga connection ay nagtatapos sa nginx sa host INPUT chain at hindi sila makikita ng isang DOCKER-USER ban — sa kasong ito, i-delete ang chain = DOCKER-USER line para gamitin ng Fail2ban ang default INPUT chain. Pangatlo, gamitin ang banaction = iptables-allports sa halip na ang port-based default — walang dine-define na port ang jail na ito, at ang isang all-ports ban sa DOCKER-USER ay malinis na iba-block ang offender sa lahat ng published service sa machine.

Step 8 — i-back up ang vault, pagkatapos ay i-restore ito

Ang vw-data volume ang iyong password manager. Naglalaman ito ng db.sqlite3 (bawat entry), ang attachments/ at sends/ directories, ang mga rsa_key.* files na nag-a-authenticate ng login sessions, at ang config.json mula sa admin panel. Mabibigo ang backup kung may makakaligtaang kahit isa sa mga ito.

Maaaring ma-capture ang corrupt na file kung kokopyahin ang db.sqlite3 habang nagsusulat ang Vaultwarden. Gumamit ng cold snapshot — ilang segundo lang ang downtime nito:

#!/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

I-set up ito sa cron nang nightly at i-copy ang .tgz palabas ng server — ang backup na nasa server lang na pinoprotektahan ay hindi maituturing na backup. Ang pinakamainam na paraan ay nightly restic backup sa ibang server o object storage, na nag-e-encrypt ng archive at nag-deduplicate ng mga paulit-ulit na snapshot. Ang Backup Database button sa admin panel ay mabilis na snapshot ng SQLite file lamang, ngunit hindi kasama ang mga attachment at keys.

Ngayon, ang proseso para mapatunayan kung gumagana ang backup — i-restore ito nang isang beses:

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, mag-tunnel gamit ang ssh -L 8888:127.0.0.1:8888 you@your-vps at buksan ang http://localhost:8888. Dahil ang localhost ay isang secure context, available ang crypto.subtle at mag-dedecrypt ang vault via plain http dito — ito lang ang tanging pinapayagang paraan. Mag-log in gamit ang iyong master password at i-verify kung nandoon ang iyong mga entry: kung nandoon sila, ang iyong database, RSA keys, at master password ay gumagana nang tama, at maaari ka nang mag-rebuild sa bagong VPS sa loob ng ilang minuto. I-stop ang container gamit ang Ctrl-C at i-delete ang /tmp/vw-restore.

Failure modes, kasama ang 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 via https:// at magdagdag ng HTTP-to-HTTPS redirect sa proxy.

This is not a recognized Bitwarden server... sa isang client. Ang Server URL ay http, may typo, o hindi trusted ang certificate; i-verify kung nagpapakita ang https://vault.example.com ng valid na padlock, pagkatapos ay i-re-enter ito sa self-hosted settings ng client.

/admin rejects the correct password. Nawala ang escaping ng Argon2 hash — dapat ay $$ ang bawat $ sa Compose — o ang hash ang nailagay mo sa halip na ang plaintext nito.

Mabagal na cross-device sync; ang console ay nagpapakita ng WebSocket connection to 'wss://vault.example.com/notifications/hub' failed. Hindi pino-forward ng proxy ang Upgrade/Connection headers; awtomatiko itong ginagawa ng Traefik, habang ang nginx ay nangangailangan ng dalawang upgrade lines mula sa Step 1. Gumagana pa rin ang vault, ngunit nag-si-sync lamang kapag binuksan. Wala na ang dating dedicated port na 3012 simula v1.31.0, kaya hindi na kailangan ang hiwalay na WebSocket route.

Nag-report ang Fail2ban ng ban pero tuloy ang koneksyon ng attacker. Bina-ban nito ang 127.0.0.1 dahil mali ang IP_HEADER, o ang ban ay nasa maling iptables chain — i-set ang chain = DOCKER-USER at banaction = iptables-allports.

Upgrades

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 mga release ang Vaultwarden. Mas mabuting i-monitor ang release notes ng project kaysa mag-pin ng patch version, dahil ang ilang release ay may kasamang migration notes. Gumawa muna ng bagong backup bago ang anumang major bump; maaari kang mag-roll back sa pamamagitan ng pag-restore ng tarball sa isang bagong volume.

FAQ

Ang Vaultwarden ba ay kapareho ng Bitwarden?

Isa itong compatible at independent na server, hindi ang official server. Ni-re-implement ng Vaultwarden ang Bitwarden server API gamit ang Rust. Dahil dito, gumagana ang official desktop, mobile, browser, at CLI clients dito gamit ang mas maliit na resources. Pareho ang vault format, kaya maaari kang mag-migrate sa kahit anong direksyon sa pamamagitan ng pag-export at pag-import.

Kailangan ko ba talaga ng HTTPS, o maaari itong patakbuhin via http sa aking LAN?

Kailangan mo ng HTTPS maliban na lang kung para sa localhost test ito. Ginagamit ng Bitwarden web vault at extensions ang Web Crypto API ng browser. Ang API na ito ay available lamang sa isang secure context. Dahil dito, maglalabas ng error na Cannot read properties of undefined ang client at hindi makakapag-login kung plain http ang gamit. Ang tanging http address na gumagana ay ang http://localhost, kaya gumagamit ng SSH tunnel sa restore test sa Step 8.

Paano ko mapipigilan ang pag-register ng mga hindi kakilala sa aking server?

I-set ang SIGNUPS_ALLOWED: "false" sa Compose file at i-run ang docker compose up -d agad pagkatapos gawin ang iyong sariling account. Pagkatapos nito, i-add ang mga bagong tao gamit ang Invite User button sa /admin. Kailangan ang SMTP configuration para matanggap nila ang invitation link. Suriin ang admin user list paminsan-minsan para masiguradong walang ibang account na nag-appear.

Paano ko i-ba-backup ang aking Vaultwarden vault?

Itigil muna nang panandalian ang container at i-archive ang buong vw-data volume — ang db.sqlite3, attachments/, sends/, config.json at ang rsa_key.* files — pagkatapos ay i-copy ang archive palabas ng server, mas mainam kung sa pamamagitan ng nightly cron. Delikadong mag-copy ng live SQLite file habang tumatakbo ang server dahil maaari itong maging corrupt, kaya i-backup ito nang naka-stop ang server. Pinakaimportante, i-restore ito minsan sa isang throwaway container at mag-log in, para masiguradong gumagana ang backup bago ito lubos na pagkatiwalaan.

Ligtas ba talaga ang pag-self-host ng aking mga password?

Oo, kung gagawin mo ang tatlong bagay na tatalakayin sa guide na ito: totoong HTTPS, saradong signups na may kasamang malakas na admin token, at mga tested na backup. Ang iyong vault ay encrypted client-side gamit ang iyong master password. Dahil dito, hindi kailanman makikita ng server ang iyong mga password nang hindi encrypted — walang silbi ang nakaw na db.sqlite3 kung wala ito. Ang kapalit nito ay responsibilidad mo na ang patching at backups, kaya ang Fail2ban at ang restore ritual ay hindi optional dito.

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