VPS पर Vaultwarden कैसे सेटअप करें: पूरी गाइड

आप क्या बना रहे हैं

एक पासवर्ड मैनेजर जिस पर आपका पूर्ण नियंत्रण है: एक छोटे कंटेनर में चल रहा Vaultwarden, जो एक reverse proxy के पीछे है। यह proxy HTTPS termination का कार्य करता है। आपके फोन, लैपटॉप और ब्राउज़र पर मौजूद आधिकारिक Bitwarden ऐप्स इसी सर्वर से कनेक्ट होते हैं। Vaultwarden, Rust भाषा में Bitwarden सर्वर API को फिर से लागू करता है और bitwarden.com के समान प्रोटोकॉल का उपयोग करता है। इसलिए, आधिकारिक क्लाइंट्स बिना किसी बदलाव के इसके साथ काम करते हैं, बशर्ते आप सर्वर को अपडेट रखें (नए क्लाइंट releases के लिए कभी-कभी Vaultwarden के नए release की आवश्यकता होती है: 2026.8.0 और उससे नए क्लाइंट्स के लिए 1.37.2 आवश्यक है)। यह आधिकारिक स्टैक के विपरीत, जो कई कंटेनर्स का उपयोग करता है, केवल 100 MB RAM में चल जाता है।

इंस्टॉलेशन प्रक्रिया में Compose की केवल कुछ पंक्तियाँ शामिल हैं। तीन मुख्य बातें जो वास्तव में मायने रखती हैं और जिनमें खराबी आ सकती है, वे ये हैं: वेब वॉल्ट लोड करने से पहले TLS मौजूद होना चाहिए, अपना अकाउंट बनाने के तुरंत बाद public signups को बंद कर देना चाहिए, और डेटा वॉल्यूम का बैकअप लेकर उसे restore करके टेस्ट करना चाहिए, क्योंकि उस एक डायरेक्टरी में आपके सभी पासवर्ड सुरक्षित रहते हैं।

पूर्वापेक्षाएँ और महत्वपूर्ण सावधानियाँ

• Docker Engine और Compose plugin के साथ एक VPS, जो एक नए Ubuntu 24.04 KVM बॉक्स पर हो और जिसमें root या sudo एक्सेस हो। 512 MB RAM वास्तव में पर्याप्त है; 1 GB RAM के साथ यह आराम से चलता है। यह सबसे हल्के सॉफ्टवेयर में से एक है जिसे आप चला सकते हैं, और यह self-hosting के योग्य सेवाओं की सूची में सबसे ऊपर आता है। हालांकि, बॉक्स का आकार उस पर चलने वाली अन्य सेवाओं के अनुसार तय करें: यदि आप PhotoPrism या Immich जैसी self-hosted फोटो लाइब्रेरी को उसी VPS पर रखते हैं, तो RAM की आवश्यकता कई GB तक बढ़ जाती है, जबकि Vaultwarden बहुत कम RAM लेता है। यही गणित बाद में जोड़ी जाने वाली मीडिया फ्रंट-एंड सेवाओं पर भी लागू होता है, क्योंकि Jellyfin लाइब्रेरी को 90 के दशक के रेंटल स्टोर जैसा रूप देने का मतलब है एक और हमेशा चलने वाला कंटेनर और उसी बजट में transcoding के लिए अतिरिक्त क्षमता।
• एक डोमेन जिसमें A record (और यदि आपके पास IPv6 है तो AAAA record) हो, जो vault.example.com VPS की ओर इशारा करता हो। TLS certificate इसी सटीक नाम के लिए जारी किया जाता है, इसलिए काम शुरू करने से पहले DNS का resolve होना अनिवार्य है।
• पोर्ट 80 और 443 इंटरनेट के लिए खुले होने चाहिए और इन्हें आपके reverse proxy द्वारा terminate किया जाना चाहिए, कभी भी सीधे Vaultwarden द्वारा नहीं। पोर्ट 80 का उपयोग केवल ACME certificate challenge और HTTP-to-HTTPS redirect के लिए किया जाता है।
• सबसे बड़ी सावधानी: Bitwarden clients ऐसे सर्वर से जुड़ने से मना कर देते हैं जो HTTPS पर नहीं है। इसमें "पहले http पर टेस्ट करें" जैसा कोई विकल्प नहीं है, वह तरीका काम नहीं करता है, जिसका ठोस कारण आगे बताया गया है।

