SSD Nodes Learn Hosting plans →
Guide Matt ConnorDi Matt Connor · Aggiornato 2026-10-28

Vaultwarden o Bitwarden self-hosted: quale scegliere

Bitwarden ufficiale richiede circa 12 container e 2 GB di RAM; Vaultwarden offre la stessa API in uno solo. Confronta risorse, backup e gestione su VPS.

Che cosa sono realmente Vaultwarden e Bitwarden self-hosted

Vaultwarden vs Bitwarden self-hosted è una scelta tra due server che implementano la stessa API client, non tra due password manager. Lo stack ufficiale di Bitwarden esegue circa una dozzina di container dietro nginx, archivia tutti i dati in Microsoft SQL Server ed è associato a un installation ID da registrare con un indirizzo email. Vaultwarden è una reimplementazione non ufficiale dell'API client di Bitwarden, scritta in Rust, che viene eseguita come un singolo container e utilizza un unico file SQLite. L'estensione del browser e l'app sul telefono non possono distinguerli, perché entrambi rispondono agli stessi endpoint.

La cifratura è identica in entrambi i casi. I client Bitwarden cifrano il vault prima che qualsiasi dato lasci il dispositivo. Il server archivia quindi blob che non può leggere, e in entrambi i casi il formato del vault appartiene a Bitwarden. Cambiano invece la quantità di risorse che devi noleggiare, chi mantiene il codice, quali funzionalità sono a pagamento e che cosa devi includere nei backup.

Il README di Vaultwarden è esplicito sul suo stato: "This project is not associated with Bitwarden or Bitwarden, Inc." È un progetto gestito da volontari, senza un servizio di assistenza e senza garanzia. Un maintainer attivo lavora presso Bitwarden e contribuisce nel proprio tempo libero: si tratta di una cortesia, non di un'approvazione ufficiale.

I tre stack che è possibile installare

La maggior parte dei confronti trascura il fatto che Bitwarden distribuisce due diversi prodotti self-hosted.

Bitwarden standard. Il deployment del fornitore, gestito tramite uno script shell.

curl -Lso bitwarden.sh "https://func.bitwarden.com/api/dl/?app=self-host&platform=linux" \
  && chmod 700 bitwarden.sh
./bitwarden.sh install

Il programma di installazione richiede il dominio, se richiedere un certificato Let's Encrypt, un ID di installazione e una chiave da ottenere da https://bitwarden.com/host inserendo un indirizzo email, e la regione (US o EU). ./bitwarden.sh start scarica quindi le immagini e avvia lo stack. Bitwarden indica 2 GB di RAM e 12 GB di spazio di archiviazione come requisiti minimi, 4 GB e 25 GB come raccomandati, e Docker Engine 26 o superiore con il plugin Compose. Il database è un'immagine MSSQL Express, che Bitwarden documenta con un limite massimo di 10 GB per il database relazionale. Se tale dimensione risulta insufficiente, è possibile puntare il deployment verso un database esterno.

Bitwarden lite. Questo è il deployment precedentemente noto come Bitwarden Unified. È uscito dalla fase beta ed è stato rinominato a dicembre 2025. Un singolo container applicativo più un database a scelta:

services:
  bitwarden:
    depends_on:
      - db
    env_file:
      - settings.env
    image: ghcr.io/bitwarden/lite
    restart: always
    ports:
      - "80:8080"
    volumes:
      - bitwarden:/etc/bitwarden
  db:
    environment:
      MARIADB_USER: "bitwarden"
      MARIADB_PASSWORD: "super_strong_password"
      MARIADB_DATABASE: "bitwarden_vault"
      MARIADB_RANDOM_ROOT_PASSWORD: "true"
    image: mariadb:10
    restart: always
    volumes:
      - data:/var/lib/mysql
volumes:
  bitwarden:
  data:

Supporta MariaDB o MySQL, PostgreSQL, SQLite e MSSQL, e richiede 200 MB di RAM e 1 GB di spazio di archiviazione. La documentazione ufficiale di Bitwarden solleva due avvertenze. È destinato all'uso personale e agli home lab piuttosto che all'uso aziendale, e non esegue backup automatici del database, pertanto tale operazione è interamente a carico dell'utente.

Vaultwarden. Un singolo container, come indicato nel README del progetto:

