تحریر: Matt Connor 2026-07-15 · اپ ڈیٹ شدہ 2026-08-29

VPS پر Vaultwarden: اپنا password manager چلائیں

Q: کیا مجھے واقعی HTTPS درکار ہے، یا میں اسے اپنے LAN پر http کے ذریعے چلا سکتا ہوں؟

localhost test کے علاوہ ہر صورت میں HTTPS درکار ہے۔ Bitwarden web vault اور extensions، browser کی Web Crypto API استعمال کرتے ہیں، جو صرف secure context میں دستیاب ہوتی ہے۔ اس لیے plain http پر client Cannot read properties of undefined دکھاتا ہے اور login نہیں کرتا۔ صرف http://localhost والا http address کام کرتا ہے، اسی وجہ سے Step 8 میں restore test کے لیے SSH tunnel استعمال کیا گیا ہے۔

Q: میں اجنبی لوگوں کو اپنے server پر register کرنے سے کیسے روکوں؟

Compose file میں SIGNUPS_ALLOWED: "false" set کریں اور اپنا account بنانے کے فوراً بعد docker compose up -d چلائیں۔ اس کے بعد /admin میں Invite User button کے ذریعے نئے لوگوں کو شامل کریں۔ اس کے لیے SMTP configured ہونا چاہیے تاکہ انہیں invitation link موصول ہو۔ کبھی کبھار admin user list دیکھ کر تصدیق کریں کہ کوئی غیر متوقع account شامل نہیں ہوا۔

Q: میں اپنے Vaultwarden vault کا backup کیسے بناؤں؟

Container کو مختصر وقت کے لیے stop کریں اور پورے vw-data volume، db.sqlite3، attachments/، sends/، config.json اور rsa_key.* files کو archive کریں۔ پھر archive کو server سے باہر copy کریں، بہتر ہے کہ یہ کام nightly cron کے ذریعے ہو۔ Server چلتے وقت live SQLite file copy کرنے سے corrupt snapshot بننے کا خطرہ ہوتا ہے، اس لیے اسے cold حالت میں copy کریں۔ سب سے اہم بات یہ ہے کہ اسے ایک بار عارضی container میں restore کر کے login کریں، تاکہ اس backup پر انحصار کرنے سے پہلے معلوم ہو جائے کہ یہ واقعی قابلِ استعمال ہے۔

Docker کے ساتھ VPS پر Vaultwarden تعینات کریں۔ TLS پہلے فعال کریں، account بناتے ہی public signups بند کریں، اور 100 MB data volume کا backup بحال کر کے جانچیں۔

آپ کیا بنا رہے ہیں

ایک ایسا password manager جس کا مکمل اختیار آپ کے پاس ہو: Vaultwarden ایک چھوٹے container میں چل رہا ہو، reverse proxy کے پیچھے ہو جو HTTPS termination کرے، اور آپ کے فون، laptop اور browser پر موجود official Bitwarden apps اسی server سے منسلک ہوں۔ Vaultwarden Rust میں Bitwarden server API کو دوبارہ implement کرتا ہے اور bitwarden.com جیسا ہی protocol استعمال کرتا ہے۔ اس لیے ہر official client میں کسی تبدیلی کے بغیر اس کے ساتھ کام کرتا ہے۔ تاہم، یہ official stack کے متعدد containers کے بجائے تقریباً 100 MB RAM میں چل جاتا ہے۔

تنصیب کے لیے Compose کی صرف ایک درجن سطریں درکار ہیں۔ اصل اہمیت رکھنے والی اور عموماً ناکام ہونے والی تین باتیں یہ ہیں: web vault پہلی بار کھولنے سے پہلے TLS فعال ہونا چاہیے، اپنا account بناتے ہی public signups بند کر دینے چاہییں، اور data volume کا backup لے کر test restore کرنا چاہیے، کیونکہ اسی ایک directory میں آپ کے تمام passwords محفوظ ہوتے ہیں۔

ضروری شرائط اور اہم عملی نکات