Vaultwarden क्यों, आधिकारिक Bitwarden stack क्यों नहीं

वही clients, लेकिन बहुत कम भार। आधिकारिक Bitwarden self-hosted deployment containers (MSSQL Express, Identity, Api, Admin और अन्य) के एक bundle के रूप में आता है और इसके लिए कम से कम 2 GB RAM की आवश्यकता होती है। Bitwarden, Bitwarden lite भी प्रदान करता है, जो एक single Docker image है जिसे कम से कम 200 MB RAM चाहिए, लेकिन यह व्यक्तिगत उपयोग और home labs के लिए है, न कि व्यवसाय के लिए, और इसमें database और उसके backups की पूरी जिम्मेदारी आपकी होती है। Vaultwarden एक single binary है जो डिफ़ॉल्ट रूप से सब कुछ एक SQLite database में store करता है और idle रहने पर कुछ tens of megabytes RAM का उपयोग करता है। एक व्यक्ति, परिवार या छोटी टीम के लिए यह स्पष्ट विकल्प है, और चूंकि यह Bitwarden API को पूरी तरह से लागू करता है, इसलिए आपका डेटा इसके और bitwarden.com के बीच portable रहता है।

आप जो छोड़ते हैं वह अधिकांश enterprise surface है: कोई SCIM provisioning नहीं (हालाँकि 1.35.0 में OpenID Connect SSO support आ गया है), और आप ही operator हैं, इसलिए patching, HTTPS और backups का काम आपका है। यह मार्गदर्शिका इन्हीं तीन कार्यों के बारे में है।

HTTPS वैकल्पिक क्यों नहीं है

Bitwarden वेब वॉल्ट और ब्राउज़र एक्सटेंशन Web Crypto API (window.crypto.subtle) का उपयोग करके ब्राउज़र में आपकी एन्क्रिप्शन कुंजियाँ तैयार करते हैं। ब्राउज़र केवल सुरक्षित संदर्भ (secure context), HTTPS, या http://localhost और http://127.0.0.1 जैसे लूपबैक पतों के विशेष मामलों में ही crypto.subtle को एक्सपोज़ करते हैं। सादे http://vault.example.com पर यह undefined होता है, इसलिए जैसे ही ऐप कुंजी तैयार करता है, यह त्रुटि देता है और कंसोल में यह दिखाई देता है:

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

पेज हैंग हो जाता है या एक सामान्य क्रिप्टो त्रुटि दिखाता है, और कुछ भी लॉग-इन नहीं होता। डेस्कटॉप, मोबाइल और ब्राउज़र क्लाइंट एक self-hosted URL के विरुद्ध अपना स्वयं का चेक चलाते हैं, और http (या अप्राप्य) एंडपॉइंट के विरुद्ध वे इस त्रुटि के साथ मना कर देते हैं:

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

दोनों का कारण एक ही है: कोई वैध HTTPS नहीं है। इसलिए हम सबसे पहले TLS सेटअप करते हैं और वॉल्ट को कभी भी http पर नहीं खोलते, यहाँ तक कि एक बार जल्दी देखने के लिए भी नहीं।

चरण 1, DNS और reverse proxy (TLS पहले)

अपने record को अपने VPS पर point करें और सुनिश्चित करें कि यह सही address पर resolve हो रहा है:

dig +short vault.example.com

इसके द्वारा print की गई line आपका VPS IP होनी चाहिए। यदि यह खाली है या गलत है, तो DNS को ठीक करें और TTL समाप्त होने की प्रतीक्षा करें, क्योंकि यदि नाम resolve नहीं होता है तो certificate issuance विफल हो जाता है।