docker run --detach --name vaultwarden \
  --env DOMAIN="https://vw.domain.tld" \
  --volume /vw-data/:/data/ \
  --restart unless-stopped \
  --publish 127.0.0.1:8000:80 \
  vaultwarden/server:latest

La riga di pubblicazione associa la porta 8000 esclusivamente al loopback, e questa è una scelta deliberata. Vaultwarden serve traffico HTTP semplice e richiede un reverse proxy per terminare il TLS (transport layer security) davanti ad esso. Il TLS qui non è opzionale: il web vault esegue la crittografia tramite l'API WebCrypto del browser, che i browser espongono solo in un contesto sicuro; pertanto, su un normale http, la pagina di login fallisce nel browser prima ancora che il server riceva la richiesta. La guida completa all'installazione di Vaultwarden copre la configurazione del proxy e del certificato.

Quanta RAM utilizza Vaultwarden rispetto a Bitwarden self-hosted?

I requisiti minimi del fornitore indicano sotto quale soglia l'installer rifiuta di avviarsi, non quante risorse utilizza effettivamente il software. Le righe seguenti provengono da docker stats --no-stream su installazioni inattive, con un utente per installazione, un vault di piccole dimensioni e nessun allegato, su un sistema Ubuntu 24.04 con 4 GB di RAM. Lo spazio su disco comprende le immagini e la directory dei dati dopo il primo avvio completato correttamente.

GraficoIdle memory, container count and disk, measured on one Ubuntu 24.04 box
I dati alla base di questo grafico
[
  {
    "label": "Vaultwarden (SQLite)",
    "idle_ram_mb": 58,
    "containers": 1,
    "disk_gb": 0.4
  },
  {
    "label": "Bitwarden lite + MariaDB",
    "idle_ram_mb": 470,
    "containers": 2,
    "disk_gb": 1.6
  },
  {
    "label": "Bitwarden standard (MSSQL)",
    "idle_ram_mb": "2,400",
    "containers": 12,
    "disk_gb": 6.5
  }
]

Vaultwarden utilizzava 58 MB di RAM in una singola container. Lo stack Bitwarden standard utilizzava circa 2,400 MB distribuiti su 12 container, e la container MSSQL ne assorbiva la maggior parte. Bitwarden lite si collocava tra i due, con 470 MB e la relativa container MariaDB. Esegui lo stesso comando sul tuo sistema prima di considerare attendibili questi valori, perché cambiano in base al numero di utenti, agli allegati e al traffico di sincronizzazione; inoltre MSSQL aumenta il proprio working set quanto più a lungo rimane in esecuzione.

Per un VPS di piccole dimensioni, l'interpretazione pratica è questa: Vaultwarden con SQLite funziona senza problemi su un piano da 1 GB, mentre lo stack Bitwarden standard non si avvia. Su un piano da 2 GB lo stack standard soddisfa il requisito minimo documentato, ma lascia pochissima memoria al sistema operativo; di conseguenza, l'out-of-memory killer del kernel può intervenire concretamente. Quando interviene, dmesg stampa una riga con il nome del processo terminato e, con questo stack, di solito si tratta di sqlservr. Per la distribuzione standard, assegna 4 GB. Se lo stesso VPS deve ospitare più di un vault, calcola i requisiti minimi degli altri servizi prima di scegliere il piano, perché un server fotografico come PhotoPrism o Immich richiede molta più memoria di quanta Vaultwarden ne utilizzerà mai. Non tutti i servizi aggiuntivi sono altrettanto esigenti: un'applicazione come Halcyon, che rielabora una libreria Jellyfin come un videonoleggio degli anni 90 è un front end browser che si appoggia al media server configurato, invece di includere un proprio database. La memoria non è l'unico requisito minimo da verificare: un relay RustDesk per le sessioni desktop remote utilizza a malapena risorse in docker stats, ma consuma invece la quota di banda prevista dal tuo piano.

Quali funzionalità a pagamento sono gratuite in Vaultwarden?

Eseguire il server di Bitwarden non comporta costi, ma le funzionalità a pagamento restano bloccate finché non si carica un file di licenza. Ne hanno bisogno gli account individuali Premium e i piani organizzativi a pagamento che possono essere self-hosted: Families ed Enterprise. Bitwarden non offre l'opzione self-hosted per Teams. Il file si scarica dal vault web cloud, in Settings e poi Subscription per un account individuale, oppure dalla Admin Console, in Billing e poi Subscription per un'organizzazione, quindi si carica nella propria istanza. Le licenze delle organizzazioni vengono emesse per l'installation ID memorizzato in ./bwdata/env/global.override.env. Un'organizzazione self-hosted mantiene quindi comunque un abbonamento a pagamento e continua a interagire con il cloud di Bitwarden per la fatturazione.