ایک VPS درکار ہے جس پر Docker Engine اور Compose plugin نصب ہوں۔ یہ ایک نئے Ubuntu 24.04 KVM سرور پر ہو، اور آپ کے پاس root یا sudo کی سہولت ہو۔ 512 MB RAM واقعی کافی ہے؛ 1 GB زیادہ آرام دہ ہے۔ یہ ان ہلکی ترین ایپس میں شامل ہے جنہیں آپ چلا سکتے ہیں، اور خود میزبانی کے قابل سروسز کی مختصر فہرست میں نمایاں مقام رکھتی ہے۔ تاہم سرور کا سائز اس پر چلنے والی دیگر ایپس کے مطابق منتخب کریں: اسی VPS پر PhotoPrism یا Immich جیسی self-hosted photo library چلانے سے RAM کی کم از کم ضرورت کئی گیگابائٹس تک پہنچ جاتی ہے، جبکہ Vaultwarden کی وجہ سے یہ ضرورت تقریباً نہیں بڑھتی۔ یہی حساب بعد میں شامل کیے جانے والے media front ends پر بھی لاگو ہوتا ہے، کیونکہ Jellyfin library کو 90s کی ایسی rental store میں تبدیل کرنا جس میں صارف چل پھر سکے اسی وسائل میں ایک اور مستقل چلنے والا container اور transcoding کے لیے اضافی گنجائش درکار بناتا ہے۔
ایک domain درکار ہے جس کا A record (اور IPv6 دستیاب ہو تو AAAA record) vault.example.com کو VPS کی طرف point کرتا ہو۔ TLS certificate اسی نام کے لیے جاری کیا جاتا ہے، اس لیے شروع کرنے سے پہلے DNS کا resolve ہونا ضروری ہے۔
Ports 80 اور 443 internet کے لیے کھلے ہوں اور انہیں آپ کا reverse proxy terminate کرے، Vaultwarden براہ راست کبھی نہیں۔ Port 80 صرف ACME certificate challenge اور HTTP-to-HTTPS redirect کے لیے استعمال ہوتا ہے۔
آغاز ہی میں سب سے اہم عملی نکتہ یہ ہے: Bitwarden clients ایسے server سے رابطہ نہیں کرتے جو HTTPS استعمال نہ کر رہا ہو۔ "پہلے اسے http پر آزما لیں" ممکن نہیں؛ یہ طریقہ کام نہیں کرتا، اور اس کی ٹھوس وجہ اگلے حصے میں بیان کی گئی ہے۔

Vaultwarden، official Bitwarden stack کے بجائے کیوں

وہی clients، مگر وسائل کی ضرورت کا ایک حصہ۔ official self-hosted Bitwarden متعدد containers کے bundle کے طور پر فراہم ہوتا ہے، جن میں MSSQL، Nginx، Identity، Api، Admin اور دیگر components شامل ہیں، اور اسے تقریباً 2 GB RAM درکار ہوتی ہے۔ Vaultwarden ایک single binary ہے جو default طور پر تمام data کو SQLite database میں محفوظ کرتا ہے اور idle حالت میں چند دسیوں megabytes استعمال کرتا ہے۔ ایک فرد، خاندان یا چھوٹی team کے لیے یہ واضح انتخاب ہے۔ چونکہ یہ Bitwarden API کو درست طور پر implement کرتا ہے، اس لیے آپ کا data Vaultwarden اور bitwarden.com کے درمیان portable رہتا ہے۔

اس کے بدلے آپ کو enterprise features کا بڑا حصہ نہیں ملتا۔ SCIM provisioning دستیاب نہیں ہے، اگرچہ experimental OpenID Connect SSO، 1.35.0 میں شامل ہوا۔ آپ خود operator ہیں، اس لیے patching، HTTPS اور backups آپ کی ذمہ داری ہیں۔ یہ guide انہی تین کاموں کا احاطہ کرتی ہے۔

HTTPS کیوں اختیاری نہیں ہے

Bitwarden web vault اور browser extensions، Web Crypto API (window.crypto.subtle) استعمال کرتے ہوئے browser میں encryption keys بناتے ہیں۔ Browsers crypto.subtle کو صرف secure context، HTTPS، یا http://localhost کی خاص صورت میں ظاہر کرتے ہیں۔ سادہ http://vault.example.com پر یہ undefined ہوتا ہے، اس لیے app کے key اخذ کرتے ہی error آتا ہے، اور console میں یہ دکھائی دیتا ہے:

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

