Găzduirea Vaultwarden pe un Managed VPS: parolele pe propriul server

Ce face Vaultwarden

Vaultwarden este un server de gestionare a parolelor scris în Rust, conceput pentru găzduirea pe propriul server. Wiki-ul său îl destinează persoanelor, familiilor și organizațiilor de dimensiuni mici. Seiful web este livrat în imaginile sale Docker.

El implementează un API compatibil cu clienții oficiali Bitwarden, în browser, pe computer și pe telefon. README-ul precizează că proiectul nu este asociat cu Bitwarden și nici cu Bitwarden, Inc., și cere ca orice problemă să-i fie semnalată direct, oricare ar fi clientul folosit, nu canalelor de asistență oficiale.

• Seiful: seif personal, atașamente, pictogramele site-urilor, cheie API personală și Send, pentru a transmite un text sau un fișier.
• Organizațiile: colecții, partajarea parolelor, roluri, grupuri, jurnale de evenimente și politici.
• Autentificarea în doi pași: aplicație de autentificare, e-mail, FIDO2 WebAuthn, YubiKey și Duo.
• Mecanismele de recuperare: acces de urgență și recuperarea contului, aceasta din urmă cerând ca e-mailul să fie configurat.
• Administrarea: o pagină /admin pentru setări, conturi și diagnostic.

Wiki-ul enumeră și ce lipsește față de serverul oficial, precum autentificarea cu cheie de acces (passkey), rolurile personalizate și unele politici de întreprindere. El precizează că funcțiile utile mai ales marilor organizații nu sunt o prioritate a proiectului: citiți această listă dacă aveți nevoie de ele.

Ce permite licența AGPL-3.0

Vaultwarden este publicat sub GNU Affero General Public License, versiunea 3. Textul afirmă o permisiune nelimitată de a rula programul nemodificat. Puteți deci folosi imaginea publicată de proiect pentru firma și echipa dumneavoastră, fără nicio licență de cumpărat.

Articolul 13 adaugă o condiție specifică AGPL: dacă modificați programul, versiunea dumneavoastră trebuie să ofere tuturor celor care o folosesc de la distanță, prin rețea, posibilitatea de a obține gratuit codul sursă.

Instalarea cu Docker Compose

README-ul recomandă imaginile de container. Pe un server unde Docker este instalat, creați un director și puneți în el acest compose.yaml, preluat din README și din wiki:

services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.example.com"
      SIGNUPS_ALLOWED: "true"
    volumes:
      - ./vw-data/:/data/
    ports:
      - 127.0.0.1:8000:80

docker compose up -d

• Un port publicat pe 127.0.0.1: ca în README, Vaultwarden este accesibil doar prin proxy-ul invers, instalat pe același server.
• DOMAIN: adresa de bază a instanței dumneavoastră, în https. Wiki-ul avertizează că, fără ea, unele funcții nu mai merg, printre care atașamentele și linkurile de invitație.
• Un director vw-data pe un disc local: el păstrează toate datele. Wiki-ul semnalează problemele SQLite pe un volum CIFS sau Samba, care nu gestionează blocarea fișierelor.
• Eticheta latest urmărește ultima versiune publicată, iar wiki-ul o recomandă pentru majoritatea utilizărilor. O etichetă precum 1.37.5 fixează o versiune, iar latest-alpine oferă același lucru pe o bază Alpine.

Numele dumneavoastră de domeniu trebuie să indice spre server prin înregistrări A și AAAA, iar vizitatorii ajung pe porturile 80 și 443. Cât timp proxy-ul invers nu este instalat, seiful web rămâne inutilizabil: treceți direct la secțiunea următoare.

Proiectul nu indică nici memoria, nici procesorul necesare; el se prezintă doar ca o soluție pentru cazurile în care serviciul oficial, mare consumator de resurse, nu se potrivește. Dimensiunea depinde de numărul de conturi și de volumul atașamentelor. Pe un Managed VPS, descrieți-ne utilizarea dumneavoastră și vă recomandăm dimensiunea potrivită.

HTTPS și WebSocket: proxy-ul invers

Seiful web se sprijină pe API-ul Web Crypto, pe care browserele îl rezervă contextelor securizate: README-ul indică faptul că funcționează doar după activarea HTTPS, iar wiki-ul consideră HTTPS „pretty much required”, adică aproape obligatoriu. Proiectul recomandă un proxy invers în fața Vaultwarden și descurajează TLS-ul integrat în framework-ul său Rocket.