Vaultwarden abilita le stesse funzionalità senza licenza e senza abbonamento. Il wiki del progetto le elenca:

  • organizzazioni, raccolte e gruppi
  • allegati di file
  • accesso in due passaggi tramite email, Duo, YubiKey e FIDO2
  • Emergency Access
  • Bitwarden Send
  • chiavi API personali
  • SSO tramite OpenID Connect

SSO è la funzionalità più recente tra queste e si configura con SSO_ENABLED, SSO_AUTHORITY, SSO_CLIENT_ID e SSO_CLIENT_SECRET. Esegue solo l'autenticazione dell'accesso. Il wiki specifica chiaramente che è comunque necessaria una master password, che non viene gestita dall'identity provider, perché da quella password deriva la chiave che decritta il vault. Impostare SSO_AUTHORITY sull'issuer di discovery di un identity provider Authentik self-hosted consente agli utenti di autenticarsi tramite quel servizio e quindi di sbloccare il vault con la propria master password. Il valore deve corrispondere al campo issuer restituito dall'endpoint di discovery, senza il suffisso /.well-known/openid-configuration finale.

Con Vaultwarden non si ottiene invece un fornitore. Bitwarden dispone delle certificazioni SOC 2 Type 2 e ISO 27001, pubblica report di audit di terze parti e gestisce un programma privato di bug bounty su HackerOne. Questi elementi riguardano il codice e il servizio di Bitwarden, non il server installato dall'utente. Tuttavia, se un auditor richiede un fornitore nominativo responsabile del password manager, una reimplementazione gestita da volontari rende la discussione più complessa.

Le app ufficiali di Bitwarden funzionano con Vaultwarden?

Sì. Vaultwarden implementa l'API client, quindi le estensioni del browser, le app desktop, le app mobili e il web vault incluso funzionano con il server. In ogni client è necessario impostare l'URL del server self-hosted nella schermata dell'ambiente prima di effettuare l'accesso, non dopo.

Una funzionalità richiede una configurazione aggiuntiva: le notifiche push nelle app mobili. Senza le notifiche push, l'app esegue la sincronizzazione quando viene aperta o secondo il proprio intervallo, quindi una password modificata sul laptop non compare sul telefono finché non si apre l'app. Vaultwarden può usare il relay push di Bitwarden e richiede un installation ID e una key dalla stessa pagina https://bitwarden.com/host usata dall'installer ufficiale.

PUSH_ENABLED=true
PUSH_INSTALLATION_ID=<your installation id>
PUSH_INSTALLATION_KEY=<your installation key>

I server nella regione UE richiedono anche PUSH_RELAY_URI=https://api.bitwarden.eu e PUSH_IDENTITY_URI=https://identity.bitwarden.eu. La wiki documenta due problemi da conoscere prima di dedicare un'ora al troubleshooting. Un'app installata da F-Droid o Neo Store non supporta Firebase e non riceverà mai notifiche push, indipendentemente dalla configurazione del server. Un'app che si è connessa prima di Vaultwarden 1.30.2 deve cancellare i propri dati, in modo da registrare un push token.

Quanto è sicura una reimplementazione?

La cronologia degli audit di Bitwarden è lunga e pubblica. Cure53 l'ha esaminato nel 2018, 2021, 2022, 2023, 2024 e 2025. L'audit del 2025 ha riguardato l'estensione del browser e l'overlay per il completamento automatico, l'applicazione principale, l'applicazione desktop, il vault web e il crate e la libreria RustCrypto. IOActive e Mandiant hanno esaminato i client nel 2024. Fracture Labs ha svolto valutazioni web e di rete nel 2024 e 2025. Unit 42 ha valutato le applicazioni mobili nel 2025. L'Applied Cryptography Group dell'ETH Zurich ha esaminato la crittografia nel 2025.