صفحہ رک جاتا ہے یا عام crypto error دکھاتا ہے، اور کوئی بھی login نہیں کر پاتا۔ Desktop، mobile اور browser clients self-hosted URL کے خلاف اپنا check چلاتے ہیں، اور http یا unreachable endpoint کے خلاف یہ error دیتے ہیں:

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

دونوں کی وجہ ایک ہی ہے: درست HTTPS موجود نہیں ہے۔ اس لیے پہلے TLS قائم کریں، اور vault کو http پر کبھی بھی نہ کھولیں، حتیٰ کہ فوری جائزے کے لیے بھی نہیں۔

مرحلہ 1، DNS اور reverse proxy (پہلے TLS)

record کو اپنے VPS کی طرف point کریں اور تصدیق کریں کہ یہ درست address پر resolve ہو رہا ہے:

dig +short vault.example.com

اس میں ظاہر ہونے والی سطر آپ کے VPS کا IP ہونی چاہیے۔ اگر یہ خالی یا غلط ہو تو DNS درست کریں اور TTL کی مدت پوری ہونے کا انتظار کریں۔ جو نام resolve نہ ہو رہا ہو، اس کے لیے certificate issuance ناکام ہو جاتی ہے۔

HTTPS front end کے لیے یہ guide Traefik استعمال کرتی ہے۔ یہ Let's Encrypt certificates خودکار طور پر issue اور renew کرتا ہے اور Compose میں براہِ راست شامل ہو جاتا ہے۔ اگر یہ پہلے سے نہیں چل رہا تو پہلے Traefik reverse proxy اور automatic TLS setup پر عمل کریں۔ یہ ایک external Docker network (proxy ذیل میں) اور ایک ACME resolver (letsencrypt) بناتا ہے، جس سے Vaultwarden service attach ہوتی ہے۔ Vaultwarden کی طرف سے plain nginx کے ساتھ manually issued certificate بھی اسی طرح کام کرتا ہے۔

Traefik کے بجائے nginx اور Certbot کو ترجیح دیتے ہیں؟ Vaultwarden کو 127.0.0.1:8080 پر رکھیں (service میں ports: ["127.0.0.1:8080:80"] شامل کریں اور Traefik labels ہٹا دیں)، پھر certificate issue کریں اور اس کی طرف proxy کریں۔ Certificate کا حصہ Certbot اور nginx کے ساتھ Let's Encrypt certificates جاری کرنا میں بیان کیا گیا ہے۔ اہم اضافی configuration 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 والی سطر پر توجہ دیں۔ اسی کی وجہ سے Fail2ban بعد میں 127.0.0.1 کے بجائے اصل attacker کا پتا لگا سکتا ہے۔ اس guide کی باقی تمام configuration یکساں رہتی ہے، چاہے سامنے Traefik ہو یا nginx۔

مرحلہ 2، Compose فائل

پہلے project directory بنائیں۔ اس guide میں /opt/vaultwarden استعمال کیا گیا ہے، جو Compose project name اور اس کے نتیجے میں data volume کا نام vaultwarden_vw-data قابلِ پیش گوئی بناتا ہے؛ نیچے دیے گئے Fail2ban اور backup مراحل اسی نام پر منحصر ہیں۔

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

اس directory میں admin secret کے لیے ایک .env اور Compose فائل بنائیں۔

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

اس token کو openssl rand -base64 48 سے generate کریں اور فائل میں paste کریں۔ (اگلے مرحلے میں زیادہ مضبوط hashed form دی گئی ہے؛ ابتدا کے لیے ایک طویل random string کافی ہے۔)

# 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

