Jinsi ya kusakinisha Vaultwarden kwenye VPS kwa Docker

Unachojenga

Kidhibiti cha nywila unachomiliki kikamilifu: Vaultwarden inayofanya kazi kwenye container moja ndogo nyuma ya reverse proxy inayomalizia HTTPS, huku programu rasmi za Bitwarden kwenye simu, kompyuta na kivinjari chako zikielekezwa huko. Vaultwarden inatekeleza upya API ya seva ya Bitwarden kwa kutumia Rust na inatumia itifaki sawa na bitwarden.com, hivyo kila client rasmi inafanya kazi nayo bila mabadiliko, lakini inatumia takriban 100 MB ya RAM badala ya stack rasmi ya container nyingi.

Usakinishaji wenyewe ni mistari michache ya Compose. Mambo matatu ya msingi, ambayo yakikosewa husababisha hitilafu, ni haya: TLS lazima iwepo kabla hujapakia web vault, usajili wa umma lazima ufungwe mara tu akaunti yako itakapoundwa, na data volume lazima ihifadhiwe (backup) na kufanyiwa jaribio la kurejesha (restore), kwa sababu saraka hiyo moja inashikilia kila nywila unayomiliki.

Mahitaji ya awali na changamoto za kweli

• VPS yenye Docker Engine na Compose plugin, kwenye mashine mpya ya Ubuntu 24.04 KVM ukiwa na root au sudo. 512 MB ya RAM inatosha kabisa; 1 GB ni ya starehe. Hii ni moja ya huduma nyepesi zaidi unayoweza kuendesha, inashika nafasi za juu kwenye orodha fupi ya huduma zinazofaa kwa self-hosting. Hata hivyo, kadiria ukubwa wa mashine kulingana na huduma nyingine zitakazoshiriki rasilimali: kuweka maktaba ya picha ya self-hosted kama PhotoPrism au Immich kwenye VPS hiyo hiyo kutasukuma matumizi yako ya RAM kufikia gigabytes, wakati Vaultwarden haiongezi mzigo wowote. Hesabu hiyo hiyo inatumika kwa front ends za media utakazoongeza baadaye, kwa sababu kufanya maktaba ya Jellyfin ionekane kama duka la kukodisha la miaka ya 90 kunamaanisha container nyingine inayowaka muda wote pamoja na nafasi ya ziada ya transcoding kwenye bajeti hiyo hiyo.
• Domain yenye A record (pamoja na AAAA kama una IPv6) inayoelekeza vault.example.com kwenye VPS yako. Cheti cha TLS hutolewa kwa jina hili kamili, kwa hivyo DNS lazima iwe inafanya kazi kabla ya kuanza.
• Ports 80 na 443 zikiwa wazi kwa mtandao, zikisimamiwa na reverse proxy yako, kamwe zisielekezwe moja kwa moja kwa Vaultwarden. Port 80 hutumika tu kwa ajili ya ACME certificate challenge na kuelekeza HTTP kwenda HTTPS.
• Changamoto kubwa zaidi mwanzoni: Bitwarden clients hukataa kuwasiliana na seva ambayo si HTTPS. Hakuna njia ya "jaribu kwanza kwa http", njia hiyo haifanyi kazi, kwa sababu ya msingi inayoelezwa hapa chini.

Kwa nini Vaultwarden, si stack rasmi ya Bitwarden

Wateja ni wale wale, lakini uzito ni mdogo sana. Toleo rasmi la Bitwarden la kujihudumia (self-hosted) huja kama mkusanyiko wa container (MSSQL, Nginx, Identity, Api, Admin na nyinginezo) na huhitaji takriban 2 GB ya RAM. Vaultwarden ni binary moja inayohifadhi kila kitu kwenye database ya SQLite kwa chaguo-msingi na hutumia megabytes chache tu ikiwa imetulia. Kwa mtu mmoja, familia au timu ndogo, hii ndiyo chaguo dhahiri, na kwa sababu inatekeleza API ya Bitwarden kwa usahihi, data yako inabaki kuwa rahisi kuhamishika kati yake na bitwarden.com.

Unachokosa ni sehemu kubwa ya vipengele vya biashara: hakuna SCIM provisioning (ingawa OpenID Connect SSO ya majaribio ilianza kupatikana kuanzia toleo la 1.35.0), na wewe ndiye mwendeshaji, kwa hivyo kusasisha (patching), HTTPS na backups ni jukumu lako. Mwongozo huu unashughulikia kazi hizo tatu.