Anche Vaultwarden è stato esaminato da soggetti esterni, nonostante si possa pensare che nessuno lo controlli. Il Federal Office for Information Security (BSI) tedesco ha incaricato mgm security partners di sottoporlo a test tra febbraio e maggio 2024, nell'ambito del progetto di analisi del codice Caos 3.0. La valutazione ha classificato due risultati come di gravità elevata. Separatamente, ERNW ha segnalato un bypass dell'autenticazione che interessava le versioni precedenti alla 1.32.5 (CVE-2024-55225), corretto a novembre 2024. La versione 1.37.0, rilasciata a luglio 2026, ha corretto vulnerabilità SSRF (server side request forgery) tramite l'endpoint delle icone, l'accesso cifrato tra organizzazioni e un bypass dei criteri dell'organizzazione durante l'importazione delle directory. La versione 1.37.4, rilasciata a ottobre 2026, ha corretto un altro gruppo di problemi. Tra questi c'era una vulnerabilità di gravità elevata nella revoca dei membri dell'organizzazione, oltre a problemi nell'autenticazione a due fattori, negli inviti alle organizzazioni e negli allegati.

Questa cronologia dimostra che il progetto dispone di un processo funzionante per la gestione delle segnalazioni. Indica anche quale superficie di attacco ricorre più spesso: la pagina di amministrazione. Trattala quindi come una componente sensibile. Rimane disabilitata se ADMIN_TOKEN non è impostato. Devi inoltre memorizzare un hash invece del token in chiaro.

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

Il comando stampa una stringa PHC Argon2 (password hashing competition format) da inserire in ADMIN_TOKEN. Abilita HTTPS prima di abilitare la pagina di amministrazione, perché il token viene inviato nella richiesta. Un token in chiaro su una connessione HTTP non cifrata può essere letto da qualsiasi soggetto presente sul percorso di rete. Il rischio pratico riguarda soprattutto quel token e il file di backup, non la crittografia. Una procedura di hardening su un'istanza in esecuzione interviene su entrambi gli aspetti. Mantieni /admin fuori da Internet pubblico quando possibile e applica anche le normali misure di hardening dell'host, ad esempio limitare l'accesso SSH al server.

Cosa si interrompe quando l'API ufficiale cambia

Questo è il rischio che viene sottovalutato. Bitwarden rilascia i client e questi si aggiornano automaticamente dagli app store durante la notte. Vaultwarden deve seguire il passo. Quando una nuova versione del client modifica il contratto API, un'istanza di Vaultwarden non aggiornata si trova a interagire con un client che è già passato alla versione successiva; di conseguenza, le operazioni di accesso o sincronizzazione iniziano a fallire su dispositivi che non sono stati toccati.

Le note di rilascio forniscono un esempio concreto. Vaultwarden 1.37.0 riporta: "Questo aggiornamento è richiesto per il supporto ai client con versione 2026.7.0+; si prega di aggiornare prima di segnalare qualsiasi problema con essi." Un mese dopo, la versione 1.37.2, pubblicata il 22 agosto 2026, ha ripetuto l'avviso per i client alla versione 2026.8.0 e successive; pertanto, un server rimasto alla versione 1.37.0 o 1.37.1 è già indietro rispetto alle applicazioni. Al 27 ottobre 2026, la versione corrente è la 1.37.4, pubblicata il 5 ottobre 2026, dopo la 1.37.3 del 13 settembre 2026.

Due abitudini rendono questa gestione meno problematica. Fissare un tag di immagine specifico invece di latest, in modo che un pull automatico non aggiorni il server alle 3 del mattino. Successivamente, monitorare il feed dei rilasci ed eseguire l'aggiornamento in modo deliberato, leggendo prima le note, poiché è lì che vengono annunciate le modifiche che rompono la compatibilità. L'avviso della 1.37.2 è stato pubblicato anche nelle GitHub Discussions del progetto, insieme ai passaggi di ripristino per i client che continuano a non funzionare correttamente dopo l'aggiornamento del server: effettuare il logout e il login, quindi svuotare la cache dell'app o dell'estensione e reinstallare l'app mobile o l'estensione solo come ultima risorsa. La versione 1.35.5, ad esempio, ha invalidato tutti i token di "ricordami" per la doppia autenticazione esistenti al momento dell'aggiornamento, il che costringe gli utenti a ripetere un passaggio di doppia autenticazione che ritenevano di aver già salvato.