اس فائل کی 2 چیزیں پورے design کی بنیاد ہیں۔ کوئی ports: mapping نہیں ہے، اس لیے Vaultwarden تک رسائی صرف Traefik اور اس کے TLS کے ذریعے ہوتی ہے۔ Host پر اس کا port publish کرنا اس بات کا سبب بنتا ہے کہ لوگ غلطی سے vault کو http کے ذریعے serve کرنے لگیں۔ دوسری چیز، DOMAIN مکمل public HTTPS URL ہونا چاہیے۔ یہ attachment links، WebAuthn 2FA اور notifications endpoint میں شامل کیا جاتا ہے، اس لیے غلط یا http value ان چیزوں کو توڑ دیتی ہے، چاہے site load ہو جائے۔ latest tag معمول کے never-latest rule سے دانستہ exception ہے۔ Vaultwarden اپنی stable releases کو ایک single rolling image کے طور پر جاری کرتا ہے، جبکہ :testing الگ pre-release channel ہے۔ اس لیے update جان بوجھ کر کریں اور image pull کرنے سے پہلے release notes کا سرسری جائزہ لیں۔ تاہم یہ exception محدود ہے: زیادہ تر طویل مدت تک چلنے والے containers کو exact tag پر pin کرنا بہتر ہوتا ہے۔ یہی چیز اسی VPS پر ہمیشہ چلنے والے self-hosted agent کو reboots اور pulls کے دوران قابلِ پیش گوئی رکھتی ہے۔

اسے start کریں اور log monitor کریں:

docker compose up -d
docker compose logs -f vaultwarden

درست start کا اختتام Rocket has launched from http://0.0.0.0:80 جیسی line پر ہوتا ہے۔ Traefik کو certificate حاصل کرنے کے لیے چند seconds دیں، پھر https://vault.example.com کھولیں۔ آپ کو valid padlock اور certificate warning کے بغیر Bitwarden web vault نظر آنا چاہیے۔

مرحلہ 3، مضبوط `ADMIN_TOKEN` اور `$$` کا مسئلہ

ADMIN_TOKEN حفاظتی حصے /admin کی حفاظت کرتا ہے۔ یہ آپ کی instance کے ہر user اور setting کو پڑھ سکتا ہے، اس لیے اسے root password کی طرح محفوظ رکھیں۔ دو صورتیں کام کرتی ہیں۔

آسان صورت وہ random string ہے جو آپ نے پہلے ہی openssl rand -base64 48 سے بنائی ہے۔ چونکہ base64 میں کبھی $ شامل نہیں ہوتا، اس لیے اسے escaping کے بغیر براہِ راست .env میں رکھا جا سکتا ہے۔

زیادہ محفوظ صورت Argon2 PHC hash ہے۔ اس صورت میں plaintext token disk پر محفوظ نہیں ہوتا۔ اسی image کے خلاف اسے بنائیں:

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

یہ دو مرتبہ input طلب کرتا ہے اور ایسی string دکھاتا ہے جو $argon2id$v=19$... سے شروع ہوتی ہے۔ یہاں ایک اہم مسئلہ ہے جس کی وجہ سے لوگ ایک گھنٹہ ضائع کر دیتے ہیں: Docker Compose $ کو variable interpolation کے طور پر سمجھتا ہے، اس لیے hash کو Compose file میں paste کرتے وقت ہر $ کو دوہرے $$ میں تبدیل کریں۔ اسے براہِ راست environment: کے نیچے رکھیں، .env کے ذریعے نہ رکھیں، اور اسے quotes میں نہ لپیٹیں:

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

اگر آپ single $ signs برقرار رکھتے ہیں تو Compose The "argon2id" variable is not set warning دکھاتا ہے اور token کو خالی کر دیتا ہے، پھر /admin آپ کا درست password بھی مسترد کر دیتا ہے۔ docker compose up -d چلائیں، اور prompt پر درج کیا ہوا plaintext اپنی password store میں محفوظ رکھیں۔

مرحلہ 4، اپنا اکاؤنٹ رجسٹر کریں، پھر دروازہ بند کریں

SIGNUPS_ALLOWED: "true" کے ذریعے https://vault.example.com کھولیں، Create account پر کلک کریں، اور اپنے ای میل اور مضبوط master password کے ساتھ رجسٹریشن کریں۔ یہ master password کبھی recover نہیں کیا جا سکتا اور اسے reset کرنے کا کوئی طریقہ نہیں ہے، اس لیے پہلے اسے کسی محفوظ اور پائیدار جگہ پر محفوظ کریں۔