HTTPS front end के लिए यह गाइड Traefik का उपयोग करती है, जो Let's Encrypt certificates को स्वचालित रूप से जारी और renew करता है और सीधे Compose में फिट हो जाता है। यदि आप इसे पहले से नहीं चला रहे हैं, तो पहले Traefik reverse proxy और स्वचालित TLS सेटअप का पालन करें; यह एक external Docker network (नीचे proxy) और एक ACME resolver (letsencrypt) बनाता है जिससे Vaultwarden service जुड़ती है। Vaultwarden की ओर से hand-issued certificate के साथ plain nginx भी बिल्कुल वैसा ही काम करता है।

क्या आप Traefik के बजाय nginx और Certbot को प्राथमिकता देते हैं? Vaultwarden को 127.0.0.1:8080 पर रखें (service में ports: ["127.0.0.1:8080:80"] जोड़ें और Traefik labels को हटा दें), फिर एक certificate जारी करें और उस पर proxy करें। certificate वाला भाग Certbot और nginx के साथ Let's Encrypt certificates जारी करना में कवर किया गया है। notifications path पर WebSocket upgrade सबसे महत्वपूर्ण अतिरिक्त चरण है:

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

X-Real-IP line पर ध्यान दें, यही वह है जो बाद में Fail2ban को 127.0.0.1 के बजाय वास्तविक attacker को देखने देती है। इस गाइड में बाकी सब कुछ समान है, चाहे सामने Traefik हो या nginx।

चरण 2, Compose फ़ाइल

सबसे पहले प्रोजेक्ट डायरेक्टरी बनाएँ। यह गाइड /opt/vaultwarden का उपयोग करती है, जो Compose प्रोजेक्ट के नाम को, और परिणामस्वरूप डेटा वॉल्यूम को, vaultwarden_vw-data के रूप में पूर्वानुमानित (predictable) बनाता है; नीचे दिए गए Fail2ban और बैकअप चरण उसी सटीक नाम पर निर्भर करते हैं।

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

उस डायरेक्टरी में एडमिन सीक्रेट और Compose फ़ाइल के लिए एक .env बनाएँ।

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

उस टोकन को openssl rand -base64 48 के साथ जनरेट करें और उसे पेस्ट करें। (एक अधिक मजबूत हैशेड फॉर्म आगे बताया गया है; शुरुआत के लिए एक लंबी रैंडम स्ट्रिंग पर्याप्त है।)

# 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

इस फ़ाइल के बारे में दो बातें पूरे डिज़ाइन को निर्धारित करती हैं। इसमें कोई ports: मैपिंग नहीं है, इसलिए Vaultwarden केवल Traefik और उसके TLS के माध्यम से ही पहुँच योग्य है; होस्ट पर पोर्ट पब्लिश करना ही वह तरीका है जिससे लोग गलती से वॉल्ट को http पर सर्व कर देते हैं। और DOMAIN को पूर्ण सार्वजनिक HTTPS URL होना चाहिए: यह अटैचमेंट लिंक, WebAuthn 2FA और नोटिफिकेशन एंडपॉइंट में इनबिल्ट होता है, इसलिए गलत या http मान होने पर साइट लोड होने के बावजूद ये सुविधाएँ काम नहीं करेंगी। latest टैग सामान्य 'कभी भी latest न करें' नियम का एक जानबूझकर किया गया अपवाद है, Vaultwarden अपने स्टेबल रिलीज़ को एक सिंगल रोलिंग इमेज के रूप में शिप करता है, जिसमें :testing अलग प्री-रिलीज़ चैनल है, इसलिए सोच-समझकर अपडेट करें और पुल करने से पहले रिलीज़ नोट्स को देख लें। हालाँकि, यह अपवाद सीमित है: अधिकांश लंबे समय तक चलने वाले कंटेनरों को एक सटीक टैग पर पिन करना बेहतर होता है, जो उसी VPS पर होस्ट किए गए हमेशा चालू रहने वाले एजेंट को रीबूट और पुल के दौरान स्थिर रखता है।

इसे स्टार्ट करें और लॉग देखें:

docker compose up -d
docker compose logs -f vaultwarden

एक सही शुरुआत Rocket has launched from http://0.0.0.0:80 जैसी लाइन के साथ समाप्त होती है। Traefik को सर्टिफिकेट प्राप्त करने के लिए कुछ सेकंड दें, फिर https://vault.example.com लोड करें, आपको एक वैध पैडलॉक के साथ Bitwarden वेब वॉल्ट मिलना चाहिए और कोई सर्टिफिकेट चेतावनी नहीं आनी चाहिए।