Alegeți un certificat recunoscut, precum cele de la Let’s Encrypt, pe care wiki-ul le recomandă: cu un certificat autosemnat, unele platforme refuză conexiunea. Certificatul trebuie să includă lanțul complet, altfel dispozitivele Android nu se conectează.

Notificările WebSocket, active implicit, anunță browserul, aplicația desktop și extensia că o intrare s-a schimbat. Ele trec prin portul HTTP principal, iar proxy-ul trebuie să transmită antetele Upgrade și Connection. Aplicațiile mobile folosesc notificările native ale sistemului lor, care se configurează separat.

Cu Caddy

Wiki-ul sfătuiește să priviți mai întâi spre Caddy, dacă nu aveți o preferință: el activează singur HTTPS, obține certificatul Let’s Encrypt și suportă WebSocket. Setarea din wiki transmite și adresa reală a vizitatorului către Vaultwarden, pentru jurnalele sale:

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

Cu Nginx și Certbot

Acest bloc preia exemplul Nginx din wiki, redus la portul 80, pentru a lăsa Certbot să instaleze HTTPS:

upstream vaultwarden-default {
  zone vaultwarden-default 64k;
  server 127.0.0.1:8000;
  keepalive 2;
}

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      "";
}

server {
    listen 80;
    listen [::]:80;
    server_name vault.example.com;

    client_max_body_size 525M;

    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;

    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;

    location / {
      proxy_pass http://vaultwarden-default;
    }
}

Certbot instalează apoi certificatul și se ocupă de reînnoirea lui:

sudo certbot --nginx

Verificarea WebSocket

Deschideți instrumentele de dezvoltare ale browserului, fila de rețea, filtrul WS, apoi reconectați-vă la seif: un răspuns 101 pe /notifications/hub confirmă conexiunea. Alt test din wiki: deschideți seiful în două browsere, redenumiți o intrare în unul și schimbarea apare imediat în celălalt.

Închiderea înregistrărilor

Implicit, oricine ajunge la instanța dumneavoastră își poate crea un cont. Este util pentru primul cont, iar wiki-ul recomandă să închideți apoi înregistrările, pentru a-i împiedica pe atacatori să creeze unul.

1. Deschideți adresa dumneavoastră HTTPS și creați-vă contul, apoi conectați-vă aplicațiile la această adresă.
2. Treceți SIGNUPS_ALLOWED pe "false" în compose.yaml.
3. Relansați cu docker compose up -d: o variabilă de mediu este legată de container, care trebuie recreat pentru ca ea să fie luată în considerare.

SIGNUPS_ALLOWED: "false"

• Invitațiile rămân deschise și după închidere: proprietarii și administratorii unei organizații pot invita persoane noi. INVITATIONS_ALLOWED pe "false" elimină această posibilitate, iar wiki-ul lasă alegerea în funcție de încrederea pe care o acordați utilizatorilor.
• O listă de domenii: SIGNUPS_DOMAINS_WHITELIST limitează înregistrarea la anumite domenii de e-mail, iar SIGNUPS_VERIFY pe true impune atunci verificarea adresei. Când această listă este setată, SIGNUPS_ALLOWED este ignorată.
• Pagina de administrare permite invitarea oricui, indiferent de aceste restricții.

De îndată ce salvați configurația din pagina de administrare, în directorul de date apare un fișier config.json, care are prioritate față de variabilele de mediu. Setările respective se schimbă atunci din această pagină: modificarea lui compose.yaml nu mai este de ajuns.

Pagina de administrare și tokenul ei

Pagina /admin servește la configurarea Vaultwarden, la vizualizarea și ștergerea conturilor și a organizațiilor, la eliminarea autentificării în doi pași a unui utilizator, la invitații și la citirea diagnosticului. Fără ADMIN_TOKEN, ea rămâne dezactivată: dacă nu aveți nevoie de ea, lăsați-o așa.

Wiki-ul recomandă insistent activarea HTTPS înaintea acestei pagini. Tokenul servește drept parolă și poate fi păstrat sub formă de hash, în argon2id, în loc de text clar în configurație. Vaultwarden furnizează comanda: ea cere parola de două ori, apoi returnează un șir PHC.

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

Puneți acest șir într-un fișier .env, lângă compose.yaml, între apostrofuri, apoi apelați-l din serviciu:

