Je, Vaultwarden ni salama kwa matumizi ya kibinafsi?

Je, Vaultwarden ni salama? Jibu fupi

Vaultwarden ni salama katika sehemu moja muhimu zaidi, kwa sababu kila kitu kilichohifadhiwa kwenye vault husimbwa kwa njia fiche (encrypted) kwenye kifaa chako kabla ya kufika kwenye seva. Seva huhifadhi data ambazo haiwezi kuzisoma. Mtu anayenakili hifadhidata nzima bado atahitaji master password ili kupata chochote chenye manufaa kutoka humo.

Jibu hilo linabeba uzito mkubwa, na sehemu zinazoweza kuvunjika ni zile unazozisanidi wewe mwenyewe. Jopo la usimamizi (admin panel) lililofichwa nyuma ya token inayoweza kubahatishwa. Port ya container iliyochapishwa kwenye Internet nzima. config.json iliyo katika maandishi wazi (plaintext). Faili ya backup iliyohifadhiwa kwenye home directory ya seva hiyo hiyo. Hakuna kati ya hayo yanayohusiana na matatizo ya kriptografia. Yote hayo ndiyo sababu vault zinazojiendesha (self-hosted) huweza kuibiwa.

Kila kitu hapa chini kinachukulia kuwa una usakinishaji unaofanya kazi. Ikiwa bado huna, isanidi kwanza kwa kutumia mwongozo wa usakinishaji wa Vaultwarden kwa VPS, kisha urudi na ufuate orodha hii kwa mpangilio.

Yale ambayo seva huhifadhi kihalisi

Vaultwarden hutumia mfumo wa data wa Bitwarden. Jina la kitu kilichohifadhiwa, jina la mtumiaji, nenosiri, madokezo na URIs husimbwa kwa njia fiche kwa kutumia ufunguo unaotokana na nenosiri lako kuu, ndani ya kifaa cha mteja, kabla ya ombi lolote kutumwa. Maudhui ya faili zilizounganishwa husimbwa kwa njia hiyo hiyo. Seva hupokea data isiyosomeka ikiwa na UUID (kitambulisho cha kipekee duniani) kilichounganishwa nayo.

Baadhi ya vitu si maandishi yaliyosimbwa (ciphertext), na unapaswa kujua ni yapi hasa:

• Anwani yako ya barua pepe ya akaunti, katika maandishi ya kawaida (plaintext).
• Mipangilio yako ya KDF (key derivation function) na salt, kwa sababu mteja anahitaji vitu hivi ili kuunda upya ufunguo wakati wa kuingia tena.
• Hash ya upande wa seva ya hash ya nenosiri kuu inayotumwa na mteja, inayotumiwa kuthibitisha kuingia kwenyewe.
• Metadata: uanachama wa shirika, majina ya vifaa, nyakati za mwisho za kuingia.
• Siri ya njia ya uthibitishaji wa hatua mbili (2FA) inayolinda kuingia kwa Vaultwarden. Hii hukaa katika jedwali la twofactor bila kusimbwa, kwa sababu seva lazima ihesabu msimbo unaotarajiwa ili kuulinganisha na wako. Hii si sawa na siri ya TOTP (time-based one-time password) unayohifadhi ndani ya kitu cha vault, ambayo husimbwa kama sehemu nyingine yoyote.

Folda ya data ni ndogo. Katika usakinishaji wa Docker, ni ile uliyoiweka kwenye /data.

sudo ls -l /vw-data/

db.sqlite3 hushikilia karibu hali yote ya mfumo. attachments/ hushikilia faili zilizopakiwa, moja kwa kila UUID, na ndiyo daraja pekee muhimu la data ambalo halikai kwenye majedwali ya hifadhidata. sends/ hushikilia viambatisho vya Send na imekusudiwa kuwa ya muda. icon_cache/ ni ya kutupwa. rsa_key.pem na faili zake nyingine husaini JWTs (JSON web tokens) za watumiaji walioingia, kwa hivyo nakala ya ufunguo huo wa faragha inaweza kutumika kughushi kipindi cha kuingia kwenye vault. config.json huwepo tu pindi unapowasha ukurasa wa admin, na mradi huu uko wazi kuhusu hilo: hushikilia token ya admin na vitambulisho vyako vya SMTP katika maandishi ya kawaida (plaintext).