اب دروازہ بند کریں۔ Signups بند کرنے کے لیے Compose file میں ترمیم کریں:

      SIGNUPS_ALLOWED: "false"

docker compose up -d کے ذریعے دوبارہ apply کریں۔ اس hardening کو مؤخر نہیں کیا جا سکتا۔ اگر یہ کھلا رہے تو URL تلاش کرنے والا کوئی بھی شخص، اور crawlers بھی، آپ کے server پر اکاؤنٹ بنا سکتے ہیں۔ وہ آپ کا vault نہیں پڑھ سکتے، لیکن resources استعمال کرتے ہیں اور آپ کے private instance کو open service میں تبدیل کر دیتے ہیں۔ یہ معلوم کرنے کا اشارہ کہ آپ نے اسے کھلا چھوڑ دیا ہے: /admin میں ایسے اکاؤنٹس درج ہوں گے جو آپ نے نہیں بنائے۔

بعد میں family یا teammates شامل کرنے کے لیے public signups دوبارہ کھولنے کے بجائے /admin میں موجود Invite User بٹن استعمال کریں؛ اس طریقے کے لیے SMTP configured ہونا ضروری ہے تاکہ invitee کو اس کا link موصول ہو سکے۔

مرحلہ 5، /admin تک رسائی

https://vault.example.com/admin پر جائیں اور سادہ متن والا admin token درج کریں۔ یہ random string یا وہ password ہے جسے آپ نے hash کیا تھا، خود hash نہیں۔ یہاں آپ users کی فہرست دیکھ سکتے ہیں، settings ایڈجسٹ کر سکتے ہیں، test email بھیج سکتے ہیں اور database snapshot بنا سکتے ہیں۔

اگر صفحہ 404 Not Found واپس کرے تو ADMIN_TOKEN خالی یا unset ہے، جس سے panel مکمل طور پر disable ہو جاتا ہے۔ اگر آپ کو اس کی کبھی ضرورت نہیں تو یہ ایک درست انتخاب ہے۔ اگر panel load ہو لیکن token مسترد کر دے تو نیچے failure list میں $$ escaping trap دیکھیں۔ token بھول گئے ہیں؟ recovery prompt موجود نہیں ہے؛ .env یا Compose file میں ترمیم کریں، نیا token مقرر کریں، اور docker compose up -d۔

مرحلہ 6، Bitwarden کلائنٹس کو مربوط کریں

ہر official client self-hosted server سے مربوط ہو سکتا ہے۔ اس لیے Bitwarden desktop، mobile یا browser client عام stores سے install کریں۔ آپ کو کوئی خصوصی Vaultwarden build درکار نہیں۔

لاگ ان کرنے سے پہلے login screen پر settings gear کھولیں، جس پر Self-hosted یا Region → Self-hosted لکھا ہو۔ Server URL کو https://vault.example.com پر set کریں اور save کریں۔ پھر اسی email اور master password سے لاگ ان کریں جو آپ نے رجسٹر کرتے وقت فراہم کیے تھے۔ Client کو فوراً connect ہو جانا چاہیے اور credentials کو fill اور save کرنے کی سہولت دینی چاہیے۔

اگر کوئی client This is not a recognized Bitwarden server. You may need to check with your provider or update your server. دکھائے تو URL غلط ہو سکتا ہے، اس میں http استعمال ہو سکتا ہے، یا certificate قابلِ اعتماد نہیں ہو سکتا۔ پہلے browser میں تصدیق کریں کہ https://vault.example.com بغیر کسی مسئلے کے load ہوتا ہے۔ دیگر devices پر updates میں تاخیر WebSocket push سے متعلق ہے، جس کا ذکر ذیل میں کیا گیا ہے۔

Vaultwarden ہر ناکام login کو LOG_FILE سے مقرر کردہ file میں log کرتا ہے۔ یہ brute-force protection کے لیے درکار معلومات فراہم کرتا ہے۔ اگر Fail2ban پہلے سے نہیں چل رہا تو installation اور بنیادی configuration Fail2ban SSH hardening guide میں موجود ہے۔ یہاں ہم vault کے لیے ایک jail شامل کریں گے۔

