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

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

एक पासवर्ड मैनेजर जिस पर आपका पूर्ण स्वामित्व है: Vaultwarden, जो एक छोटे कंटेनर में HTTPS को terminate करने वाले reverse proxy के पीछे चल रहा है। आप अपने फोन, लैपटॉप और ब्राउज़र पर आधिकारिक Bitwarden ऐप्स का उपयोग करके इसे कनेक्ट करेंगे। Vaultwarden, Rust में Bitwarden सर्वर API को फिर से लागू करता है और bitwarden.com के समान प्रोटोकॉल का उपयोग करता है। इसलिए, हर आधिकारिक क्लाइंट बिना किसी बदलाव के इसके साथ काम करता है, लेकिन यह आधिकारिक multi-container स्टैक के बजाय लगभग 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 पर टेस्ट करें" जैसा कोई विकल्प नहीं है, वह तरीका काम नहीं करता है, जिसका ठोस कारण आगे बताया गया है।

आधिकारिक Bitwarden stack के बजाय Vaultwarden क्यों

क्लाइंट वही हैं, लेकिन संसाधन की खपत बहुत कम है। आधिकारिक self-hosted Bitwarden कई containers (MSSQL, Nginx, Identity, Api, Admin आदि) के एक समूह के रूप में आता है और इसे लगभग 2 GB RAM की आवश्यकता होती है। Vaultwarden एक single binary है जो डिफ़ॉल्ट रूप से सब कुछ एक SQLite database में स्टोर करता है और कुछ ही megabytes RAM का उपयोग करता है। एक व्यक्ति, परिवार या छोटी टीम के लिए यह स्पष्ट विकल्प है, और चूंकि यह Bitwarden API को पूरी तरह से लागू करता है, इसलिए आपका डेटा इसके और bitwarden.com के बीच पोर्टेबल रहता है।

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

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

Bitwarden वेब वॉल्ट और ब्राउज़र एक्सटेंशन Web Crypto API (window.crypto.subtle) का उपयोग करके ब्राउज़र में आपकी एन्क्रिप्शन कुंजियाँ (encryption keys) तैयार करते हैं। ब्राउज़र केवल secure context, HTTPS, या http://localhost के विशेष मामले में ही crypto.subtle को expose करते हैं। सादे 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 वेब वॉल्ट मिलना चाहिए और कोई सर्टिफिकेट चेतावनी नहीं आनी चाहिए।

चरण 3, एक मजबूत ADMIN_TOKEN, और $$ का जाल

ADMIN_TOKEN, /admin की सुरक्षा करता है, जो कि एक ऐसा पैनल है जो आपके इंस्टेंस पर हर उपयोगकर्ता और सेटिंग को पढ़ सकता है, इसलिए इसे root पासवर्ड की तरह ही समझें। इसके दो तरीके काम करते हैं।

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

हार्डन (hardened) तरीका एक Argon2 PHC हैश है, ताकि प्लेनटेक्स्ट टोकन कभी भी डिस्क पर स्टोर न हो। उसी इमेज के विरुद्ध एक जनरेट करें:

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

यह दो बार प्रॉम्प्ट करता है और $argon2id$v=19$... से शुरू होने वाली एक स्ट्रिंग प्रिंट करता है। यहाँ वह जाल है जिसमें लोगों का एक घंटा बर्बाद हो जाता है: Docker Compose $ को वेरिएबल इंटरपोलेशन के रूप में मानता है, इसलिए जब आप हैश को Compose फ़ाइल में पेस्ट करें तो आपको हर $ को दोगुना करके $$ करना होगा। इसे सीधे environment: के नीचे रखें, .env के माध्यम से नहीं, और इसे कोट्स (quotes) में न लपेटें:

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

यदि आप सिंगल $ साइन छोड़ देते हैं, तो Compose The "argon2id" variable is not set की चेतावनी देता है और टोकन को खाली कर देता है, और फिर /admin आपके सही पासवर्ड को अस्वीकार कर देता है। docker compose up -d चलाएं, और प्रॉम्प्ट पर टाइप किए गए प्लेनटेक्स्ट को अपने पासवर्ड स्टोर में सुरक्षित रखें।

चरण 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 कॉन्फ़िगर होना आवश्यक है ताकि आमंत्रित व्यक्ति को उनका लिंक प्राप्त हो सके।

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

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

यदि पेज 404 Not Found दिखाता है, तो ADMIN_TOKEN खाली या unset है, जो panel को पूरी तरह से disable कर देता है; यदि आपको इसकी कभी आवश्यकता नहीं है, तो यह एक वैध विकल्प है। यदि पेज load होता है लेकिन आपके token को reject कर देता है, तो नीचे दी गई failure सूची में $$ escaping trap देखें। क्या आप token भूल गए हैं? इसके लिए कोई recovery prompt नहीं है; .env या Compose file को edit करें, एक नया token set करें, और 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, लॉगिन एंडपॉइंट के लिए Fail2ban जेल