Kwa hivyo, mfano wa vitisho vya kivitendo ni ufikiaji wa mfumo wa faili, si usimbaji fiche wa mtandao. Ufikiaji wa kusoma wa saraka hiyo moja hutoa anwani ya barua pepe ya kila mtumiaji, siri zao za 2FA za kuingia, ufunguo unaoweza kughushi vipindi vya kuingia, na nakala ya nje ya mtandao ya kila vault ili kushambuliwa wakati wowote. Kila hatua hapa chini ipo ili kuwazuia watu wasiingie kwenye saraka hiyo.

Rekebisha token ya admin kwanza

/admin ni jopo kamili la udhibiti: orodha ya watumiaji, mialiko, ufutaji, na kila mpangilio wa runtime. Inalindwa na siri moja ya pamoja na hakuna kingine. Hakuna jina la mtumiaji. Hakuna uthibitishaji wa hatua mbili (2FA) kwa kila mtumiaji.

Miongozo ya zamani inakuambia utengeneze ADMIN_TOKEN kwa kutumia openssl rand -base64 48. Hiyo inafanya kazi, na inaandika siri hiyo kwa maandishi ya kawaida (plaintext) ndani ya config.json na kwenye faili yako ya compose. Vaultwarden pia inakubali kamba ya Argon2 PHC (password hashing competition), kwa hivyo thamani inayohifadhiwa ni hash badala yake. Tengeneza moja dhidi ya container inayofanya kazi:

docker exec -it vaultwarden /vaultwarden hash

Au bila kugusa container inayofanya kazi kabisa:

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

Inakuomba nenosiri mara mbili, kisha inachapisha mstari unaoanza na $argon2id$. Kwenye usakinishaji wa bare-metal, endesha ./vaultwarden hash. Ikiwa ungependelea kutumia argon2 CLI moja kwa moja, mradi huo unaandika vigezo vya chini vya OWASP:

echo -n 'MySecretPassword' | argon2 "$(openssl rand -base64 32)" -e -id -k 19456 -t 2 -p 1

Sasa mtego unaowagharimu watu saa moja. Kamba ya PHC imejaa herufi za $, na Docker Compose inachukulia $ kama interpolation ya variable. Ukiibandika bila kuikwepa (unescaped) kwenye block ya environment:, thamani inayofika kwenye container inaharibika, kwa hivyo /admin inakataa token unayojua ni sahihi. Kuna njia mbili salama. Katika docker-compose.yml, rudufu kila $:

environment:
  ADMIN_TOKEN: $$argon2id$$v=19$$m=19456,t=2,p=1$$UUZxK1FZMkZoRHFQRlVrTXZvS0E3bHpNQW55c2dBN2NORzdsa0Nxd1JhND0$$cUoId+JBUsJutlG4rfDZayExfjq4TCt48aBc9qsc3UI

Katika faili ya .env, hakuna haja ya kukwepa (escaping), lakini tumia alama za kunukuu moja (single quotes):

ADMIN_TOKEN='$argon2id$v=19$m=65540,t=3,p=4$MmeKRnGK5RW5mJS7h3TOL89GrpLPXJPAtTK8FTqj9HM$DqsstvoSAETl9YhnsXbf43WeaUwJC6JhViIvuPoig78'

Kisha weka kikomo cha kasi (rate limit) kwenye jopo na ufupishe session yake:

ADMIN_RATELIMIT_SECONDS=300
ADMIN_RATELIMIT_MAX_BURST=3
ADMIN_SESSION_LIFETIME=20