Kwa nini HTTPS si hiari

Bitwarden web vault na viendelezi vya kivinjari (browser extensions) hutengeneza funguo zako za usimbaji (encryption keys) ndani ya kivinjari kwa kutumia Web Crypto API (window.crypto.subtle). Vivinjari hutoa crypto.subtle pekee katika muktadha salama, yaani HTTPS, au kisa maalum cha http://localhost. Kupitia http://vault.example.com isiyo salama, kipengele hiki ni undefined, kwa hivyo programu inapojaribu kutengeneza ufunguo, inashindwa na konsole huonyesha:

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

Ukurasa hukwama au kuonyesha hitilafu ya jumla ya crypto, na hakuna kinachoingia (login). Wateja wa desktop, simu, na kivinjari hufanya ukaguzi wao wenyewe dhidi ya URL inayojiendesha (self-hosted), na dhidi ya endpoint ya http (au isiyoweza kufikiwa), wanakataa kwa ujumbe:

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

Zote zina sababu moja: hakuna HTTPS halali. Kwa hivyo, tunaweka TLS kwanza na hatufungui vault kamwe kupitia http, hata mara moja kwa ajili ya kuangalia haraka.

Hatua ya 1, DNS na reverse proxy (TLS kwanza)

Elekeza rekodi kwenye VPS yako na uhakikishe kuwa inatafsiriwa kwenda kwenye anwani sahihi:

dig +short vault.example.com

Mstari unaochapishwa lazima uwe IP ya VPS yako. Ikiwa ni tupu au si sahihi, rekebisha DNS na usubiri muda wa TTL uishe; utoaji wa cheti utafeli dhidi ya jina lisilotafsiriwa.

Kwa ajili ya HTTPS front end, mwongozo huu unatumia Traefik, ambayo hutoa na kuhuisha vyeti vya Let's Encrypt kiotomatiki na inafaa moja kwa moja kwenye Compose. Ikiwa huiendeshi tayari, fuata usanidi wa Traefik reverse proxy na TLS ya kiotomatiki kwanza; inatengeneza Docker network ya nje (proxy hapa chini) na ACME resolver (letsencrypt) ambayo huduma ya Vaultwarden huunganishwa nayo. Nginx ya kawaida yenye cheti kilichotolewa kwa mikono hufanya kazi vilevile kwa upande wa Vaultwarden.

Unapendelea nginx na Certbot badala ya Traefik? Weka Vaultwarden kwenye 127.0.0.1:8080 (ongeza ports: ["127.0.0.1:8080:80"] kwenye huduma na uondoe lebo za Traefik), kisha toa cheti na uifanyie proxy. Sehemu ya cheti imeelezwa katika utoaji wa vyeti vya Let's Encrypt kwa Certbot na nginx. Ziada muhimu ni WebSocket upgrade kwenye njia ya notifications:

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";
    }
}

Zingatia mstari wa X-Real-IP, ndio unaomruhusu Fail2ban baadaye kuona mshambuliaji halisi badala ya 127.0.0.1. Kila kitu kingine katika mwongozo huu ni sawa bila kujali kama Traefik au nginx imewekwa mbele.

Hatua ya 2, faili la Compose

Anza kwa kutengeneza saraka ya mradi. Mwongozo huu unatumia /opt/vaultwarden, ambayo hufanya jina la mradi wa Compose, na hivyo volume ya data, vaultwarden_vw-data, kuwa ya kutabirika; hatua za Fail2ban na backup zilizo hapa chini zinategemea jina hilo kamili.

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

Tengeneza .env kwa ajili ya siri ya admin na faili la Compose ndani ya saraka hiyo.

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

Tengeneza token hiyo kwa kutumia openssl rand -base64 48 na uibandike ndani. (Fomu iliyofanyiwa hashing kwa nguvu zaidi itajadiliwa baadaye; kamba ndefu ya herufi za kubahatisha inatosha kwa kuanzia.)

# 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