Vaultwarden हर विफल लॉगिन को LOG_FILE द्वारा सेट की गई फ़ाइल में लॉग करता है, जो कि ब्रूट-फोर्स सुरक्षा के लिए बिल्कुल आवश्यक है। यदि आप पहले से Fail2ban नहीं चला रहे हैं, तो इसका इंस्टॉलेशन और बुनियादी जानकारी Fail2ban SSH हार्डनिंग गाइड में दी गई है; यहाँ हम वॉल्ट के लिए एक जेल जोड़ रहे हैं।

सबसे पहले यह पता लगाएँ कि नामित वॉल्यूम होस्ट पर कहाँ स्थित है, ताकि Fail2ban लॉग को पढ़ सके:

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

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

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

और जेल बनाएँ:

# /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 के साथ रिलोड करें और sudo fail2ban-client status vaultwarden के साथ पुष्टि करें।

तीन Docker विवरण यह तय करते हैं कि क्या यह सुरक्षा प्रदान करेगा। पहला, यदि लॉग हर विफल प्रयास पर IP: 127.0.0.1 या आपके प्रॉक्सी का पता दिखाता है, तो Vaultwarden प्रॉक्सी को बैन कर रहा है। IP_HEADER को उस हेडर पर सेट करें जिसे आपका प्रॉक्सी वास्तव में भेजता है (Traefik के लिए X-Forwarded-For, ऊपर दिए गए nginx ब्लॉक के लिए X-Real-IP, Cloudflare के पीछे CF-Connecting-IP)। दूसरा, सही iptables चेन आपके प्रॉक्सी पर निर्भर करती है: यदि Traefik पब्लिश पोर्ट्स वाले कंटेनर के रूप में चल रहा है, तो ट्रैफ़िक Docker के FORWARD पथ से होकर गुजरता है, इसलिए बैन को ऊपर दिए अनुसार DOCKER-USER में होना चाहिए; लेकिन यदि आपने चरण 1 से host-nginx विकल्प चुना है, तो कनेक्शन होस्ट की INPUT चेन पर nginx पर समाप्त होते हैं और DOCKER-USER बैन उन्हें कभी नहीं देख पाता। उस स्थिति में chain = DOCKER-USER लाइन को हटा दें ताकि Fail2ban डिफ़ॉल्ट INPUT चेन का उपयोग करे। तीसरा, पोर्ट-आधारित डिफ़ॉल्ट के बजाय banaction = iptables-allports का उपयोग करें। यह जेल कोई पोर्ट परिभाषित नहीं करती है, और DOCKER-USER में ऑल-पोर्ट्स बैन अपराधी को बॉक्स पर मौजूद हर पब्लिश सर्विस से प्रभावी रूप से ब्लॉक कर देता है।

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

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 बैकअप है, जो आर्काइव को एन्क्रिप्ट करता है और बार-बार लिए गए स्नैपशॉट्स को डुप्लीकेट होने से बचाता है। एडमिन पैनल का Backup Database बटन केवल SQLite फाइल का एक उपयोगी हॉट स्नैपशॉट है, लेकिन इसमें अटैचमेंट और कीज़ शामिल नहीं होतीं।

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

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 खोलें। चूंकि localhost एक सुरक्षित संदर्भ है, इसलिए crypto.subtle उपलब्ध होता है और वॉल्ट यहाँ 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 अपरिभाषित है; इसे केवल https:// के माध्यम से एक्सेस करें और प्रॉक्सी पर HTTP-to-HTTPS रीडायरेक्ट जोड़ें।

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

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

धीमा क्रॉस-डिवाइस सिंक; कंसोल 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 एक ही हैं?

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

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

localhost टेस्ट के अलावा किसी भी अन्य उपयोग के लिए आपको HTTPS की आवश्यकता होती है। Bitwarden वेब वॉल्ट और एक्सटेंशन ब्राउज़र के Web Crypto API का उपयोग करते हैं, जो केवल सुरक्षित संदर्भ (secure context) में उपलब्ध होता है। इसलिए, सादे http पर क्लाइंट Cannot read properties of undefined एरर देता है और कभी लॉगिन नहीं होता। एकमात्र http पता जो काम करता है वह http://localhost है, यही कारण है कि स्टेप 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.* फाइलों को आर्काइव करें, फिर आर्काइव को सर्वर से बाहर कॉपी करें। इसे रात में चलने वाले cron जॉब के माध्यम से करना आदर्श है। सर्वर चलते समय लाइव SQLite फाइल को कॉपी करने से स्नैपशॉट के करप्ट होने का जोखिम रहता है, इसलिए इसे 'कोल्ड' (सर्वर बंद करके) स्थिति में लें। सबसे महत्वपूर्ण बात, इसे एक बार किसी अस्थायी कंटेनर में रिस्टोर करके लॉगिन करें, ताकि आप सुनिश्चित हो सकें कि बैकअप सही है और आप उस पर भरोसा कर सकते हैं।

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

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