Majaribio matatu mabaya ndani ya dakika tano na jopo litaacha kujibu mteja huyo. Session ya admin inaisha baada ya dakika 20 ya kutofanya kazi.

Ni bora kuliko yote haya: zima ukurasa huo. Instance nyingi zinauhitaji mara moja tu, ili kusanidi SMTP na kualika watumiaji wa kwanza, na si tena. Ili kuuzima, usiweke ADMIN_TOKEN wala DISABLE_ADMIN_TOKEN, ondoa ufunguo wowote wa "admin_token" kutoka config.json, kisha unda upya container. Kufuta ufunguo kutoka kwenye faili ni muhimu kwa sababu ukurasa wa admin huandika mipangilio hapo, na kile kilicho kwenye config.json kinashinda mazingira (environment). Kuondoa variable pekee kutauacha ukurasa wazi.

Funga usajili kabla mtu yeyote hajapata kikoa chako

SIGNUPS_ALLOWED=false
SIGNUPS_VERIFY=true
SHOW_PASSWORD_HINT=false

SIGNUPS_ALLOWED imewekwa kuwa true kwa chaguo-msingi. Ikiachwa hivyo, mtu yeyote anayefika kwenye kikoa chako anaweza kutengeneza akaunti, na data zao zitahifadhiwa kwenye db.sqlite3 sawa na zako. Iweke kuwa false na uwaongeze watu kupitia mialiko kutoka kwenye ukurasa wa admin, jambo linalohitaji SMTP inayofanya kazi. INVITATIONS_ALLOWED pia imewekwa kuwa true kwa chaguo-msingi na inaruhusu wamiliki wa mashirika kuwaalika wengine. Hii ni sawa ikiwa unawaamini watumiaji wako, na inapaswa kuwa false kwenye instance ya mtumiaji mmoja. Ikiwa ni vikoa fulani tu vinavyopaswa kusajili, SIGNUPS_DOMAINS_WHITELIST=example.com ni finyu zaidi kuliko usajili wa wazi na ni dhaifu zaidi kuliko mialiko.

SHOW_PASSWORD_HINT imewekwa kuwa false kwa chaguo-msingi na inapaswa kubaki hivyo. Ikiwa imewashwa, kuandika anwani ya barua pepe halali kwenye fomu ya kuingia kutatoa dokezo la nenosiri kuu la akaunti hiyo, jambo ambalo linafichua dokezo hilo na kuthibitisha kuwa anwani hiyo ipo.

Ikiwa instance yako iliendeshwa huku usajili ukiwa wazi kwa muda wowote, fungua ukurasa wa admin na usome orodha ya watumiaji kabla ya kudhani kuwa wewe ndiye mtumiaji pekee uliopo.

Porti uliyokusudia kutochapisha

Docker image husikiliza kwenye port 80 ndani ya container. Ufungaji wa bare-metal hutumia ROCKET_PORT=8000 kama chaguo-msingi. Amri ya run iliyoandikwa kwenye nyaraka huichapisha hivi:

--publish 127.0.0.1:8000:80

Kiambishi 127.0.0.1: ndicho kiini cha jambo hili. Andika -p 8000:80 badala yake na Docker itafunga 0.0.0.0, na inafanya hivyo kwa kuandika sheria za DNAT (destination network address translation) kwenye jedwali la nat. Sheria hizo hupitiwa kabla ya chains za filter ambazo ufw huzisimamia, kwa hivyo ufw status huripoti port hiyo kuwa imekataliwa wakati port hiyo inajibu mtandao kwa furaha. Utaratibu kamili unastahili kusomwa katika mwongozo wa jinsi port za Docker zinavyokwepa ufw.

Kagua kile kinachosikiliza kweli:

sudo ss -tlnp | grep 8000