Step 3, एक मजबूत ADMIN_TOKEN, और $$ ट्रैप

ADMIN_TOKEN, /admin को सुरक्षित करता है, जो कि एक ऐसा पैनल है जो आपकी instance पर मौजूद हर user और setting को पढ़ सकता है, इसलिए इसे root password की तरह ही सुरक्षित रखें। इसके लिए दो तरीके काम करते हैं।

सरल तरीका वह random string है जिसे आपने पहले ही openssl rand -base64 48 के साथ generate किया है। चूंकि base64 में कभी भी $ नहीं होता है, इसलिए यह बिना किसी escaping के सीधे .env में काम करता है।

hardened तरीका एक Argon2 PHC hash है, ताकि plaintext token कभी भी disk पर store न हो। उसी image का उपयोग करके एक hash generate करें:

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

यह आपसे दो बार input मांगेगा और $argon2id$v=19$... से शुरू होने वाली एक string print करेगा। यहाँ वह ट्रैप है जिसमें लोगों का एक घंटा बर्बाद हो जाता है: Docker Compose, $ को variable interpolation की तरह मानता है, इसलिए यदि आप hash को सीधे Compose file में environment: के नीचे paste करते हैं, तो आपको हर $ को $$ में double करना होगा। वहाँ value को quote करना ठीक है; escaping ही मुख्य बात है:

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

यदि आप hash को .env में रखना पसंद करते हैं, तो नियम बदल जाता है: single $ signs को वैसे ही रहने दें, पूरी value को single quotes (ADMIN_TOKEN='$argon2id$v=19$...') में लपेटें, और Compose file में मौजूद ${ADMIN_TOKEN} line इसे उठा लेगी। .env में $ को कभी भी double न करें। यदि आप Compose file में ही single $ signs छोड़ देते हैं, तो Compose The "argon2id" variable is not set की चेतावनी देता है और token को खाली कर देता है, और फिर /admin आपके सही password को अस्वीकार (reject) कर देता है। docker compose up -d चलाएं, और prompt पर टाइप किए गए plaintext को अपने password store में सुरक्षित रखें।

चरण 4, अपना अकाउंट रजिस्टर करें, फिर दरवाजा बंद करें

SIGNUPS_ALLOWED: "true" के साथ, https://vault.example.com खोलें, Create account पर क्लिक करें, और अपने ईमेल तथा एक मजबूत मास्टर पासवर्ड के साथ रजिस्टर करें। यह मास्टर पासवर्ड कभी भी रिकवर नहीं किया जा सकता, इसे रीसेट करने का कोई विकल्प नहीं है, इसलिए इसे पहले किसी सुरक्षित स्थान पर लिख लें।

अब दरवाजा बंद करें। Compose फाइल को एडिट करें ताकि साइनअप बंद हो जाए:

      SIGNUPS_ALLOWED: "false"

docker compose up -d के साथ दोबारा अप्लाई करें। यह ऐसी सुरक्षा नहीं है जिसे आप टाल सकें। यदि इसे खुला छोड़ दिया गया, तो कोई भी व्यक्ति जिसे URL मिल जाए (और क्रॉलर इसे ढूंढ ही लेते हैं), आपके सर्वर पर अकाउंट बना सकता है। वे आपके vault को नहीं पढ़ सकते, लेकिन वे संसाधनों का उपयोग करेंगे और आपके निजी इंस्टेंस को एक ओपन सर्विस बना देंगे। यदि आपने इसे खुला छोड़ दिया है, तो इसका संकेत यह है: /admin उन अकाउंट्स की सूची दिखाएगा जिन्हें आपने कभी बनाया ही नहीं था।

बाद में परिवार या टीम के सदस्यों को जोड़ने के लिए, पब्लिक साइनअप को दोबारा खोले बिना, /admin में Invite User बटन का उपयोग करें; उस प्रक्रिया के लिए SMTP कॉन्फ़िगर होना आवश्यक है ताकि आमंत्रित व्यक्ति को उनका लिंक प्राप्त हो सके।