VAULTWARDEN_ADMIN_TOKEN='$argon2id$...'

ADMIN_TOKEN: ${VAULTWARDEN_ADMIN_TOKEN}

Verificați rezultatul, relansați, apoi conectați-vă pe /admin cu parola dumneavoastră, nu cu șirul PHC:

docker compose config
docker compose up -d

• Sesiunea durează implicit 20 de minute, reglabile prin ADMIN_SESSION_LIFETIME. O sesiune deschisă rămâne valabilă după schimbarea tokenului. Pentru a le închide pe toate, ștergeți rsa_key.pem din directorul de date și reporniți, ceea ce deconectează și utilizatorii și anulează invitațiile în curs.
• Un acces restrâns: exemplele de proxy din wiki arată cum să deschideți /admin doar pentru anumite adrese sau să adăugați o autentificare HTTP.
• DISABLE_ADMIN_TOKEN elimină orice control: este prevăzut pentru un strat de autentificare separat, plasat în față, iar wiki-ul îl rezervă celor care știu ce fac.

Ce protejează seiful

Prima protecție este parola principală. Datele seifului sunt criptate cu chei personale sau de organizație: cine obține o copie a bazei sau forțează o sesiune trebuie totuși să spargă această parolă pentru a le citi. Soliditatea ei contează deci înainte de toate. O sesiune de administrare permite ea însăși ștergerea unui cont sau eliminarea unei autentificări în doi pași, fără a da acces la datele seifului.

Pregătiți-vă pentru uitarea parolei principale înainte ca ea să se întâmple: activați accesul de urgență al contului dumneavoastră și, într-o organizație, recuperarea contului, care cere ca e-mailul să fie configurat.

Trei setări în plus, preluate din ghidul de securizare

• Un cont non-root: imaginea rulează implicit ca root, iar wiki-ul consideră preferabil să i se dea drepturile minime. Adăugați user: 1000:1000 serviciului, cu un director vw-data care aparține acestui utilizator.
• Jurnalele proxy-ului: conexiunea WebSocket trece un token în adresă, în access_token. Dacă proxy-ul dumneavoastră își păstrează jurnalele sau le trimite către un serviciu extern, wiki-ul recomandă să mascați această valoare.
• Numărul minim de montări: montați directorul de date și nimic altceva, nici directorul dumneavoastră personal, nici /var/run/docker.sock.

SQLite, MariaDB sau PostgreSQL

Aceeași imagine suportă cele trei baze de date. Wiki-ul descrie SQLite ca fiind cea mai folosită și cea mai testată și o recomandă pentru majoritatea utilizărilor, în afara cazului în care aveți nevoie precisă de alta.

DATABASE_URL: "postgresql://user_name:user_password@db_host:5432/vaultwarden"

Creați o bază goală și utilizatorul ei: la pornire, Vaultwarden își instalează singur schema. O parolă care conține caractere speciale se scrie în această adresă cu codificare procentuală (percent-encoding).

Faceți această alegere înainte de a umple seiful. Wiki-ul descrie trecerea de la SQLite la PostgreSQL cu pgloader, precizând că această cale nu este suportată de proiect, că se face pe riscul dumneavoastră și că începe cu un backup.

E-mailurile: configurarea SMTP

Vaultwarden pornește fără e-mail, dar mai multe funcții depind de el: invitațiile, verificarea adreselor, trimiterea indiciilor de parolă, autentificarea în doi pași prin e-mail și recuperarea contului.

Pe un VPS Simafri, trimiterea trece printr-un releu SMTP autentificat, pe portul 587: adresa unui cont de e-mail pe care îl aveți deja sau Simafri Suite. Parola se pune în fișierul .env, ca tokenul de administrare:

SMTP_HOST: "smtp.example.com"
SMTP_FROM: "vault@example.com"
SMTP_PORT: "587"
SMTP_SECURITY: "starttls"
SMTP_USERNAME: "vault@example.com"
SMTP_PASSWORD: ${VAULTWARDEN_SMTP_PASSWORD}

• Linkurile de invitație se construiesc pornind de la DOMAIN și rămân valabile 5 zile.
• Microsoft: wiki-ul indică faptul că Hotmail, Outlook și Office 365 cer de acum OAuth2, pe care Vaultwarden nu îl suportă încă. Eroarea de recunoscut este No compatible authentication mechanism was found.
• Gmail: prevedeți o parolă de aplicație, potrivit wiki-ului.
• Proba: pagina de administrare trimite un e-mail de test. Dacă schimbați acolo o setare SMTP, salvați mai întâi, căci testul folosește setările salvate, iar această salvare creează config.json.