پہلے معلوم کریں کہ named volume host پر کہاں موجود ہے، تاکہ Fail2ban log پڑھ سکے:

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

یہ تقریباً /var/lib/docker/volumes/vaultwarden_vw-data/_data جیسا output دکھاتا ہے؛ اس کے اندر 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 تفصیلات طے کرتی ہیں کہ یہ protection مؤثر ہوگی یا نہیں۔ پہلی بات، اگر ہر ناکام کوشش پر 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۔

دوسری بات، درست iptables chain آپ کے proxy پر منحصر ہے۔ اگر Traefik ایسے container کے طور پر چل رہا ہے جس کے ports published ہیں تو traffic Docker کے FORWARD path سے گزرتا ہے۔ اس لیے ban کو اوپر کی طرح DOCKER-USER میں ہونا چاہیے۔ لیکن اگر آپ نے Step 1 والا host-nginx option منتخب کیا ہے تو connections host کے INPUT chain پر nginx پر terminate ہوتے ہیں۔ DOCKER-USER ban انہیں نہیں دیکھتا۔ ایسی صورت میں chain = DOCKER-USER line حذف کریں، تاکہ Fail2ban default INPUT chain استعمال کرے۔

تیسری بات، port-based default کے بجائے banaction = iptables-allports استعمال کریں۔ یہ jail کوئی port مقرر نہیں کرتی، اور DOCKER-USER میں all-ports ban اس machine پر موجود ہر published service سے offender کو مؤثر طور پر روک دیتا ہے۔

مرحلہ 8، vault کا بیک اپ لیں، پھر اسے حقیقت میں بحال کریں

vw-data volume ہی آپ کا password manager ہے۔ اس میں db.sqlite3 (ہر entry)، attachments/ اور sends/ directories، login sessions پر دستخط کرنے والی rsa_key.* files، اور admin panel سے حاصل کردہ config.json شامل ہیں۔ اگر بیک اپ میں ان میں سے کوئی چیز شامل نہ ہو تو ضرورت کے وقت بیک اپ ناکام ہو جائے گا۔

Vaultwarden کے لکھنے کے دوران db.sqlite3 کو copy کرنے سے آدھی لکھی ہوئی، خراب file محفوظ ہو سکتی ہے، اس لیے cold snapshot لیں۔ downtime چند seconds کا ہوگا:

#!/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 کو server سے باہر copy کریں۔ جس server کو آپ محفوظ کر رہے ہیں، صرف اسی پر موجود بیک اپ بیک اپ نہیں ہوتا۔ اسے منتقل کرنے کا صاف طریقہ کسی دوسرے server یا object storage پر nightly restic backup ہے۔ یہ archive کو encrypt کرتا ہے اور repeated snapshots کو خود deduplicate کرتا ہے۔ admin panel کا Backup Database button صرف SQLite file کا فوری hot snapshot بناتا ہے، لیکن attachments اور keys شامل نہیں کرتا۔

اب وہ عمل کریں جو حقیقی بیک اپ کو محض امید پر مبنی بیک اپ سے الگ کرتا ہے: اسے ایک بار restore کریں اور ثابت کریں کہ یہ کام کرتا ہے:

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

اپنے laptop سے ssh -L 8888:127.0.0.1:8888 you@your-vps کے ذریعے tunnel بنائیں اور http://localhost:8888 کھولیں۔ چونکہ localhost ایک secure context ہے، اس لیے crypto.subtle دستیاب ہے اور vault یہاں plain http پر decrypt ہوتا ہے؛ صرف یہی جگہ اس کی اجازت دیتی ہے۔ اپنے master password سے log in کریں اور تصدیق کریں کہ آپ کی entries موجود ہیں۔ اگر وہ موجود ہوں تو آپ کا database، RSA keys اور master password درست طور پر restore ہو رہے ہیں، اور آپ چند minutes میں fresh VPS پر system دوبارہ بنا سکتے ہیں۔ Ctrl-C سے container روکیں اور /tmp/vw-restore delete کریں۔ server پر موجود کسی بھی دوسرے admin UI کے لیے یہی tunnel کی عادت برقرار رکھیں جسے کبھی internet کے سامنے نہیں آنا چاہیے۔ اسی طریقے سے آپ port 5173 پر self-hosted open-kritt security scanner تک بھی پہنچیں گے۔