Step 5, /admin तक पहुँचना

https://vault.example.com/admin पर ब्राउज़ करें और plaintext admin token दर्ज करें (वह random string, या वह password जिसे आपने hash किया है, न कि स्वयं hash)। इसके अंदर आप users की सूची देख सकते हैं, settings को tune कर सकते हैं, test email भेज सकते हैं और database snapshot ले सकते हैं।

यदि पेज इसके बजाय The admin panel is disabled, please configure the 'ADMIN_TOKEN' variable to enable it दिखाता है, तो ADMIN_TOKEN खाली है या unset है, जो panel को पूरी तरह से disable कर देता है। यदि आपको इसकी कभी आवश्यकता नहीं है, तो यह एक वैध विकल्प है। यदि पेज लोड होता है लेकिन आपके token को अस्वीकार कर देता है, तो नीचे दी गई विफलता सूची में $$ escaping trap देखें। क्या आप token भूल गए हैं? इसके लिए कोई recovery prompt नहीं है; .env या Compose file को edit करें, एक नया token सेट करें, और docker compose up -d करें।

चरण 6, Bitwarden clients को कनेक्ट करें

प्रत्येक आधिकारिक client को self-hosted सर्वर की ओर पॉइंट किया जा सकता है, इसलिए सामान्य stores से Bitwarden desktop, mobile या browser client इंस्टॉल करें। आपको किसी विशेष Vaultwarden build की आवश्यकता नहीं है।

लॉग इन करने से पहले, लॉग इन स्क्रीन पर सेटिंग्स गियर खोलें (जिसे Self-hosted या Region → Self-hosted लेबल किया गया है), Server URL को https://vault.example.com पर सेट करें और save करें। फिर उस ईमेल और मास्टर पासवर्ड के साथ लॉग इन करें जिसे आपने रजिस्टर किया था; client को तुरंत कनेक्ट हो जाना चाहिए और credentials को भरने और save करने का विकल्प देना चाहिए।

यदि कोई client This is not a recognized Bitwarden server. You may need to check with your provider or update your server. दिखाता है, तो इसका मतलब है कि URL गलत है, http का उपयोग कर रहा है, या certificate पर भरोसा नहीं किया जा सकता है। पहले यह दोबारा जाँच लें कि https://vault.example.com ब्राउज़र में ठीक से लोड हो रहा है या नहीं। अन्य उपकरणों पर धीमे अपडेट WebSocket push के कारण होते हैं, जिसे नीचे कवर किया गया है।

चरण 7, login endpoint के लिए एक Fail2ban jail

Vaultwarden हर विफल login प्रयास को LOG_FILE द्वारा निर्धारित फ़ाइल में log करता है, जो कि brute-force सुरक्षा के लिए आवश्यक है। यदि आप पहले से Fail2ban नहीं चला रहे हैं, तो इसका installation और बुनियादी जानकारी Fail2ban SSH hardening guide में दी गई है; यहाँ हम vault के लिए एक jail जोड़ेंगे।

सबसे पहले यह पता लगाएँ कि host पर named volume कहाँ स्थित है, ताकि Fail2ban log को पढ़ सके:

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

यह /var/lib/docker/volumes/vaultwarden_vw-data/_data जैसा कुछ print करेगा; log इसके अंदर vaultwarden.log पर स्थित है। filter बनाएँ:

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

और 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

sudo systemctl restart fail2ban के साथ reload करें और sudo fail2ban-client status vaultwarden के साथ पुष्टि करें।