Matokeo mazuri ni mstari mmoja uliounganishwa kwenye 127.0.0.1:8000. Mstari uliounganishwa kwenye 0.0.0.0:8000 inamaanisha kuwa vault imefichuliwa moja kwa moja. Rekebisha mapping, kisha uunde upya container, kwa sababu port binding huwekwa wakati container inaundwa na docker compose restart haitaibadilisha:

docker compose up -d --force-recreate

Port moja zaidi imesalia katika miongozo ya zamani: 3012, port tofauti ya WebSocket. Usaidizi wake uliondolewa katika Vaultwarden 1.31.0, kwa sababu trafiki ya notification ilihamia kwenye port kuu ya HTTP. WEBSOCKET_ENABLED na WEBSOCKET_PORT zimepuuzwa tangu 1.29.0. Swichi ya sasa ni ENABLE_WEBSOCKET, ambayo chaguo-msingi lake ni true. Ikiwa firewall yako au faili ya compose bado inafungua 3012, ifunge.

Terminate TLS at a reverse proxy, not in Rocket

Vaultwarden can serve TLS (transport layer security) itself through Rocket, its web framework, and the project tells you not to in production. Rocket's built-in TLS lacks strict SNI (server name indication) support, which is also why the hardening advice is to reach your instance by hostname and never by bare IP address. Public IP ranges are scanned constantly, and a vault that answers on an IP address is a vault that gets found.

The parts of an nginx server block that matter:

client_max_body_size 525M;

location / {
  proxy_pass http://127.0.0.1:8000;
  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_set_header Upgrade $http_upgrade;
  proxy_set_header Connection $connection_upgrade;
}

nginx defaults client_max_body_size to 1 MB, so without that line an attachment upload fails with 413 Request Entity Too Large in the nginx error log while Vaultwarden logs nothing at all. The Upgrade and Connection headers carry the WebSocket handshake to /notifications/hub. Drop them and the vault still works, and changes stop appearing on your other devices until you reload the page by hand.

Caddy is shorter and obtains the certificate on its own:

vw.example.com {
  reverse_proxy 127.0.0.1:8000 {
    header_up X-Real-IP {remote_host}
  }
}

Then tell Vaultwarden about it:

DOMAIN=https://vw.example.com
IP_HEADER=X-Real-IP

IP_HEADER already defaults to X-Real-IP, so the job is making sure the proxy actually sets that header. If it does not, every log line and every login rate limit sees 127.0.0.1, the proxy itself, which means one attacker's failures are counted against every user on the instance. Set DOMAIN to the real https URL too, because Vaultwarden builds invitation and password reset links from it, and WebAuthn security keys are bound to that origin.

One detail people miss: the WebSocket connection passes the session token in the query string, as /notifications/hub?access_token=[JWT]. That lands in your proxy access log in the clear. Redact the access_token parameter in the log format, or make sure those logs are not shipped anywhere you do not control.

Zuia mashambulizi ya brute force kwenye endpoint ya kuingia

Rate limits zimewashwa kwa chaguo-msingi (LOGIN_RATELIMIT_SECONDS=60, LOGIN_RATELIMIT_MAX_BURST=10). Hizi hupunguza kasi ya mshambuliaji. Hazimsimamishi kabisa. fail2ban hufanya hivyo, lakini Vaultwarden inapaswa kuandika faili ya logi kwanza, na haifanyi hivyo kwa usanidi wa awali:

LOG_FILE=/data/vaultwarden.log
LOG_LEVEL=info
EXTENDED_LOGGING=true

Jaribio lililoshindwa la kuingia hutoa mstari mmoja kamili, na huu ndio mfuatano wa herufi ambao kichujio chako kinapaswa kuulinganisha:

[2026-08-07 09:14:22][vaultwarden::api::identity][ERROR] Username or password is incorrect. Try again. IP: 203.0.113.10. Username: user@example.com.

Andika kichujio kwenye /etc/fail2ban/filter.d/vaultwarden.local:

[INCLUDES]
before = common.conf