Mambo mawili kuhusu faili hili yanabeba usanifu mzima. Hakuna mapping ya ports:, kwa hivyo Vaultwarden inafikika tu kupitia Traefik na TLS yake; kuchapisha port yake kwenye host ndiyo njia ambayo watu hutumikia vault kupitia http kwa bahati mbaya. Na DOMAIN lazima iwe URL kamili ya umma ya HTTPS: inajengwa ndani ya viungo vya viambatisho, WebAuthn 2FA na endpoint ya notifications, kwa hivyo thamani isiyo sahihi au ya http huvunja vipengele hivyo hata kama tovuti inapakia. Tag ya latest ni ubaguzi wa makusudi kwa kanuni ya kawaida ya kutotumia latest, Vaultwarden husafirisha releases zake thabiti kama image moja inayojisasisha, huku :testing ikiwa ni chaneli tofauti ya kabla ya release, kwa hivyo sasisha kwa makusudi na usome maelezo ya release kabla ya kufanya pull. Hata hivyo, ubaguzi huo ni mdogo: container nyingi za muda mrefu ni bora zaidi zikifungwa kwenye tag kamili, jambo ambalo hufanya wakala anayewashwa kila wakati na kujiendesha kwenye VPS hiyo hiyo kuwa wa kutabirika wakati wa reboot na pull.

Iwashe na ufuatilie log:

docker compose up -d
docker compose logs -f vaultwarden

Kuanza kwa usahihi huishia na mstari kama Rocket has launched from http://0.0.0.0:80. Ipe Traefik sekunde chache ili ichukue cheti, kisha pakia https://vault.example.com, unapaswa kupata Bitwarden web vault ikiwa na padlock halali na bila onyo la cheti.

Hatua ya 3, ADMIN_TOKEN imara, na mtego wa $$

ADMIN_TOKEN inalinda /admin, paneli inayoweza kusoma kila mtumiaji na mpangilio kwenye instance yako, kwa hivyo ichukulie kama nenosiri la root. Njia mbili zinafanya kazi.

Njia rahisi ni mfuatano wa herufi nasibu uliotengeneza awali kwa kutumia openssl rand -base64 48. Kwa sababu base64 haina kamwe $, inaingia moja kwa moja kwenye .env bila kuhitaji escaping.

Njia iliyoimarishwa ni hash ya Argon2 PHC, kwa hivyo token ya maandishi ya kawaida (plaintext) haihifadhiwi kamwe kwenye diski. Tengeneza moja dhidi ya image hiyo hiyo:

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

Itakuomba uingize mara mbili na kuchapisha mfuatano unaoanza na $argon2id$v=19$.... Huu hapa ni mtego unaowapotezea watu saa nzima: Docker Compose inachukulia $ kama variable interpolation, kwa hivyo lazima uongeze $ mara mbili ili iwe $$ unapopaste hash hiyo kwenye faili la Compose. Iweke moja kwa moja chini ya environment:, si kupitia .env, na usiiweke kwenye alama za kunukuu (quotes):

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

Ukiacha alama moja ya $, Compose itatoa onyo la The "argon2id" variable is not set na kufuta token hiyo, na /admin itakataa nenosiri lako sahihi. Endesha docker compose up -d, na uhifadhi maandishi ya kawaida uliyochapa kwenye prompt katika hifadhi yako ya nenosiri.

Hatua ya 4, sajili akaunti yako, kisha funga mlango

Ukiwa na SIGNUPS_ALLOWED: "true", fungua https://vault.example.com, bofya Create account, na ujisajili kwa kutumia barua pepe yako na nenosiri kuu (master password) imara. Nenosiri hili kuu haliwezi kurejeshwa, hakuna njia ya kuliweka upya, kwa hivyo lihifadhi mahali salama na pa kudumu kwanza.

Sasa funga mlango. Hariri faili ya Compose ili kuzima usajili:

      SIGNUPS_ALLOWED: "false"

Tekeleza mabadiliko kwa kutumia docker compose up -d. Hii si hatua ya usalama unayoweza kuiahirisha. Ikiachwa wazi, mtu yeyote anayepata URL hiyo, na roboti za utafutaji (crawlers) hufanya hivyo, anaweza kuunda akaunti kwenye seva yako. Hawawezi kusoma vault yako, lakini wanatumia rasilimali na kugeuza mfumo wako binafsi kuwa huduma ya wazi. Ishara kwamba uliacha usajili wazi ni: /admin kuorodhesha akaunti ambazo hukuziumba wewe.

Ili kuongeza wanafamilia au wenzako baadaye bila kufungua usajili wa umma, tumia kitufe cha Invite User katika /admin; njia hiyo inahitaji SMTP kusanidiwa ili mwalikwa apokee kiungo chake.

Hatua ya 5, kufikia /admin