तीन Docker विवरण यह तय करते हैं कि क्या यह सुरक्षा प्रदान करता है। पहला, यदि log में हर विफल प्रयास पर IP: 127.0.0.1 या आपके proxy का address दिखाई देता है, तो Vaultwarden proxy को ही ban कर रहा है। IP_HEADER को उस header पर set करें जिसे आपका proxy वास्तव में भेजता है (Traefik के लिए X-Forwarded-For, ऊपर दिए गए nginx block के लिए X-Real-IP, Cloudflare के पीछे CF-Connecting-IP)। 1.37.4 के बाद से, X-Forwarded-For के साथ Vaultwarden उस rightmost address को लेता है जो IP_HEADER_TRUSTED_PROXIES में नहीं है (default local, जो उसी host या Docker network पर मौजूद proxy को कवर करता है)। इसलिए यदि आपके proxy के सामने कोई CDN है, तो उसके addresses को भी वहाँ list करें। दूसरा, सही iptables chain आपके proxy पर निर्भर करती है: यदि Traefik published ports वाले container के रूप में चल रहा है, तो traffic Docker के FORWARD path से गुजरता है, इसलिए ban को ऊपर बताए अनुसार DOCKER-USER में होना चाहिए। लेकिन यदि आपने चरण 1 से host-nginx विकल्प चुना है, तो connections host की INPUT chain पर nginx पर समाप्त होते हैं और DOCKER-USER ban उन्हें कभी नहीं देख पाता। उस स्थिति में chain = DOCKER-USER line को हटा दें ताकि Fail2ban default INPUT chain का उपयोग करे। तीसरा, port-आधारित default के बजाय banaction = iptables-allports का उपयोग करें। यह jail कोई port परिभाषित नहीं करती है, और DOCKER-USER में all-ports ban अपराधी को box पर मौजूद हर published service से प्रभावी ढंग से block कर देता है।

चरण 8, vault का बैकअप लें, फिर वास्तव में इसे रिस्टोर करें

vw-data वॉल्यूम ही आपका पासवर्ड मैनेजर है। इसमें db.sqlite3 (हर एंट्री), attachments/ और sends/ डायरेक्टरी, rsa_key.* फाइलें जो लॉगिन सेशन को साइन करती हैं, और एडमिन पैनल से config.json शामिल होते हैं। यदि बैकअप में इनमें से कुछ भी छूट जाता है, तो जरूरत पड़ने पर वह काम नहीं करेगा।

Vaultwarden के लिखते समय db.sqlite3 को कॉपी करने से आधी-अधूरी या करप्ट फाइल मिल सकती है, इसलिए एक कोल्ड स्नैपशॉट लें, इसमें केवल कुछ सेकंड का डाउनटाइम लगता है:

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

इसे हर रात cron से चलाएं और .tgz को सर्वर से बाहर कॉपी करें; जिस सर्वर को आप सुरक्षित कर रहे हैं, केवल उसी पर रखा गया बैकअप वास्तव में बैकअप नहीं है। इसे भेजने का सही तरीका किसी अन्य सर्वर या ऑब्जेक्ट स्टोरेज पर nightly restic बैकअप है, जो आर्काइव को एन्क्रिप्ट करता है और बार-बार लिए गए स्नैपशॉट्स को डी-डुप्लिकेट (deduplicate) करता है। एडमिन पैनल का Backup Database बटन केवल SQLite फाइल का एक उपयोगी हॉट स्नैपशॉट है, लेकिन इसमें अटैचमेंट्स और कीज़ (keys) शामिल नहीं होतीं।

अब वह प्रक्रिया जो एक वास्तविक बैकअप को केवल उम्मीद वाले बैकअप से अलग करती है, इसे एक बार रिस्टोर करें और साबित करें कि यह काम करता है:

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

अपने लैपटॉप से, ssh -L 8888:127.0.0.1:8888 you@your-vps के साथ टनल बनाएं और http://localhost:8888 (या http://127.0.0.1:8888) खोलें। चूंकि लूपबैक एड्रेस को सुरक्षित संदर्भ माना जाता है, इसलिए crypto.subtle उपलब्ध होता है और vault यहाँ plain http पर डिक्रिप्ट हो जाता है, जो कि एकमात्र ऐसा एड्रेस है जहाँ इसकी अनुमति है। अपने मास्टर पासवर्ड से लॉगिन करें और पुष्टि करें कि आपकी एंट्रीज़ मौजूद हैं: यदि वे हैं, तो आपका डेटाबेस, RSA कीज़ और मास्टर पासवर्ड सभी सही तरह से काम कर रहे हैं, और आप मिनटों में एक नए VPS पर इसे फिर से खड़ा कर सकते हैं। Ctrl-C के साथ कंटेनर को रोकें और /tmp/vw-restore को डिलीट कर दें। बॉक्स पर मौजूद किसी भी अन्य एडमिन UI के लिए उस टनलिंग की आदत बनाए रखें जिसे कभी भी इंटरनेट का सामना नहीं करना चाहिए, इसी तरह आप पोर्ट 5173 पर self-hosted open-kritt security scanner तक भी पहुँच सकते हैं।