[Definition]
failregex = ^.*?Username or password is incorrect\. Try again\. IP: <ADDR>\. Username:.*$
ignoreregex =

Na jail kwenye /etc/fail2ban/jail.d/vaultwarden.local:

[vaultwarden]
enabled = true
port = 80,443
filter = vaultwarden
banaction = %(banaction_allports)s
logpath = /vw-data/vaultwarden.log
maxretry = 3
bantime = 14400
findtime = 14400

Ikiwa ulihifadhi ukurasa wa admin, ongeza jail ya pili ambayo failregex yake ni ^.*Invalid admin token\. IP: <ADDR>.*$, kwa sababu makosa ya admin huandikwa kwa ujumbe tofauti na kichujio cha kuingia hakitayaona. Kisha kagua kazi yako:

sudo systemctl restart fail2ban
sudo fail2ban-client status vaultwarden

Jail inayofanya kazi huorodhesha faili yako ya logi chini ya File list na kuripoti Currently failed: 0. Ingiza nenosiri lisilo sahihi mara tatu kutoka mtandao tofauti na kaunta hiyo itaongezeka, kisha anwani hiyo itaonekana chini ya Banned IP list. Ikiwa kaunta haisogei kamwe, sababu ya kawaida ni logpath: lazima iwe njia ya faili kwenye host, si njia ya /data/... ndani ya container. Sababu ya pili ya kawaida ni kukosekana kwa X-Real-IP, jambo linalofanya kila zuio kulenga proxy yako mwenyewe. Usanidi uliosalia, ikiwemo SSH jail ambayo unapaswa kuwa unaiendesha tayari, uko kwenye mwongozo wa fail2ban kwa Ubuntu 24.04.

Nenosiri kuu bado ndilo msingi wa mfumo mzima

Ufumbaji wa data upande wa mteja (client-side encryption) unamaanisha kuwa nenosiri kuu ndilo ufunguo. Nenosiri kuu fupi kwenye mfumo ambao hifadhidata yake imenakiliwa na mshambuliaji halilindwi na chochote katika makala hii, kwa sababu wanashambulia nakala hiyo nje ya mtandao kwa kasi yoyote ile inayoruhusiwa na maunzi yao. Hakuna mpangilio wowote wa seva unaoweza kufika kwenye mashine ya mshambuliaji.

PASSWORD_ITERATIONS=600000 ni idadi ya marudio ya KDF inayotolewa kwa wateja wanapofungua akaunti mpya. Akaunti zilizopo huhifadhi thamani ile ile zilizoundiwa nayo, kwa hivyo kuiongeza hakubadilishi chochote kwa watumiaji waliojiunga mwaka jana. Ni lazima wao wenyewe waibadilishe katika mipangilio ya usalama ya web vault, jambo ambalo hufumbua upya ufunguo wao. Wataarifu, kwa sababu hakuna kitu katika kiolesura kitakachowafahamisha.

Kisha wezesha uthibitishaji wa hatua mbili (two-factor authentication) kwa kila akaunti. Hii haikulindi matini fiche (ciphertext), kwa sababu ufunguo wa vault hutokana na nenosiri kuu pekee. Hata hivyo, inazuia nenosiri lililoibwa kutosheleza kuingia na kusawazisha nakala. REQUIRE_DEVICE_EMAIL=true huongeza hatua ya uthibitisho kwa barua pepe mara ya kwanza akaunti inapoingia kutoka kwenye kifaa kisichotambulika.

Backup ndipo mahali ambapo vault zinazojiendesha (self-hosted) hukosea

tar czf ya folda ya data, ikihifadhiwa kwenye home directory ya VPS hiyo hiyo, inabatilisha kila hatua iliyotajwa hapo juu. Kumbukumbu hiyo (archive) ina db.sqlite3 yenye ciphertext ya kila mtumiaji, rsa_key.pem inayoweza kughushi session za kuingia, na config.json yenye admin token na nenosiri la SMTP katika mfumo wa maandishi wazi (plaintext). Kupata idhini ya kusoma faili hiyo moja kunamaanisha kupata idhini ya kusoma vault nzima.