ناکامی کی صورتیں، اور وہ strings جو آپ دیکھیں گے

Cannot read properties of undefined (reading 'importKey') browser console میں۔ Vault کو http کے ذریعے load کیا گیا، اس لیے crypto.subtle undefined ہے؛ اسے صرف https:// کے ذریعے access کریں اور proxy پر HTTP-to-HTTPS redirect شامل کریں۔

This is not a recognized Bitwarden server... client میں۔ Server URL http ہے، غلط درج کیا گیا ہے، یا certificate قابلِ اعتماد نہیں؛ تصدیق کریں کہ https://vault.example.com میں درست padlock دکھائی دے رہا ہے، پھر اسے client کی self-hosted settings میں دوبارہ درج کریں۔

/admin درست password مسترد کرتا ہے۔ Argon2 hash کی escaping ختم ہو گئی ہے، Compose میں ہر $ کو $$ ہونا چاہیے، یا آپ نے plaintext کے بجائے hash درج کر دیا ہے۔

آلات کے درمیان sync سست ہے؛ console میں WebSocket connection to 'wss://vault.example.com/notifications/hub' failed دکھائی دیتا ہے۔ Proxy Upgrade/Connection headers forward نہیں کر رہا؛ Traefik یہ خودکار طور پر کرتا ہے، جبکہ nginx میں Step 1 کی دو upgrade lines درکار ہیں۔ Vault پھر بھی کام کرتا ہے، لیکن open ہونے پر ہی sync ہوتا ہے۔ پرانا dedicated port 3012، v1.31.0 کے بعد موجود نہیں، اس لیے الگ WebSocket route درکار نہیں۔

Fail2ban ban کی اطلاع دیتا ہے، لیکن attacker مسلسل connect کرتا رہتا ہے۔ یہ 127.0.0.1 کو ban کر رہا ہے کیونکہ IP_HEADER غلط ہے، یا ban غلط iptables chain میں موجود ہے؛ chain = DOCKER-USER اور banaction = iptables-allports set کریں۔

اپ گریڈز

نئی image حاصل کریں اور container کو دوبارہ بنائیں؛ named volume اور آپ کا تمام data برقرار رہے گا:

docker compose pull
docker compose up -d

Vaultwarden کی releases کثرت سے جاری ہوتی ہیں۔ patch version کو pin کرنے کے بجائے project کی release notes monitor کریں، کیونکہ بعض releases میں migration notes شامل ہوتے ہیں۔ کسی بھی major version upgrade سے پہلے نیا backup لیں؛ tarball کو نئے volume میں restore کرکے rollback کیا جا سکتا ہے۔

FAQ

کیا Vaultwarden، Bitwarden ہی ہے؟

یہ ایک مطابقت رکھنے والا آزاد server ہے، سرکاری server نہیں۔ Vaultwarden، Bitwarden server API کو Rust میں دوبارہ نافذ کرتا ہے، اس لیے سرکاری desktop، mobile، browser اور CLI clients اس کے ساتھ کام کرتے ہیں، جبکہ سرکاری stack کے مقابلے میں بہت کم resources درکار ہوتے ہیں۔ vault format ایک ہی ہے، اس لیے آپ export اور import کے ذریعے دونوں سمتوں میں migrate کر سکتے ہیں۔

کیا مجھے واقعی HTTPS درکار ہے، یا میں اسے اپنے LAN پر http کے ذریعے چلا سکتا ہوں؟

localhost test کے علاوہ ہر صورت میں HTTPS درکار ہے۔ Bitwarden web vault اور extensions، browser کی Web Crypto API استعمال کرتے ہیں، جو صرف secure context میں دستیاب ہوتی ہے۔ اس لیے plain http پر client Cannot read properties of undefined دکھاتا ہے اور login نہیں کرتا۔ صرف http://localhost والا http address کام کرتا ہے، اسی وجہ سے Step 8 میں restore test کے لیے SSH tunnel استعمال کیا گیا ہے۔

