{"id":151,"date":"2026-06-15T16:32:36","date_gmt":"2026-06-15T16:32:36","guid":{"rendered":"https:\/\/shattered.io\/it\/2026\/06\/15\/vaultwarden-bitwarden-self-hosted\/"},"modified":"2026-06-15T16:34:01","modified_gmt":"2026-06-15T16:34:01","slug":"vaultwarden-bitwarden-self-hosted","status":"publish","type":"post","link":"https:\/\/shattered.io\/it\/2026\/06\/15\/vaultwarden-bitwarden-self-hosted\/","title":{"rendered":"Vaultwarden: Bitwarden Self-Hosted in 12 Step [2026]"},"content":{"rendered":"\n

Affidare tutte le password a un servizio cloud di terze parti significa fidarsi della loro infrastruttura, delle loro policy e della loro sicurezza. Vaultwarden<\/strong> ribalta questo schema: \u00e8 un server gestore password compatibile con Bitwarden che gira sul tuo hardware, sotto il tuo controllo, con cifratura end-to-end e architettura a conoscenza zero. Scritto in Rust, consuma poche decine di megabyte di RAM e funziona su un Raspberry Pi, un NAS o un piccolo VPS da pochi euro al mese.<\/p>\n\n\n\n

Questa guida pratica ti porta dall’installazione a un’istanza Vaultwarden in produzione, con HTTPS, pannello di amministrazione blindato, autenticazione a due fattori, backup automatici e hardening con fail2ban. Dodici step concreti, comandi copia-incolla testati su Ubuntu 24.04 LTS, oltre a errori comuni e risoluzione dei problemi. Tempo stimato: circa 45 minuti per la configurazione completa.<\/p>\n\n\n\n

Aggiornato al 15 giugno 2026. La versione di riferimento \u00e8 Vaultwarden 1.36.0<\/strong>, rilasciata a maggio 2026, il progetto open source dani-garcia\/vaultwarden<\/code> che su GitHub supera le 62.000 stelle.<\/p>\n\n\n\n

Cosa \u00e8 Vaultwarden e perch\u00e9 self-hostarlo<\/h2>\n\n\n\n

Vaultwarden \u00e8 un’implementazione alternativa e non ufficiale del server Bitwarden, scritta in Rust<\/strong>. Nasce nel 2018 con il nome bitwarden_rs<\/code> e viene rinominato in Vaultwarden nel 2023 per evitare confusione con il marchio ufficiale Bitwarden. Il progetto re-implementa l’API di Bitwarden, quindi funziona con tutti i client ufficiali: applicazioni desktop per Windows, macOS e Linux, app mobile per Android e iOS, estensioni per browser e interfaccia web.<\/p>\n\n\n\n

La differenza chiave rispetto allo stack ufficiale \u00e8 il peso. Il server Bitwarden self-hosted ufficiale richiede una dozzina di container Docker e circa 2 GB di RAM per funzionare in modo fluido. Vaultwarden gira in un singolo container e a riposo consuma poche decine di megabyte. Questo lo rende ideale per un Raspberry Pi 4 o 5, un NAS Synology o QNAP, o un VPS economico da 1 GB di RAM. Il database predefinito \u00e8 SQLite<\/strong>, ma sono supportati anche MySQL\/MariaDB e PostgreSQL per scenari multi-utente pi\u00f9 impegnativi.<\/p>\n\n\n\n

Il modello di sicurezza \u00e8 identico a quello di Bitwarden. La cifratura \u00e8 end-to-end<\/strong>: la chiave di cifratura del vault deriva dalla master password tramite PBKDF2 o, sui client moderni, Argon2id, e il server non vede mai le password in chiaro. \u00c8 un’architettura a conoscenza zero (zero-knowledge): anche con accesso fisico al database, un attaccante trova solo blob cifrati con AES-256. Vaultwarden supporta organizzazioni, condivisione tramite la funzione Send, allegati cifrati, notifiche in tempo reale via WebSocket e autenticazione a due fattori (TOTP, WebAuthn\/FIDO2, Duo ed email).<\/p>\n\n\n\n

Perch\u00e9 self-hostarlo? Tre motivi concreti. Primo, sovranit\u00e0 sui dati: i tuoi segreti restano in Italia o in Europa, sotto il GDPR, su hardware che controlli. Secondo, costo: niente abbonamenti per famiglia o team, paghi solo il server. Terzo, funzionalit\u00e0 premium gratuite: con Vaultwarden ottieni 2FA hardware, vault organizzativi e reportistica sulla salute delle password senza alcun piano a pagamento. Il rovescio della medaglia \u00e8 la responsabilit\u00e0: backup, aggiornamenti e sicurezza dell’infrastruttura ricadono interamente su di te. Questa guida copre tutti e tre i fronti.<\/p>\n\n\n\n

Vale la pena chiarire a chi conviene questo approccio. Se sei un utente alle prime armi che vuole solo un gestore password senza pensieri, un servizio cloud gestito resta la scelta pi\u00f9 pratica. Vaultwarden brilla invece per chi ha gi\u00e0 un minimo di dimestichezza con Linux e Docker, per le famiglie tecniche, per i professionisti che gestiscono dati sensibili dei clienti e per le piccole organizzazioni che vogliono evitare costi ricorrenti per utente. Il progetto \u00e8 maturo, attivamente mantenuto e adottato da decine di migliaia di amministratori in tutto il mondo: le oltre 62.000 stelle su GitHub raccontano una community solida e una documentazione collaudata. Non \u00e8 un esperimento di nicchia, \u00e8 infrastruttura di produzione su cui molti si appoggiano da anni.<\/p>\n\n\n\n

Vaultwarden vs Bitwarden ufficiale: le differenze<\/h2>\n\n\n\n

Prima di mettere mano al terminale, \u00e8 utile capire cosa scegli e a cosa rinunci. Vaultwarden non \u00e8 un fork di Bitwarden, ma una re-implementazione indipendente dell’API. Per l’uso quotidiano di una famiglia o di un piccolo team le differenze sono minime, ma ci sono distinzioni importanti su licenza, supporto e funzionalit\u00e0 enterprise.<\/p>\n\n\n\n

\n
Caratteristica<\/th>Vaultwarden 1.36.0<\/th>Bitwarden ufficiale self-hosted<\/th><\/tr><\/thead>
Linguaggio<\/td>Rust<\/td>C# \/ .NET<\/td><\/tr>\n
Container Docker<\/td>1<\/td>~11<\/td><\/tr>\n
RAM a riposo<\/td>Poche decine di MB<\/td>~2 GB consigliati<\/td><\/tr>\n
Database<\/td>SQLite, MySQL, PostgreSQL<\/td>MSSQL (o PostgreSQL su Unified)<\/td><\/tr>\n
Licenza<\/td>AGPLv3 (open source)<\/td>Bitwarden License (source-available)<\/td><\/tr>\n
Funzioni premium<\/td>Tutte gratuite<\/td>Richiedono licenza<\/td><\/tr>\n
2FA hardware (FIDO2)<\/td>Incluso<\/td>Richiede licenza premium<\/td><\/tr>\n
Supporto ufficiale<\/td>Community<\/td>Supporto commerciale<\/td><\/tr>\n
Compatibilit\u00e0 client<\/td>Client ufficiali Bitwarden<\/td>Client ufficiali Bitwarden<\/td><\/tr>\n<\/tbody><\/table><\/figure>\n\n\n\n

La distinzione di licenza conta. Vaultwarden \u00e8 rilasciato sotto AGPLv3<\/strong>, una licenza copyleft che impone la pubblicazione del codice sorgente per i servizi esposti in rete. Bitwarden usa una licenza source-available pi\u00f9 restrittiva. Per un uso personale o domestico la differenza \u00e8 irrilevante; per chi rivende il servizio cambia tutto.<\/p>\n\n\n\n

Cosa manca a Vaultwarden? Non implementa alcune funzioni enterprise dell’ufficiale, come SSO con SAML, criteri di accesso aziendali avanzati e l’integrazione completa con directory esterne. Per una PMI, una famiglia o un professionista, queste assenze raramente pesano. Per un’azienda con requisiti di compliance stringenti, il prodotto ufficiale con supporto commerciale resta la scelta sensata. Se stai valutando le alternative cloud, abbiamo confrontato altri gestori in Proton Pass vs 1Password<\/a>.<\/p>\n\n\n\n

Un punto fondamentale: la sicurezza crittografica di Vaultwarden non \u00e8 inferiore. La cifratura avviene sul client, non sul server, quindi usa le stesse primitive di Bitwarden. La superficie di rischio si sposta sulla tua capacit\u00e0 di gestire correttamente server, HTTPS e backup, non sull’algoritmo. Questo \u00e8 il vero impegno che ti assumi.<\/p>\n\n\n\n

Prerequisiti e requisiti di sistema<\/h2>\n\n\n\n

Vaultwarden \u00e8 leggero, ma per esporlo in modo sicuro su Internet servono alcuni elementi. Ecco il setup minimo testato per questa guida. Il punto non negoziabile \u00e8 il dominio con HTTPS: i client Bitwarden rifiutano di connettersi a un server senza TLS valido, perch\u00e9 la cifratura del vault avviene solo su connessioni sicure.<\/p>\n\n\n\n

\n
Componente<\/th>Requisito minimo<\/th>Note<\/th><\/tr><\/thead>
Sistema operativo<\/td>Ubuntu 24.04 LTS \/ Debian 12<\/td>Qualsiasi Linux con Docker<\/td><\/tr>\n
RAM<\/td>1 GB<\/td>512 MB sufficienti per pochi utenti<\/td><\/tr>\n
Spazio disco<\/td>2 GB liberi<\/td>Pi\u00f9 spazio per gli allegati<\/td><\/tr>\n
Docker Engine<\/td>27.x o superiore<\/td>Con plugin Compose v2<\/td><\/tr>\n
Dominio<\/td>vault.tuodominio.it<\/td>Record DNS A\/AAAA verso il server<\/td><\/tr>\n
Porte<\/td>80 e 443 aperte<\/td>Per HTTPS e validazione ACME<\/td><\/tr>\n
Accesso<\/td>SSH con chiave<\/td>No password, vedi hardening<\/td><\/tr>\n<\/tbody><\/table><\/figure>\n\n\n\n

Hai bisogno di un nome di dominio e della possibilit\u00e0 di puntare un sottodominio (per esempio vault.tuodominio.it<\/code>) all’indirizzo IP pubblico del server. Se ospiti su una rete domestica dietro NAT, dovrai aprire le porte 80 e 443 sul router e, idealmente, avere un IP statico o un servizio DNS dinamico. Per il primo accesso al server raccomandiamo SSH con chiave Ed25519: trovi la procedura completa nella nostra guida sulle chiavi SSH Ed25519 e l’hardening del server<\/a>.<\/p>\n\n\n\n

Per il reverse proxy useremo Caddy<\/strong>, che ottiene e rinnova automaticamente i certificati TLS da Let’s Encrypt senza configurazione manuale. In alternativa puoi usare Nginx con Certbot: in quel caso la nostra guida su Let’s Encrypt e Certbot<\/a> copre il rilascio dei certificati. Caddy semplifica enormemente il lavoro ed \u00e8 la scelta consigliata per chi parte da zero.<\/p>\n\n\n\n

Step 1: Installare Docker Engine e Compose<\/h2>\n\n\n\n

Vaultwarden viene distribuito come immagine Docker ufficiale (vaultwarden\/server<\/code>), quindi il primo passo \u00e8 installare Docker Engine con il plugin Compose v2. Sul tuo server Ubuntu 24.04, aggiorna i pacchetti e installa Docker dal repository ufficiale, non dalla versione spesso obsoleta nei repository di sistema.<\/p>\n\n\n\n

# Aggiorna il sistema e installa le dipendenze\nsudo apt update && sudo apt upgrade -y\nsudo apt install -y ca-certificates curl gnupg\n\n# Aggiungi la chiave GPG ufficiale di Docker\nsudo install -m 0755 -d \/etc\/apt\/keyrings\ncurl -fsSL https:\/\/download.docker.com\/linux\/ubuntu\/gpg | \\\n  sudo gpg --dearmor -o \/etc\/apt\/keyrings\/docker.gpg\nsudo chmod a+r \/etc\/apt\/keyrings\/docker.gpg\n\n# Aggiungi il repository Docker\necho \"deb [arch=$(dpkg --print-architecture) \\\n  signed-by=\/etc\/apt\/keyrings\/docker.gpg] \\\n  https:\/\/download.docker.com\/linux\/ubuntu \\\n  $(. \/etc\/os-release && echo \"$VERSION_CODENAME\") stable\" | \\\n  sudo tee \/etc\/apt\/sources.list.d\/docker.list > \/dev\/null\n\n# Installa Docker Engine e Compose\nsudo apt update\nsudo apt install -y docker-ce docker-ce-cli containerd.io \\\n  docker-buildx-plugin docker-compose-plugin\n\n# Verifica l'installazione\nsudo docker --version\nsudo docker compose version<\/code><\/pre>\n\n\n\n
Se i comandi finali stampano i numeri di versione, Docker \u00e8 pronto. Per evitare di digitare sudo<\/code> a ogni comando, aggiungi il tuo utente al gruppo docker con sudo usermod -aG docker $USER<\/code> e poi riconnettiti via SSH. Attenzione: appartenere al gruppo docker equivale a privilegi di root, quindi limita questo accesso agli amministratori fidati. La guida ufficiale per l’installazione su Ubuntu \u00e8 disponibile nella documentazione Docker<\/a>.<\/p>\n\n\n\n
Step 2: Preparare le cartelle e le variabili<\/h2>\n\n\n\n
Organizza i file in una struttura ordinata. Vaultwarden salva il database, gli allegati e le chiavi in una cartella dati che dovrai includere nei backup. Creiamo una directory dedicata e un file .env<\/code> per le variabili sensibili, cos\u00ec da tenerle fuori dal file Compose.<\/p>\n\n\n\n
# Crea la struttura delle cartelle\nmkdir -p ~\/vaultwarden\/vw-data\ncd ~\/vaultwarden\n\n# Crea il file delle variabili d'ambiente\ncat > .env << 'EOF'\nDOMAIN=https:\/\/vault.tuodominio.it\nSIGNUPS_ALLOWED=true\nINVITATIONS_ALLOWED=true\nWEBSOCKET_ENABLED=true\nSIGNUPS_VERIFY=true\nEOF\n\n# Proteggi il file dalle letture non autorizzate\nchmod 600 .env<\/code><\/pre>\n\n\n\n
Una nota sulle variabili. DOMAIN<\/code> deve corrispondere esattamente all’URL pubblico con cui accederai, incluso https:\/\/<\/code>: \u00e8 usato per WebAuthn e per i link nelle email. SIGNUPS_ALLOWED=true<\/code> lo lasciamo attivo solo temporaneamente, per creare il primo account; lo disattiveremo nello Step 8 per impedire registrazioni indesiderate. WEBSOCKET_ENABLED=true<\/code> abilita le notifiche in tempo reale sui client. Dalla versione 1.30 in poi Vaultwarden gestisce i WebSocket internamente sulla stessa porta, quindi non serve pi\u00f9 esporre la porta 3012 separata come nelle vecchie guide.<\/p>\n\n\n\n
Step 3: Scrivere il file docker-compose.yml<\/h2>\n\n\n\n
Il cuore della configurazione \u00e8 il file Compose. Qui definiamo due servizi: Vaultwarden e Caddy come reverse proxy. Caddy si occupa di TLS automatico, inoltrando il traffico interno verso Vaultwarden sulla porta 80 del container. Crea il file docker-compose.yml<\/code> nella cartella ~\/vaultwarden<\/code>.<\/p>\n\n\n\n
services:\n  vaultwarden:\n    image: vaultwarden\/server:1.36.0\n    container_name: vaultwarden\n    restart: unless-stopped\n    env_file: .env\n    volumes:\n      - .\/vw-data:\/data\n    networks:\n      - vw-net\n\n  caddy:\n    image: caddy:2\n    container_name: caddy\n    restart: unless-stopped\n    ports:\n      - \"80:80\"\n      - \"443:443\"\n      - \"443:443\/udp\"\n    volumes:\n      - .\/Caddyfile:\/etc\/caddy\/Caddyfile:ro\n      - .\/caddy-data:\/data\n      - .\/caddy-config:\/config\n    networks:\n      - vw-net\n    depends_on:\n      - vaultwarden\n\nnetworks:\n  vw-net:<\/code><\/pre>\n\n\n\n
Abbiamo fissato l’immagine alla versione 1.36.0<\/code> invece di usare il tag latest<\/code>. \u00c8 una scelta deliberata: bloccare la versione rende gli aggiornamenti prevedibili e controllabili, evitando che un docker compose pull<\/code> tiri una release non testata. Quando vorrai aggiornare, modificherai il numero a mano dopo aver letto le note di rilascio. Nota anche che Vaultwarden non espone porte direttamente all’esterno: solo Caddy pubblica le porte 80 e 443. Tutto il resto avviene sulla rete interna vw-net<\/code>, riducendo la superficie di attacco.<\/p>\n\n\n\n
Step 4: Configurare Caddy per l’HTTPS automatico<\/h2>\n\n\n\n
Caddy ottiene e rinnova i certificati Let’s Encrypt senza intervento manuale, applica TLS 1.3 e imposta header di sicurezza moderni. Crea il file Caddyfile<\/code> nella stessa cartella. \u00c8 volutamente minimale: poche righe fanno il lavoro che con Nginx richiederebbe decine di direttive.<\/p>\n\n\n\n
vault.tuodominio.it {\n    # Inoltra il traffico a Vaultwarden sulla rete interna\n    reverse_proxy vaultwarden:80\n\n    # Header di sicurezza\n    header {\n        Strict-Transport-Security \"max-age=31536000; includeSubDomains; preload\"\n        X-Content-Type-Options \"nosniff\"\n        X-Frame-Options \"DENY\"\n        Referrer-Policy \"same-origin\"\n        -Server\n    }\n\n    # Log degli accessi (utile per fail2ban)\n    log {\n        output file \/data\/access.log\n        format json\n    }\n}<\/code><\/pre>\n\n\n\n
Sostituisci vault.tuodominio.it<\/code> con il tuo sottodominio reale. Alla prima esecuzione, Caddy contatta Let’s Encrypt, supera la sfida HTTP-01 e installa un certificato valido. Da quel momento, l’header HSTS<\/strong> impone ai browser di usare solo HTTPS per un anno, mentre X-Frame-Options: DENY<\/code> blocca i tentativi di clickjacking. Il log in formato JSON ci servir\u00e0 pi\u00f9 avanti per fail2ban. Se preferisci affinare la configurazione TLS, il generatore di configurazioni SSL di Mozilla<\/a> resta il riferimento per cipher suite e profili moderni.<\/p>\n\n\n\n
Step 5: Avviare lo stack e verificare<\/h2>\n\n\n\n
Con i tre file pronti (.env<\/code>, docker-compose.yml<\/code>, Caddyfile<\/code>), assicurati che il record DNS del tuo sottodominio punti gi\u00e0 all’IP del server, altrimenti Caddy non potr\u00e0 ottenere il certificato. Poi avvia tutto in background.<\/p>\n\n\n\n
# Avvia i container in modalit\u00e0 detached\ndocker compose up -d\n\n# Controlla che entrambi i servizi siano \"running\"\ndocker compose ps\n\n# Segui i log per verificare il rilascio del certificato\ndocker compose logs -f caddy<\/code><\/pre>\n\n\n\n
Nei log di Caddy cerca una riga come certificate obtained successfully<\/code>. Se compare, apri il browser su https:\/\/vault.tuodominio.it<\/code>: dovresti vedere la schermata di login di Bitwarden con il lucchetto verde. Premi Ctrl+C<\/kbd> per uscire dai log senza fermare i container. Se invece vedi errori ACME, consulta la sezione di risoluzione dei problemi: quasi sempre \u00e8 un problema di DNS o di porte chiuse.<\/p>\n\n\n\n
Una volta che la pagina di login risponde in HTTPS, hai un server Vaultwarden funzionante ed esposto in sicurezza. Ma non \u00e8 ancora pronto per la produzione: mancano il pannello admin protetto, la chiusura delle registrazioni e i backup. Procediamo.<\/p>\n\n\n\n
Step 6: Generare l’ADMIN_TOKEN con Argon2<\/h2>\n\n\n\n
Vaultwarden offre un pannello di amministrazione web all’indirizzo \/admin<\/code> per gestire utenti, organizzazioni e diagnostica. L’accesso \u00e8 protetto da un token. Le versioni recenti raccomandano di non salvare il token in chiaro, ma di memorizzarne l’hash Argon2<\/strong> in formato PHC, cos\u00ec che anche chi legge il file .env<\/code> non possa usarlo direttamente. Vaultwarden include un comando integrato per generarlo.<\/p>\n\n\n\n
# Genera un hash Argon2 PHC del token admin in modo interattivo\ndocker run --rm -it vaultwarden\/server:1.36.0 \\\n  \/vaultwarden hash --preset owasp\n\n# Ti verr\u00e0 chiesto di inserire e confermare una password robusta.\n# L'output sar\u00e0 una stringa come:\n# $argon2id$v=19$m=19456,t=2,p=1$base64salt$base64hash<\/code><\/pre>\n\n\n\n
Copia l’intera stringa $argon2id$...<\/code> generata. La master password che inserisci qui \u00e8 la chiave del pannello admin: scegline una lunga e unica, conservala in modo sicuro. Argon2id con il preset OWASP usa parametri di memoria e iterazioni resistenti agli attacchi con GPU e ASIC, lo stesso principio che approfondiamo nella nostra guida sull’hashing sicuro delle password<\/a>. Se preferisci, esiste anche il preset bitwarden<\/code>, ma owasp<\/code> \u00e8 il default consigliato.<\/p>\n\n\n\n
Step 7: Inserire il token e ricaricare lo stack<\/h2>\n\n\n\n
Ora aggiungiamo l’hash al file .env<\/code>. C’\u00e8 un dettaglio cruciale che fa inciampare molti: in un file .env<\/code> letto da Docker Compose, il simbolo $<\/code> viene interpretato come variabile. Devi quindi raddoppiare ogni $<\/code> in $$<\/code>, oppure racchiudere il valore tra apici singoli a seconda di come Compose gestisce il file.<\/p>\n\n\n\n
# Apri il file .env con l'editor\nnano ~\/vaultwarden\/.env\n\n# Aggiungi la riga ADMIN_TOKEN raddoppiando ogni simbolo $\n# Esempio (sostituisci con il TUO hash):\nADMIN_TOKEN='$$argon2id$$v=19$$m=19456,t=2,p=1$$c2FsdA$$aGFzaA'\n\n# Salva (Ctrl+O, Invio) ed esci (Ctrl+X), poi ricarica\ncd ~\/vaultwarden\ndocker compose up -d<\/code><\/pre>\n\n\n\n
Dopo il riavvio, visita https:\/\/vault.tuodominio.it\/admin<\/code>. Inserisci la master password che hai scelto nello Step 6 (non l’hash) e dovresti entrare nel pannello. Se ricevi un errore di accesso, quasi sempre \u00e8 colpa dei simboli $<\/code> non raddoppiati: torna al file, controlla l’escape e ricarica. In alternativa, puoi disabilitare del tutto il pannello admin lasciando ADMIN_TOKEN<\/code> vuoto, scelta valida se preferisci gestire tutto da riga di comando.<\/p>\n\n\n\n
Step 8: Creare il primo account e chiudere le registrazioni<\/h2>\n\n\n\n
Questo \u00e8 l’ordine corretto: prima crei il tuo account, poi blocchi le registrazioni pubbliche. Apri https:\/\/vault.tuodominio.it<\/code>, clicca su “Crea account” e registra la tua utenza principale con una master password forte e univoca. Questa password non \u00e8 recuperabile: se la perdi, perdi l’accesso al vault, quindi annotala in un luogo sicuro offline.<\/p>\n\n\n\n
Subito dopo, disattiva le registrazioni per impedire che estranei creino account sul tuo server. Modifica il file .env<\/code> impostando SIGNUPS_ALLOWED=false<\/code> e ricarica lo stack. D’ora in poi i nuovi utenti potranno entrare solo tramite invito dal pannello admin o da un’organizzazione.<\/p>\n\n\n\n
# Modifica .env: disattiva le registrazioni aperte\nsed -i 's\/SIGNUPS_ALLOWED=true\/SIGNUPS_ALLOWED=false\/' ~\/vaultwarden\/.env\n\n# Per accettare inviti solo su domini fidati, puoi aggiungere:\necho \"SIGNUPS_DOMAINS_WHITELIST=tuodominio.it\" >> ~\/vaultwarden\/.env\n\n# Applica le modifiche\ncd ~\/vaultwarden && docker compose up -d<\/code><\/pre>\n\n\n\n
Per aggiungere familiari o colleghi, vai nel pannello \/admin<\/code>, sezione utenti, e usa “Invite User”: riceveranno un’email per impostare la propria master password. In alternativa, crea un’organizzazione e invita i membri da l\u00ec, cos\u00ec potrai condividere collezioni di credenziali in modo strutturato. Ricorda: ogni utente ha una propria master password e un proprio vault cifrato; nemmeno tu, come amministratore, puoi leggere le loro password.<\/p>\n\n\n\n
Step 9: Installare e configurare i client Bitwarden<\/h2>\n\n\n\n
Il bello di Vaultwarden \u00e8 che usi le app ufficiali Bitwarden, senza software speciale. L’unico passaggio differente \u00e8 indicare al client l’URL del tuo server invece di quello cloud di Bitwarden. Funziona con l’estensione per Chrome, Firefox, Edge e Safari, con le app desktop e mobile.<\/p>\n\n\n\n