Kuna kanuni mbili za kuzingatia. Ondoa kumbukumbu hiyo kwenye seva hiyo. Iifiche (encrypt) kabla haijatoka nje.

Pia kuna tatizo la usahihi wa data. Kunakili db.sqlite3 kwa kutumia cp wakati huduma inaendelea kufanya kazi kunaweza kutoa faili ambayo haijakamilika kuandikwa na haitafunguka, na hutajua hilo hadi utakapojaribu kuirejesha. Tumia snapshot ya SQLite yenyewe badala yake:

sqlite3 /vw-data/db.sqlite3 ".backup '/tmp/vw-db-backup.sqlite3'"

Upande wa urejeshaji (restore), ambao ni nusu ya mchakato ambayo hakuna mtu anayeifanyia majaribio, imeelezewa katika mwongozo wa backup na restore wa Vaultwarden.

Mambo unayopoteza ukilinganisha na Bitwarden inayohudumiwa na kampuni

Ukweli mtupu. Huduma ya Bitwarden inayohudumiwa na kampuni inaendeshwa na watu ambao kazi yao ya muda wote ni hiyo, ikiwa na ukaguzi wa watu wa tatu uliochapishwa na mtu anayepatikana kwa dharura saa 9 usiku. Kujihudumia mwenyewe (self-hosting) kunabadilisha hali hiyo na kukuweka kwenye ratiba yako mwenyewe ya kusasisha programu (patching).

Vaultwarden hutoa marekebisho ya usalama kama releases za kawaida. Toleo la 1.37.0, lililotolewa tarehe 24 Julai 2026, ndilo la sasa kufikia Agosti 2026, na maelezo yake yanawataka watumiaji kusasisha haraka iwezekanavyo. Instance uliyoiweka mwaka mmoja uliopita na kuisahau inaendesha msimbo wa mwaka mmoja uliopita. Tag ya latest haisaidii yenyewe: container inayofanya kazi huendelea kutumia image ile ile iliyoanza nayo hadi utakapofanya docker compose pull na kuiumba upya. Weka unattended upgrades kwenye Ubuntu kwa ajili ya vifurushi vya host, na uweke sasisho la container kwenye kikumbusho cha kalenda ambacho utakisoma kweli.

Hitimisho ambalo msomaji mwaminifu anapaswa kulifikia: kriptografia inayotumika hapa ni usanifu wa Bitwarden na inafanya kazi vizuri, huku hatari ya uendeshaji ikihamia kwako kikamilifu. Ikiwa utaisasisha na kuweka backup mahali pengine, instance ya Vaultwarden kwenye VPS unayoimiliki ni mahali pazuri pa kuhifadhi nywila zako. Ikiwa tabia hizo mbili hazitafanyika, lipia huduma inayohudumiwa na kampuni na uelekeze umakini wako kwingine. Ulinganisho wa vipengele kwa vipengele upo kwenye Vaultwarden ikilinganishwa na Bitwarden ya kujihudumia.

Kutia nguvu seva mwenyeji chini ya kontena

Vaultwarden ni mchakato mmoja kwenye seva ya Linux, na mtumiaji root kwenye seva hiyo anaweza kusoma /vw-data bila kujali jinsi programu ilivyosanidiwa. Endesha kontena kama mtumiaji asiye na upendeleo (unprivileged user) kwa kutumia user: "1000:1000" kwenye faili yako ya compose, huku folda ya data ikiwa na umiliki unaolingana, na weka chochote ambacho kontena hakiandikii kama read-only kwa kutumia :ro. Kisha funga mlango wa mbele: Kutia nguvu SSH kwenye VPS inaelezea kuingia kwa kutumia funguo pekee (key-only) na kuzima uthibitishaji wa nenosiri, jambo ambalo ndilo linalozuia mashambulizi ya kawaida yanayoweza kupita hatua zote zilizotajwa hapo juu.