Dacă nu pleacă nimic, wiki-ul propune testarea conexiunii la releu de pe server. Comanda returnează 0 când releul răspunde:

timeout 5 bash -c 'cat < /dev/null > /dev/tcp/smtp.example.com/587'; echo $?

Backupurile

README-ul amintește că proiectul nu poate fi tras la răspundere pentru o pierdere de date și recomandă insistent backupuri regulate. Wiki-ul le sfătuiește automate, cu cel puțin o copie în altă parte. Iată ce conține directorul de date cu SQLite:

Baza, cu serviciul în funcțiune

Începând cu versiunea 1.32.1, Vaultwarden știe să își salveze singur baza SQLite, fără oprirea serviciului:

docker exec -it vaultwarden /vaultwarden backup

Comanda scrie un fișier db_AAAAMMZZ_HHMMSS.sqlite3 lângă bază, în vw-data. Imaginea nu conține nici sqlite3, nici cron: wiki-ul sfătuiește programarea sarcinii pe server, cel puțin o dată pe zi. Eliminați atunci -it, căci o sarcină programată nu are terminal, și faceți ordine printre aceste fișiere, care se acumulează.

Tot directorul, cu serviciul oprit

Când baza nu este folosită, o simplă copiere a tuturor fișierelor ei este suficientă. Este metoda cu serviciul oprit pe care wiki-ul o dă ca exemplu pentru Docker și ea include și atașamentele:

docker compose down
tar -czf vaultwarden-$(date +%F).tar.gz vw-data
docker compose up -d

Wiki-ul consideră utilă un strat de criptare, mai ales când backupul conține tokenul de administrare și accesele SMTP, și citează rclone, restic și rustic pentru a trimite copiile la distanță. Cu MariaDB sau PostgreSQL, adăugați un export al bazei la directorul vw-data.

Wiki-ul cere să nu vă bazați doar pe instantaneele de disc, mai delicate la restaurare. Păstrați deci aceste copii proprii aplicației: puse pe discul serverului, ele intră și în backupurile sale de noapte.

Restaurarea

1. Opriți Vaultwarden.
2. Înlocuiți fiecare fișier sau director din vw-data cu versiunea sa salvată.
3. Dacă baza provine din /vaultwarden backup, numiți-o db.sqlite3 și ștergeți mai întâi orice fișier db.sqlite3-wal existent: un jurnal care nu corespunde poate corupe baza. Dacă provine dintr-o copie directă, restaurați împreună db.sqlite3 și db.sqlite3-wal.
4. Relansați, apoi verificați că puteți deschide seiful.

Wiki-ul sfătuiește repetarea acestui exercițiu din când în când, păstrând o copie a datelor existente: așa verificați că un backup funcționează.

Actualizările

Wiki-ul dă două comenzi, din directorul fișierului compose.yaml. Directorul de date rămâne pe loc:

docker compose pull
docker compose up -d

Aceste actualizări contează mai mult decât în alte părți. Aplicațiile mobile și extensiile de browser se actualizează singure, iar wiki-ul avertizează că o diferență de versiune față de server poate provoca defecțiuni bruște. Seiful web, livrat în imagine, rămâne mereu în acord cu serverul său.

Proiectul nu are un calendar de versiuni: urmăriți notele sale de versiune și faceți un backup chiar înaintea fiecărei actualizări. Unele conțin corecturi de securitate, precum versiunea 1.37.5 din 1 noiembrie 2026, ale cărei note recomandă actualizarea cât mai repede. Aceleași note avertizează și că, începând cu 1.37.5, o valoare de configurare invalidă împiedică pornirea Vaultwarden: recitiți fișierul de mediu înainte de actualizare. Pagina de diagnostic din /admin arată dacă există o versiune mai recentă.

Cine ce face pe un Managed VPS

Găzduirea pe propriul server cere să țineți serverul pe lângă aplicație. Pe un Managed VPS, echipele noastre preiau serverul și vă urmăresc proactiv instanța; Vaultwarden rămâne software-ul dumneavoastră, cu setările și datele sale.

Dacă preferați ca echipele noastre să intervină în aplicația însăși, această prestație se facturează la oră sau la preț fix, cu o ofertă comunicată înainte de intervenție.