Nenda kwenye https://vault.example.com/admin na uweke plaintext admin token (mfululizo wa herufi nasibu, au nenosiri ulilolifanyia hashing, siyo hash yenyewe). Ukiwa ndani unaweza kuorodhesha watumiaji, kurekebisha mipangilio, kutuma barua pepe ya majaribio na kuchukua snapshot ya database.

Ikiwa ukurasa unarudisha 404 Not Found, basi ADMIN_TOKEN haina kitu au haijawekwa, jambo ambalo huzima paneli hiyo kabisa, na hilo ni chaguo sahihi ikiwa hutaihitaji kamwe. Ikiwa ukurasa unapakia lakini unakataa token yako, angalia mtego wa escaping wa $$ katika orodha ya makosa hapa chini. Umesahau token? Hakuna sehemu ya kuirejesha; hariri .env au faili ya Compose, weka token mpya, kisha fanya docker compose up -d.

Hatua ya 6, unganisha wateja wa Bitwarden

Kila mteja rasmi anaweza kuelekezwa kwenye seva unayojiendeshea mwenyewe, kwa hivyo sakinisha mteja wa Bitwarden wa desktop, simu, au kivinjari kutoka kwenye maduka ya kawaida; huhitaji toleo maalum la Vaultwarden.

Kabla ya kuingia, fungua ikoni ya mipangilio kwenye skrini ya kuingia (iliyopewa jina la Self-hosted au Region → Self-hosted), weka Server URL kuwa https://vault.example.com, kisha uhifadhi. Baada ya hapo, ingia kwa kutumia barua pepe na nenosiri kuu ulilojisajili nalo; mteja anapaswa kuunganishwa mara moja na kutoa ofa ya kujaza na kuhifadhi vitambulisho.

Ikiwa mteja ataonyesha This is not a recognized Bitwarden server. You may need to check with your provider or update your server., URL si sahihi, inatumia http, au cheti hakiaminiki; hakikisha kwanza kuwa https://vault.example.com inafunguka vizuri kwenye kivinjari. Usasishaji wa polepole kwenye vifaa vingine unatokana na WebSocket push, ambayo imeelezewa hapa chini.

Hatua ya 7, jail ya Fail2ban kwa ajili ya endpoint ya kuingia (login)

Vaultwarden hurekodi kila jaribio lililofeli la kuingia kwenye faili lililowekwa na LOG_FILE, jambo ambalo ni muhimu kwa ajili ya kuzuia mashambulizi ya brute-force. Ikiwa huendeshi Fail2ban tayari, usakinishaji na misingi yake vinapatikana katika mwongozo wa kuimarisha usalama wa SSH kwa Fail2ban; hapa tunaongeza jail moja kwa ajili ya vault.

Kwanza tafuta mahali ambapo named volume inapoishi kwenye host, ili Fail2ban iweze kusoma log:

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

Hiyo itachapisha kitu kama /var/lib/docker/volumes/vaultwarden_vw-data/_data; log yenyewe ni vaultwarden.log ndani yake. Unda filter:

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

Na 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

Pakia upya kwa kutumia sudo systemctl restart fail2ban na uthibitishe kwa sudo fail2ban-client status vaultwarden.

Maelezo matatu ya Docker huamua kama hii inalinda chochote. Kwanza, ikiwa log inaonyesha IP: 127.0.0.1 au anwani ya proxy yako kwenye kila jaribio lililofeli, Vaultwarden inazuia proxy, weka IP_HEADER kwenye header ambayo proxy yako inatuma kweli (X-Forwarded-For kwa Traefik, X-Real-IP kwa block ya nginx hapo juu, CF-Connecting-IP nyuma ya Cloudflare). Pili, iptables chain sahihi inategemea proxy yako: ikiwa Traefik inaendeshwa kama container yenye ports zilizochapishwa, trafiki hupitia njia ya FORWARD ya Docker, kwa hivyo ban lazima ikae kwenye DOCKER-USER kama ilivyo hapo juu; lakini ikiwa ulichagua chaguo la host-nginx kutoka Hatua ya 1, miunganisho hukomea kwenye nginx kwenye chain ya INPUT ya host na ban ya DOCKER-USER haitawaona kamwe, katika hali hiyo futa mstari wa chain = DOCKER-USER ili Fail2ban itumie chain ya kawaida ya INPUT. Tatu, tumia banaction = iptables-allports badala ya chaguo-msingi la msingi wa port, jail hii haifafanui port yoyote, na ban ya all-ports katika DOCKER-USER huzuia mshambuliaji kwa usafi kutoka kwa kila huduma iliyochapishwa kwenye mashine hiyo.