Il deployment standard di Bitwarden presenta l'immagine speculare di questo problema. Gli aggiornamenti vengono eseguiti tramite ./bitwarden.sh updateself e ./bitwarden.sh update e l'aggiornamento applica le migrazioni del database. Un backup effettuato prima della migrazione non costituisce un rollback per lo schema successivo; pertanto, eseguire il backup e annotare la versione in cui è stato effettuato.

Backup: qui si perdono davvero i vault

La directory dei dati di Vaultwarden è il server. Conservare questi elementi:

  • db.sqlite3
  • ogni file rsa_key*, inclusi rsa_key.pem e rsa_key.der
  • attachments/
  • config.json
  • sends/

Non copiare db.sqlite3 con cp mentre il container è in esecuzione. SQLite potrebbe essere nel mezzo di una scrittura. La copia potrebbe quindi essere un database danneggiato, anche se sembra integro fino al ripristino. Usare invece l'API di backup online:

sqlite3 data/db.sqlite3 ".backup '/path/to/backups/db-$(date '+%Y%m%d-%H%M').sqlite3'"

Dalla versione 1.32.1 è disponibile anche un comando /vaultwarden backup integrato nell'immagine. In entrambi i casi, lo snapshot resta sullo stesso disco dell'originale finché non viene spostato. Inviarlo quindi fuori dal server secondo una pianificazione usando snapshot restic verso uno storage esterno. Un job di backup che smette di funzionare senza segnalazioni è indistinguibile da un job che non è mai esistito. Configurare quindi il timer in modo che segnali autonomamente i propri errori in un punto visibile, come fa un server ntfy self-hosted collegato a un'unità systemd OnFailure. I file rsa_key sono importanti quanto il database: il server usa quella chiave per firmare i token di sessione. Se il database viene ripristinato insieme a una chiave appena generata, tutti gli utenti vengono disconnessi e gli inviti alle organizzazioni ancora in corso non funzionano.

Bitwarden standard esegue il backup di una parte maggiore dei propri dati. Il container mssql scrive i backup notturni del database in ./bwdata/mssql/backups e ne conserva 30 giorni, purché il container sia in esecuzione. È possibile forzare un backup:

docker exec -i bitwarden-mssql /backup-db.sh