FAQ

Je, mtu anaweza kusoma nywila zangu akiiiba database ya Vaultwarden?

Hapana, si moja kwa moja. Kila kitu kilichohifadhiwa kwenye vault husimbwa kwa njia fiche (encrypted) kwenye kifaa cha mtumiaji kwa kutumia ufunguo unaotokana na nywila kuu, kwa hivyo db.sqlite3 ina maandishi yaliyofichwa (ciphertext). Wanachokipata mara moja ni anwani ya barua pepe ya kila akaunti, mipangilio ya KDF, metadata ya kuingia na ya kifaa, pamoja na siri za uthibitishaji wa hatua mbili (two-factor secrets) kwenye jedwali la twofactor, ambazo huhifadhiwa bila kusimbwa kwa sababu seva lazima ihesabu msimbo unaotarajiwa. Wanaweza pia kushambulia ciphertext ya vault nje ya mtandao (offline) kwa muda wowote wanaotaka, ndiyo maana urefu wa nywila kuu ndio namba inayoamua matokeo.

Je, nitumie ADMIN_TOKEN au nizime ukurasa wa admin kabisa?

Uuzime ikiwa unaweza, kwa sababu mifumo mingi inahitaji ukurasa huo mara moja tu ili kusanidi SMTP na kualika watumiaji, na hauhitajiki tena. Ili kuuzima, usiweke ADMIN_TOKEN wala DISABLE_ADMIN_TOKEN, ondoa ufunguo wowote wa "admin_token" kutoka config.json, kisha uunde upya container. Kuondoa kigezo cha mazingira (environment variable) pekee hakutoshi, kwa sababu mipangilio iliyoandikwa na ukurasa wa admin hukaa kwenye config.json na ina kipaumbele zaidi. Ikiwa utauacha ukurasa huo, hifadhi token kama Argon2 hash iliyotengenezwa na vaultwarden hash badala ya kamba ya maandishi ya kawaida (plaintext), na uweke ADMIN_RATELIMIT_MAX_BURST=3.

ADMIN_TOKEN yangu ni sahihi lakini /admin inaikataa. Nini tatizo?

Karibu kila mara ni tatizo la $ interpolation. Kamba ya Argon2 PHC ina herufi kadhaa za $, na Docker Compose hupanua herufi hizo kama vigezo ndani ya kizuizi cha docker-compose.yml environment:, kwa hivyo container hupokea thamani iliyoharibika wakati faili yako inaonekana sawa. Marufuisha kila $ kuwa $$ kwenye faili ya compose, au hamisha thamani hiyo kwenye faili ya .env iliyofungwa kwenye alama za kunukuu (single quotes), ambapo hakuna haja ya kufanya escaping. Unda upya container baada ya hapo, kwa sababu mabadiliko ya mazingira hayachukuliwi kwa kuanzisha upya (restart) pekee.

Je, bado nahitaji kufungua port 3012 kwa ajili ya arifa?

Hapana. Usaidizi wa trafiki ya WebSocket kwenye port 3012 uliondolewa katika Vaultwarden 1.31.0 kwa sababu arifa zilihamishiwa kwenye port kuu ya HTTP, na WEBSOCKET_ENABLED pamoja na WEBSOCKET_PORT zimekuwa zikipuuzwa tangu toleo la 1.29.0. Mpangilio wa sasa ni ENABLE_WEBSOCKET, ambao ni true kwa chaguo-msingi. Funga port 3012 kwenye firewall na uifute kutoka kwenye faili yako ya compose, kisha hakikisha reverse proxy yako inasambaza vichwa vya habari (headers) vya Upgrade na Connection, kwa sababu ndivyo usawazishaji wa wakati halisi (real-time sync) unavyotegemea sasa.