विफलता के प्रकार और दिखाई देने वाले संदेश

ब्राउज़र कंसोल में Cannot read properties of undefined (reading 'importKey')। वॉल्ट को http के माध्यम से लोड किया गया था, इसलिए crypto.subtle अपरिभाषित (undefined) है; इसे केवल https:// के माध्यम से एक्सेस करें और प्रॉक्सी पर HTTP-to-HTTPS रीडायरेक्ट जोड़ें।

क्लाइंट में This is not a recognized Bitwarden server...। सर्वर URL http है, गलत टाइप किया गया है, या सर्टिफिकेट अविश्वसनीय है; पुष्टि करें कि https://vault.example.com एक वैध पैडलॉक (ताला) दिखाता है, फिर क्लाइंट की self-hosted सेटिंग्स में इसे पुनः दर्ज करें।

/admin सही पासवर्ड को अस्वीकार करता है। Argon2 हैश का एस्केपिंग (escaping) हट गया है, Compose फ़ाइल में प्रत्येक $ को $$ होना चाहिए (लेकिन .env में सिंगल कोट्स के अंदर सिंगल $), या आपने उस प्लेनटेक्स्ट के बजाय हैश दर्ज किया है जिसे वह दर्शाता है।

धीमा क्रॉस-डिवाइस सिंक; कंसोल WebSocket connection to 'wss://vault.example.com/notifications/hub' failed दिखाता है। प्रॉक्सी Upgrade/Connection हेडर को फॉरवर्ड नहीं कर रहा है; Traefik इसे स्वचालित रूप से करता है, nginx को स्टेप 1 से दो अपग्रेड लाइनों की आवश्यकता होती है। वॉल्ट अभी भी काम करता है, बस खोलने पर सिंक होता है। v1.31.0 के बाद से पुराना समर्पित पोर्ट 3012 हटा दिया गया है, इसलिए किसी अलग WebSocket रूट की आवश्यकता नहीं है।

Fail2ban बैन की रिपोर्ट करता है लेकिन हमलावर कनेक्ट करना जारी रखता है। यह 127.0.0.1 को बैन कर रहा है क्योंकि IP_HEADER गलत है, या बैन गलत iptables चेन में है, chain = DOCKER-USER और banaction = iptables-allports सेट करें।

Upgrades

नया image pull करें और container को recreate करें; named volume और आपका सारा डेटा सुरक्षित रहता है:

docker compose pull
docker compose up -d

Vaultwarden के frequent releases आते रहते हैं। किसी विशिष्ट patch version को pin करने के बजाय project's release notes पर नज़र रखें, क्योंकि कुछ releases में migration notes शामिल होते हैं। किसी भी major version update से पहले एक नया backup लें; आप tarball को एक नए volume में restore करके rollback कर सकते हैं।

FAQ

क्या Vaultwarden और Bitwarden एक ही हैं?

यह एक संगत, स्वतंत्र सर्वर है, आधिकारिक सर्वर नहीं। Vaultwarden ने Rust में Bitwarden सर्वर API को फिर से लागू किया है, इसलिए आधिकारिक डेस्कटॉप, मोबाइल, ब्राउज़र और CLI क्लाइंट इसके साथ काम करते हैं, जबकि यह आधिकारिक स्टैक के मुकाबले बहुत कम संसाधनों का उपयोग करता है। वॉल्ट का फॉर्मेट समान है, इसलिए आप एक्सपोर्ट और इम्पोर्ट करके किसी भी दिशा में माइग्रेट कर सकते हैं।

क्या मुझे वास्तव में HTTPS की आवश्यकता है, या मैं इसे अपने LAN पर http के माध्यम से चला सकता हूँ?