Le directory da conservare sono ./bwdata/env (variabili d'ambiente, incluse le password del database e dei certificati), ./bwdata/core/attachments, ./bwdata/mssql/data e ./bwdata/core/aspnet-dataprotection. L'ultima viene spesso dimenticata. Contiene i dati di protezione a livello di framework, inclusi i token di autenticazione e alcune colonne del database. Se il database viene ripristinato senza questa directory, le colonne protette risultano illeggibili. Bitwarden lite non esegue backup automatici. Scegliere lite significa quindi gestire una pianificazione dei dump esattamente come per Vaultwarden.

Migrazione in entrambe le direzioni

La migrazione avviene tramite i client, non tramite i server, perché le funzioni di esportazione e importazione sono disponibili nei client. La procedura è quindi la stessa in entrambe le direzioni.

Ogni utente esporta i dati dal vault web o dall'app desktop, crea un account sul nuovo server ed esegue l'importazione. I formati disponibili sono plaintext .json, plaintext .csv, encrypted .json e un .zip che contiene il JSON e gli allegati per i singoli vault. Schede, identità, passkey memorizzate e chiavi SSH vengono conservate soltanto nei formati JSON; una migrazione CSV le elimina senza segnalarlo. Nessun formato di esportazione include gli elementi nel cestino o i Sends, e i dati di proprietà dell'organizzazione non fanno parte dell'esportazione individuale.

Tratta un'esportazione plaintext come un secret attivo, perché è esattamente questo: l'intero vault in testo non cifrato sul disco. Esportala, importala ed eliminala nella stessa sessione. Non inviarla mai tramite email o chat.

Un problema può bloccare la migrazione. Un'esportazione encrypted associata al tuo account non può essere importata in un altro account, e il trasferimento tra server implica per definizione un account diverso. Scegli invece l'opzione di esportazione protetta da password, che è portabile.

Il passaggio da Vaultwarden a Bitwarden standard è più complesso, perché la struttura dell'organizzazione non viene trasferita nell'esportazione. Ricrea l'organizzazione sul nuovo server, invita nuovamente gli utenti e chiedi a ciascun utente di importare il proprio vault. Pianifica una finestra di manutenzione, invece di scoprire il problema il giorno della migrazione.

Quale dovresti eseguire?

Esegui Vaultwarden se sei un singolo utente, una famiglia o gestisci un home lab su un VPS da 1 GB o 2 GB. Organisations, Emergency Access e Send sono inclusi gratuitamente, il consumo di memoria a riposo è paragonabile a quello di una scheda del browser e il backup consiste in un file SQLite più una directory di piccole dimensioni. È questa combinazione a rendere Vaultwarden la scelta dominante per la gestione self-hosted delle password.

Esegui il server ufficiale di Bitwarden quando altre persone dipendono dal servizio per motivi professionali: un'azienda che richiede un contratto di supporto, un requisito di conformità che indica esplicitamente il fornitore oppure funzionalità enterprise per cui paghi già. Per la distribuzione standard assegna 4 GB e considera il file di licenza e l'installation ID parte della distribuzione, non semplice documentazione amministrativa.

Bitwarden lite si colloca in una posizione intermedia poco chiara. È codice del fornitore con un ingombro molto più ridotto, un vantaggio concreto, ma Bitwarden lo documenta per l'uso personale e gli home lab e non dispone di backup automatici. Devi gestire il carico operativo di Vaultwarden senza disporre del relativo insieme gratuito di funzionalità. Sceglilo quando per te il codice del fornitore conta più delle funzionalità e accetti di gestire direttamente il database.

Se non hai ancora deciso quali altri servizi ospiterà il server, la panoramica delle alternative self-hosted mette questa scelta a confronto con gli altri servizi che competono per la stessa RAM.

FAQ

Vaultwarden è sufficientemente sicuro per un password manager reale?

Per uso personale e familiare, sì, a determinate condizioni. I client cifrano il vault prima di inviarlo al server, quindi Vaultwarden non vede mai la password principale né dati in chiaro. Il prodotto è stato sottoposto a verifiche esterne: BSI ha incaricato i partner di sicurezza di mgm di testarlo tra febbraio e maggio 2024, mentre ERNW ha segnalato un bypass dell'autenticazione corretto nella versione 1.32.5. Mantieni aggiornata la versione, disabilita la pagina di amministrazione oppure proteggila con un ADMIN_TOKEN sottoposto ad hashing Argon2 e pubblica il servizio esclusivamente tramite HTTPS. Un'azienda che necessita di supporto del fornitore o di documentazione per gli audit dovrebbe usare il server ufficiale di Bitwarden.

Quanta RAM richiede Vaultwarden rispetto a Bitwarden self-hosted?

Nelle installazioni inattive misurate con docker stats --no-stream, Vaultwarden con SQLite utilizzava circa 58 MB in un container, mentre la distribuzione standard di Bitwarden utilizzava circa 2,400 MB distribuiti su 12 container, in gran parte per il database MSSQL. Bitwarden indica 2 GB come requisito minimo e 4 GB come quantità consigliata per lo stack standard, oltre a 200 MB per Bitwarden lite. Vaultwarden funziona su un VPS da 1 GB con memoria sufficiente.

Serve una licenza Bitwarden per il self-hosting?

Non per un vault individuale gratuito. L'esecuzione del server è gratuita. Serve un file di licenza per sbloccare le funzionalità premium individuali e un piano organizzazione a pagamento; Families ed Enterprise sono gli unici piani organizzazione che Bitwarden consente di usare in modalità self-hosted. Scarica il file dal web vault cloud e caricalo nella tua istanza. Le licenze per le organizzazioni vengono emesse in base all'ID di installazione memorizzato in ./bwdata/env/global.override.env. Vaultwarden non richiede alcuna licenza e abilita autonomamente le funzionalità per le organizzazioni.

Posso passare in seguito da Vaultwarden a Bitwarden o tornare indietro?

Sì, in entrambe le direzioni, tramite i client. Ogni utente esporta il proprio vault dal web vault o dall'app desktop e lo importa nel nuovo server dopo aver creato un account. L'esportazione .zip include gli allegati dei vault individuali. I formati JSON includono carte, identità, passkey e chiavi SSH. Gli elementi del cestino e i Sends non sono inclusi in alcun formato di esportazione. Anche gli elementi di proprietà dell'organizzazione devono essere esportati separatamente da un proprietario. Pianifica quindi di ricreare l'organizzazione e invitare nuovamente gli utenti nel nuovo server.

Questo articolo ti è stato utile?

#vaultwarden#bitwarden#password-manager#self-hosting#docker