Hatua ya 8, hifadhi nakala ya vault, kisha uirejeshe ili kuhakikisha inafanya kazi

Volume ya vw-data ndiyo meneja wako wa nywila. Inashikilia db.sqlite3 (kila ingizo), saraka za attachments/ na sends/, faili za rsa_key.* zinazotia saini vikao vya kuingia, na config.json kutoka kwenye paneli ya admin. Nakala ya hifadhi inayoruka mojawapo ya haya itafeli wakati unapoiitaji.

Kunakili db.sqlite3 wakati Vaultwarden inaandika kunaweza kunasa faili iliyoandikwa nusu au iliyoharibika, kwa hiyo chukua snapshot ya baridi (cold snapshot), muda wa kutokuwepo kwa huduma ni sekunde chache tu:

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

Iendeshe kupitia cron kila usiku na unakili .tgz nje ya seva hiyo; nakala ya hifadhi inayokaa kwenye seva unayoilinda si nakala ya hifadhi. Njia safi ya kuisafirisha ni nakala ya hifadhi ya kila usiku ya restic kwenda kwenye seva nyingine au object storage, ambayo husimba archive kwa njia fiche na kuondoa marudio ya snapshots kwa ajili yako. Kitufe cha Backup Database kwenye paneli ya admin ni njia rahisi ya kuchukua snapshot ya faili ya SQLite pekee, lakini huacha viambatisho na funguo (keys).

Sasa, ibada inayotofautisha nakala ya hifadhi ya kweli na ile ya matumaini, irejeshe mara moja na uthibitishe kuwa inafanya kazi:

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

Kutoka kwenye laptop yako, tengeneza tunnel kwenda kwenye seva hiyo kwa kutumia ssh -L 8888:127.0.0.1:8888 you@your-vps na ufungue http://localhost:8888. Kwa sababu localhost ni muktadha salama, crypto.subtle inapatikana na vault inafunguka (decrypt) kupitia http ya kawaida hapa, mahali pekee panaporuhusiwa. Ingia na nywila yako kuu (master password) na uthibitishe kuwa maingizo yako yapo: kama yapo, database yako, funguo za RSA na nywila kuu zote zimerudi salama, na unaweza kujenga upya kwenye VPS mpya ndani ya dakika chache. Simamisha container kwa Ctrl-C na ufute /tmp/vw-restore. Dumisha mazoea hayo ya tunnel kwa ajili ya UI nyingine yoyote ya admin kwenye seva ambayo haipaswi kamwe kukabili mtandao, ambayo ndiyo njia unayoweza kufikia skana ya usalama ya open-kritt inayojiendesha kwenye port 5173 pia.

Njia za kufeli, pamoja na ujumbe utakaouona

Cannot read properties of undefined (reading 'importKey') kwenye console ya kivinjari. Vault ilipakiwa kupitia http, kwa hivyo crypto.subtle haijafafanuliwa; ifikie kupitia https:// pekee na uongeze HTTP-to-HTTPS redirect kwenye proxy.

This is not a recognized Bitwarden server... kwenye mteja (client). Server URL ni http, imekosewa kuandikwa, au cheti hakiaminiki; thibitisha https://vault.example.com inaonyesha alama ya kufuli iliyo sahihi, kisha iingize tena katika mipangilio ya self-hosted ya mteja.

/admin inakataa nenosiri sahihi. Argon2 hash imepoteza escaping yake, kila $ lazima iwe $$ katika Compose, au uliingiza hash badala ya maandishi ya kawaida (plaintext) inayowakilisha.

Usawazishaji (sync) wa vifaa mbalimbali ni wa polepole; console inaonyesha WebSocket connection to 'wss://vault.example.com/notifications/hub' failed. Proxy haisambazi vichwa (headers) vya Upgrade/Connection; Traefik hufanya hivi kiotomatiki, nginx inahitaji mistari miwili ya upgrade kutoka Hatua ya 1. Vault bado inafanya kazi, inasawazisha tu wakati wa kufungua. Port maalum ya zamani ya 3012 haipo tena tangu v1.31.0, kwa hivyo hakuna njia (route) ya WebSocket tofauti inayohitajika.

Fail2ban inaripoti ban lakini mshambuliaji anaendelea kuunganishwa. Inazuia 127.0.0.1 kwa sababu IP_HEADER si sahihi, au ban hiyo iko kwenye mnyororo (chain) wa iptables usio sahihi, weka chain = DOCKER-USER na banaction = iptables-allports.