लूपबैक टेस्ट के अलावा किसी भी चीज़ के लिए आपको HTTPS की आवश्यकता है। Bitwarden वेब वॉल्ट और एक्सटेंशन ब्राउज़र के Web Crypto API का उपयोग करते हैं, जो केवल सुरक्षित संदर्भ (secure context) में उपलब्ध होता है। इसलिए, सादे http पर क्लाइंट Cannot read properties of undefined त्रुटि देता है और कभी लॉग इन नहीं करता है। केवल लूपबैक पते जैसे http://localhost या http://127.0.0.1 ही http पर काम करते हैं, यही कारण है कि स्टेप 8 में रिस्टोर टेस्ट के लिए SSH टनल का उपयोग किया गया है।

मैं अजनबियों को अपने सर्वर पर रजिस्टर करने से कैसे रोकूँ?

अपना अकाउंट बनाने के तुरंत बाद, Compose फ़ाइल में SIGNUPS_ALLOWED: "false" सेट करें और docker compose up -d चलाएँ। उसके बाद, नए लोगों को /admin में Invite User बटन के माध्यम से जोड़ें, जिसके लिए SMTP कॉन्फ़िगर होना आवश्यक है ताकि उन्हें आमंत्रण लिंक प्राप्त हो सके। यह सुनिश्चित करने के लिए कि कोई अनपेक्षित अकाउंट नहीं बना है, समय-समय पर एडमिन यूजर लिस्ट की जाँच करें।

मैं अपने Vaultwarden वॉल्ट का बैकअप कैसे लूँ?

कंटेनर को संक्षेप में रोकें और पूरे vw-data वॉल्यूम, db.sqlite3, attachments/, sends/, config.json और rsa_key.* फ़ाइलों को आर्काइव करें, फिर आर्काइव को सर्वर से बाहर कॉपी करें, आदर्श रूप से इसे nightly cron पर सेट करें। सर्वर के चलते समय लाइव SQLite फ़ाइल को कॉपी करने से स्नैपशॉट के करप्ट होने का जोखिम रहता है, इसलिए इसे 'कोल्ड' (सर्वर बंद करके) लें। सबसे महत्वपूर्ण बात, इसे एक बार एक अस्थायी कंटेनर में रिस्टोर करें और लॉग इन करके देखें, ताकि आप सुनिश्चित हो सकें कि बैकअप वास्तविक है, इससे पहले कि आप उस पर निर्भर हों।

क्या अपने पासवर्ड को खुद होस्ट करना वास्तव में सुरक्षित है?

हाँ, यदि आप उन तीन चीजों का पालन करते हैं जो यह गाइड कवर करती है: वास्तविक HTTPS, बंद साइनअप के साथ एक मजबूत एडमिन टोकन, और टेस्ट किए गए बैकअप। आपका वॉल्ट आपके मास्टर पासवर्ड के साथ क्लाइंट-साइड पर एन्क्रिप्ट होता है, इसलिए सर्वर भी आपके पासवर्ड को स्पष्ट रूप से नहीं देख सकता है, और चोरी हुआ db.sqlite3 भी मास्टर पासवर्ड के बिना आपकी प्रविष्टियों (entries) को प्रकट नहीं करता है। यह अभी भी अकाउंट ईमेल और प्रत्येक मास्टर पासवर्ड से प्राप्त साल्टेड हैश को रखता है, जिसे एक हमलावर ऑफलाइन क्रैक करने का प्रयास कर सकता है, इसलिए डेटाबेस फ़ाइल और उसकी हर कॉपी को सुरक्षित रखें। इसमें समझौता यह है कि पैचिंग और बैकअप अब आपकी जिम्मेदारी है, यही कारण है कि Fail2ban और रिस्टोर प्रक्रिया यहाँ वैकल्पिक नहीं हैं। एक बार जब ये चीजें लागू हो जाती हैं, तो सेल्फ-होस्टेड वॉल्ट पर कहाँ हमला किया जा सकता है, इस पर एक विस्तृत नज़र डालना अगला उपयोगी कदम है, क्योंकि क्लाइंट में प्रविष्टियाँ स्वयं एन्क्रिप्टेड होने के कारण, बचाव के लिए केवल एडमिन टोकन और बैकअप आर्काइव ही बचते हैं।