میں اجنبی لوگوں کو اپنے server پر register کرنے سے کیسے روکوں؟

Compose file میں SIGNUPS_ALLOWED: "false" set کریں اور اپنا account بنانے کے فوراً بعد docker compose up -d چلائیں۔ اس کے بعد /admin میں Invite User button کے ذریعے نئے لوگوں کو شامل کریں۔ اس کے لیے SMTP configured ہونا چاہیے تاکہ انہیں invitation link موصول ہو۔ کبھی کبھار admin user list دیکھ کر تصدیق کریں کہ کوئی غیر متوقع account شامل نہیں ہوا۔

میں اپنے Vaultwarden vault کا backup کیسے بناؤں؟

Container کو مختصر وقت کے لیے stop کریں اور پورے vw-data volume، db.sqlite3، attachments/، sends/، config.json اور rsa_key.* files کو archive کریں۔ پھر archive کو server سے باہر copy کریں، بہتر ہے کہ یہ کام nightly cron کے ذریعے ہو۔ Server چلتے وقت live SQLite file copy کرنے سے corrupt snapshot بننے کا خطرہ ہوتا ہے، اس لیے اسے cold حالت میں copy کریں۔ سب سے اہم بات یہ ہے کہ اسے ایک بار عارضی container میں restore کر کے login کریں، تاکہ اس backup پر انحصار کرنے سے پہلے معلوم ہو جائے کہ یہ واقعی قابلِ استعمال ہے۔

کیا اپنے passwords کو self-host کرنا واقعی محفوظ ہے؟

ہاں، جب آپ اس guide میں بیان کردہ تین کام کریں: حقیقی HTTPS، بند signups کے ساتھ مضبوط admin token، اور آزمودہ backups۔ آپ کا vault client-side پر master password کے ذریعے encrypt ہوتا ہے، اس لیے server بھی آپ کے passwords کو cleartext میں نہیں دیکھتا۔ چوری شدہ db.sqlite3 اس کے بغیر بے کار ہے۔ اس کا تقاضا یہ ہے کہ patching اور backups اب آپ کی ذمہ داری ہیں، اسی لیے یہاں Fail2ban اور restore کا معمول اختیاری نہیں ہے۔ جب یہ انتظام مکمل ہو جائے تو یہ قریب سے دیکھنا مفید ہے کہ self-hosted vault پر حقیقتاً کہاں حملہ کیا جا سکتا ہے، کیونکہ entries خود client پر encrypted ہوتی ہیں، اس لیے باقی دفاع admin token اور backup archive کا کرنا ہوتا ہے۔

#vaultwarden #passwords #security #docker #self-hosting

آپ کیا بنا رہے ہیں

ضروری شرائط اور اہم عملی نکات

Vaultwarden، official Bitwarden stack کے بجائے کیوں

HTTPS کیوں اختیاری نہیں ہے

مرحلہ 1، DNS اور reverse proxy (پہلے TLS)

مرحلہ 2، Compose فائل

مرحلہ 3، مضبوط ADMIN_TOKEN اور $$ کا مسئلہ

مرحلہ 4، اپنا اکاؤنٹ رجسٹر کریں، پھر دروازہ بند کریں

مرحلہ 5، /admin تک رسائی

مرحلہ 6، Bitwarden کلائنٹس کو مربوط کریں

مرحلہ 7، login endpoint کے لیے Fail2ban jail

مرحلہ 8، vault کا بیک اپ لیں، پھر اسے حقیقت میں بحال کریں

ناکامی کی صورتیں، اور وہ strings جو آپ دیکھیں گے

اپ گریڈز

FAQ

کیا Vaultwarden، Bitwarden ہی ہے؟

کیا مجھے واقعی HTTPS درکار ہے، یا میں اسے اپنے LAN پر http کے ذریعے چلا سکتا ہوں؟

میں اجنبی لوگوں کو اپنے server پر register کرنے سے کیسے روکوں؟

میں اپنے Vaultwarden vault کا backup کیسے بناؤں؟

کیا اپنے passwords کو self-host کرنا واقعی محفوظ ہے؟

مرحلہ 3، مضبوط `ADMIN_TOKEN` اور `$$` کا مسئلہ