Uboreshaji

Vuta image mpya na uunde upya; named volume na data zako zote zitabaki kama zilivyo:

docker compose pull
docker compose up -d

Vaultwarden hutoa releases mara kwa mara. Fuatilia maelezo ya release ya mradi huu badala ya kufunga toleo mahususi la patch, kwa sababu baadhi ya releases huwa na maelekezo ya migration. Tengeneza backup mpya kabla ya kufanya uboreshaji wowote mkubwa; unaweza kurudi kwenye toleo la awali kwa kurejesha tarball kwenye volume mpya.

FAQ

Je, Vaultwarden ni sawa na Bitwarden?

Ni seva inayooana na inayojitegemea, si ile rasmi. Vaultwarden inatekeleza upya API ya seva ya Bitwarden kwa kutumia Rust, hivyo wateja rasmi wa desktop, simu, kivinjari na CLI wote hufanya kazi nayo, kwa kutumia rasilimali chache sana ikilinganishwa na mfumo rasmi. Muundo wa vault ni uleule, hivyo unaweza kuhama upande wowote kwa kusafirisha (export) na kuingiza (import) data.

Je, ninahitaji HTTPS kweli, au ninaweza kuitumia kupitia http kwenye LAN yangu?

Unahitaji HTTPS kwa kila kitu isipokuwa kwa jaribio la localhost. Vault ya wavuti ya Bitwarden na viendelezi vyake hutumia Web Crypto API ya kivinjari, ambayo inapatikana tu katika muktadha salama, hivyo kupitia http ya kawaida mteja hutoa Cannot read properties of undefined na hawezi kuingia. Anwani pekee ya http inayofanya kazi ni http://localhost, ndiyo maana jaribio la kurejesha data katika Hatua ya 8 linatumia SSH tunnel.

Ninawezaje kuwazuia wageni kujisajili kwenye seva yangu?

Weka SIGNUPS_ALLOWED: "false" katika faili ya Compose na uendeshe docker compose up -d, mara tu baada ya kutengeneza akaunti yako mwenyewe. Kuanzia hapo, ongeza watu wapya kupitia kitufe cha Invite User katika /admin, ambacho kinahitaji SMTP kusanidiwa ili wapokee kiungo cha mwaliko. Kagua orodha ya watumiaji wa admin mara kwa mara ili kuthibitisha kuwa hakuna akaunti zisizotarajiwa zilizojitokeza.

Ninawezaje kuhifadhi nakala (backup) ya vault yangu ya Vaultwarden?

Simamisha kontena kwa muda na uhifadhi (archive) ujazo mzima wa vw-data, db.sqlite3, attachments/, sends/, config.json na faili za rsa_key.*, kisha nakili nakala hiyo nje ya seva, ikiwezekana kupitia cron ya kila usiku. Kunakili faili ya SQLite inayotumika wakati seva inafanya kazi kuna hatari ya kupata snapshot iliyoharibika, hivyo ifanye wakati seva imesimama. Muhimu zaidi, irejeshe mara moja kwenye kontena la majaribio na uingie, ili ujue kuwa nakala hiyo ni halisi kabla ya kuitegemea.

Je, ni salama kweli kuhifadhi nywila zangu mwenyewe?

Ndiyo, unapofanya mambo matatu ambayo mwongozo huu unashughulikia: HTTPS halisi, usajili uliofungwa pamoja na token ya admin yenye nguvu, na nakala za chelezo zilizojaribiwa. Vault yako imesimbwa kwa njia fiche upande wa mteja (client-side) kwa kutumia nywila yako kuu, hivyo hata seva haiwezi kuona nywila zako zikiwa wazi; db.sqlite3 iliyoibiwa haina maana bila nywila hiyo. Hasara yake ni kwamba kusasisha (patching) na nakala za chelezo sasa ni jukumu lako, ndiyo maana Fail2ban na utaratibu wa kurejesha data si wa hiari hapa. Mara tu mambo hayo yakiwa yamewekwa, uchunguzi wa kina wa mahali ambapo vault inayojiendesha inaweza kushambuliwa ni hatua inayofuata yenye manufaa, kwa sababu kwa vile data zenyewe zimesimbwa kwa njia fiche ndani ya mteja, kilichobaki kulindwa ni token ya admin na nakala ya chelezo.