Vaultwarden یا Bitwarden self-hosted: VPS کے لیے کون؟

Vaultwarden اور Bitwarden self-hosted اصل میں کیا ہیں

Vaultwarden بمقابلہ Bitwarden self-hosted کا انتخاب دو ایسے servers کے درمیان ہے جو ایک ہی client API استعمال کرتے ہیں، نہ کہ دو password managers کے درمیان۔ Bitwarden کا اپنا stack nginx کے پیچھے تقریباً ایک درجن containers چلاتا ہے، تمام data Microsoft SQL Server میں محفوظ کرتا ہے، اور ایک installation ID سے منسلک ہوتا ہے جسے آپ email address کے ساتھ register کرتے ہیں۔ Vaultwarden، Bitwarden client API کی ایک غیر سرکاری reimplementation ہے جو Rust میں لکھی گئی ہے۔ یہ ایک container کے طور پر ایک SQLite file کے ساتھ چلتی ہے۔ آپ کی browser extension اور phone دونوں میں فرق محسوس نہیں کر سکتے، کیونکہ دونوں ایک ہی endpoints کا جواب دیتے ہیں۔

دونوں صورتوں میں encryption یکساں ہے۔ Bitwarden clients device سے کوئی data باہر بھیجنے سے پہلے vault کو encrypt کر دیتے ہیں۔ اس لیے server ایسے blobs محفوظ کرتا ہے جنہیں وہ پڑھ نہیں سکتا، اور دونوں صورتوں میں vault format Bitwarden ہی کا ہوتا ہے۔ فرق اس بات میں ہے کہ آپ کو کتنی machine درکار ہے، code کی دیکھ بھال کون کرتا ہے، کن features کے لیے رقم دینی پڑتی ہے، اور آپ کو کس data کا backup لینا ہوتا ہے۔

Vaultwarden README اپنی حیثیت کے بارے میں واضح ہے: "This project is not associated with Bitwarden or Bitwarden, Inc." یہ volunteers کا project ہے۔ اس کا کوئی support desk یا warranty نہیں ہے۔ ایک active maintainer Bitwarden میں کام کرتا ہے اور اپنے ذاتی وقت میں اس project میں تعاون کرتا ہے۔ یہ ایک courtesy ہے، Bitwarden کی endorsement نہیں۔

تین stacks جنہیں آپ install کر سکتے ہیں

زیادہ تر موازنوں میں یہ بات نظر انداز ہو جاتی ہے کہ Bitwarden دو مختلف self-hosted products جاری کرتا ہے۔

Bitwarden standard۔ یہ vendor deployment ہے، جسے shell script چلاتی ہے۔

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

Installer آپ سے domain، Let's Encrypt certificate request کرنے کا انتخاب، database name، اور installation ID اور key مانگتا ہے۔ یہ ID اور key آپ https://bitwarden.com/host میں email address درج کر کے حاصل کرتے ہیں۔ ./bitwarden.sh start پھر images pull کرتا ہے اور stack کو start کر دیتا ہے۔ Bitwarden کم از کم 2 GB RAM اور 12 GB storage، جبکہ تجویز کردہ طور پر 4 GB RAM اور 25 GB storage درج کرتا ہے۔ اس کے علاوہ Docker Engine 26 یا اس کے بعد کا ورژن اور Compose plugin درکار ہے۔ Database کے لیے MSSQL Express image استعمال ہوتی ہے۔ یہ edition relational database کو 10 GB تک محدود کرتی ہے، جب تک کہ deployment کو کسی external database کی طرف نہ بھیجا جائے۔

Bitwarden lite۔ یہ وہ deployment ہے جسے پہلے Bitwarden Unified کہا جاتا تھا۔ یہ beta سے نکل کر December 2025 میں نئے نام کے ساتھ جاری ہوا۔ اس میں ایک application container اور آپ کی پسند کا database شامل ہوتا ہے:

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

یہ MariaDB یا MySQL، PostgreSQL، SQLite اور MSSQL قبول کرتا ہے۔ اس کے لیے 200 MB RAM اور 1 GB storage درکار ہے۔ Bitwarden کی اپنی documentation سے دو اہم باتیں معلوم ہوتی ہیں۔ یہ business use کے بجائے personal use اور home labs کے لیے documented ہے۔ اس میں database backups خودکار طور پر نہیں لیے جاتے، اس لیے یہ کام مکمل طور پر آپ کی ذمہ داری ہے۔

Vaultwarden۔ ایک container، جو براہ راست project README سے لیا گیا ہے:

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

Publish line صرف loopback پر port 8000 bind کرتی ہے، اور یہ جان بوجھ کر ایسا کیا گیا ہے۔ Vaultwarden plain HTTP فراہم کرتا ہے اور توقع کرتا ہے کہ اس کے سامنے reverse proxy TLS (transport layer security) termination کرے گا۔ یہاں TLS اختیاری نہیں ہے۔ Web vault browser کے WebCrypto API کے ذریعے encryption کرتا ہے، اور browsers یہ API صرف secure context میں فراہم کرتے ہیں۔ اس لیے plain http پر login page browser میں fail ہو جاتا ہے، اس سے پہلے کہ server سے کوئی درخواست کی جائے۔ Vaultwarden کی مکمل installation walkthrough میں proxy اور certificate کا طریقہ بیان کیا گیا ہے۔

Bitwarden self-hosted کے ساتھ Vaultwarden کتنی RAM استعمال کرتا ہے؟

Vendor کی minimum requirements یہ بتاتی ہیں کہ installer کس کم حد سے نیچے چلنے سے انکار کرے گا، یہ نہیں بتاتیں کہ software عملاً کتنے وسائل استعمال کرتا ہے۔ ذیل کی سطریں docker stats --no-stream سے حاصل کی گئی ہیں۔ یہ پیمائشیں idle installs پر کی گئیں، جن میں فی install ایک user، چھوٹا vault اور کوئی attachments نہیں تھیں۔ ماحول Ubuntu 24.04 کا server تھا، جس میں 4 GB RAM تھی۔ Disk کا حجم images اور پہلے کامیاب start کے بعد data directory پر مشتمل ہے۔

[
  {
    "label": "Vaultwarden (SQLite)",
    "idle_ram_mb": 58,
    "containers": 1,
    "disk_gb": 0.4
  },
  {
    "label": "Bitwarden lite + MariaDB",
    "idle_ram_mb": 470,
    "containers": 2,
    "disk_gb": 1.6
  },
  {
    "label": "Bitwarden standard (MSSQL)",
    "idle_ram_mb": "2,400",
    "containers": 12,
    "disk_gb": 6.5
  }
]

Vaultwarden ایک container میں idle حالت کے دوران 58 MB RAM استعمال کر رہا تھا۔ معیاری Bitwarden stack 2,400 MB کے قریب RAM استعمال کر رہا تھا، جو 12 containers میں تقسیم تھی، اور اس کا بیشتر حصہ MSSQL container استعمال کر رہا تھا۔ Bitwarden lite، اپنے MariaDB container سمیت، 470 MB پر دونوں کے درمیان رہا۔ ان اعداد پر اعتماد کرنے سے پہلے اپنے server پر یہی command چلائیں، کیونکہ user count، attachments اور sync traffic کے ساتھ یہ اعداد بدلتے ہیں۔ اس کے علاوہ MSSQL جتنی دیر چلتا ہے، اس کا working set اتنا ہی بڑھتا ہے۔

چھوٹے VPS کے لیے عملی نتیجہ یہ ہے کہ SQLite کے ساتھ Vaultwarden، 1 GB plan پر اطمینان سے چل جاتا ہے، جبکہ معیاری Bitwarden stack وہاں start نہیں ہوگا۔ 2 GB plan پر معیاری stack documented minimum پورا کرتا ہے، لیکن operating system کے لیے بہت کم RAM بچتی ہے۔ اس لیے kernel کا out of memory killer واقعی فعال ہو سکتا ہے۔ فعال ہونے پر dmesg ایک ایسی line لکھتا ہے جس میں ختم کیے گئے process کا نام ہوتا ہے، اور اس stack میں عموماً وہ sqlservr ہوتا ہے۔ معیاری deployment کے لیے 4 GB فراہم کریں۔

Vaultwarden میں کون سی paid خصوصیات مفت ہیں؟

Bitwarden کے server کو چلانے کی کوئی لاگت نہیں، لیکن paid خصوصیات اس وقت تک بند رہتی ہیں جب تک آپ licence file upload نہ کریں۔ Premium individual accounts اور ہر paid organisation tier (Families، Teams، Enterprise) کے لیے licence درکار ہے۔ اسے cloud web vault سے download کریں۔ Individual کے لیے Settings اور پھر Subscription کھولیں، یا organisation کے لیے Admin Console میں Billing اور پھر Subscription کھولیں۔ اس کے بعد licence اپنی instance پر upload کریں۔ Organisation licences، ./bwdata/env/global.override.env میں محفوظ installation ID کی بنیاد پر جاری ہوتی ہیں۔ اس لیے self-hosted organisation کے پاس پھر بھی paid subscription رہتی ہے اور billing کے لیے Bitwarden کے cloud سے رابطہ برقرار رہتا ہے۔

Vaultwarden یہی خصوصیات کسی licence یا subscription کے بغیر فعال کر دیتا ہے۔ Project wiki میں یہ خصوصیات درج ہیں:

• organisations، collections اور groups
• file attachments
• email، Duo، YubiKey اور FIDO2 کے ذریعے two-step login
• Emergency Access
• Bitwarden Send
• personal API keys
• OpenID Connect کے ذریعے SSO

SSO ان میں سب سے نئی خصوصیت ہے اور اسے SSO_ENABLED، SSO_AUTHORITY، SSO_CLIENT_ID اور SSO_CLIENT_SECRET کے ذریعے configure کیا جاتا ہے۔ یہ صرف login کی تصدیق کرتی ہے۔ Wiki میں واضح کیا گیا ہے کہ master password پھر بھی ضروری ہے اور identity provider اسے control نہیں کرتا، کیونکہ یہی password وہ key بناتا ہے جو vault کو decrypt کرتی ہے۔ SSO_AUTHORITY کو self-hosted Authentik identity provider کے discovery issuer پر set کریں۔ صارفین وہاں sign in کریں گے، پھر اپنے master password سے vault unlock کریں گے۔ اس value کا issuer field سے match ہونا ضروری ہے جو discovery endpoint واپس کرتا ہے۔ آخر میں موجود /.well-known/openid-configuration suffix شامل نہ کریں۔

Vaultwarden میں آپ کو vendor نہیں ملتا۔ Bitwarden کے پاس SOC 2 Type 2 اور ISO 27001 certifications ہیں، یہ third-party audit reports شائع کرتا ہے اور private HackerOne bug bounty چلاتا ہے۔ یہ چیزیں Bitwarden کے code اور service پر لاگو ہوتی ہیں، آپ کے نصب کردہ server پر نہیں۔ تاہم اگر auditor آپ کے password manager کے پیچھے کسی نامزد supplier کا مطالبہ کرے تو volunteer reimplementation کی بنیاد پر یہ وضاحت کرنا مشکل ہو سکتا ہے۔

کیا سرکاری Bitwarden ایپس Vaultwarden کے ساتھ کام کرتی ہیں؟

ہاں۔ Vaultwarden کلائنٹ API نافذ کرتا ہے، اس لیے browser extensions، desktop apps، mobile apps اور bundled web vault سب اس کے ساتھ کام کرتے ہیں۔ لاگ اِن کرنے سے پہلے ہر کلائنٹ میں environment screen پر self hosted server URL درج کریں، بعد میں نہیں۔

ایک feature کے لیے اضافی configuration درکار ہے: mobile apps کو push notifications بھیجنا۔ ان کے بغیر app اس وقت sync ہوتی ہے جب آپ اسے کھولتے ہیں یا اس کے مقررہ timer پر، اس لیے آپ کے laptop پر تبدیل کیا گیا password آپ کے phone پر اس وقت تک ظاہر نہیں ہوتا جب تک آپ اسے چیک نہ کریں۔ Vaultwarden، Bitwarden کا push relay استعمال کر سکتا ہے۔ اس کے لیے اسی https://bitwarden.com/host page سے installation ID اور key درکار ہوتی ہے جسے official installer استعمال کرتا ہے۔

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

EU region کے servers کو PUSH_RELAY_URI=https://api.bitwarden.eu اور PUSH_IDENTITY_URI=https://identity.bitwarden.eu بھی درکار ہوتے ہیں۔ اس مسئلے کو debug کرنے سے پہلے wiki میں درج دو اہم نکات جان لیں۔ F-Droid یا Neo Store سے install کی گئی app میں Firebase support نہیں ہوتا، اس لیے server کچھ بھی کرے، اسے push notification کبھی موصول نہیں ہوگی۔ جو app Vaultwarden 1.30.2 سے پہلے connect ہو چکی ہو، اس کا data clear کرنا ضروری ہے تاکہ وہ push token register کر سکے۔

دوبارہ تیار کردہ implementation کتنی محفوظ ہے؟

Bitwarden کی audit history طویل اور عوامی ہے۔ Cure53 نے 2018، 2021، 2022 اور 2023 میں اس کا جائزہ لیا۔ IOActive اور Mandiant نے 2024 میں clients کا جائزہ لیا، Fracture Labs نے 2024 اور 2025 کے دوران web اور network assessments کیے، Unit 42 نے 2025 میں mobile apps کا جائزہ لیا، اور ETH Zurich Applied Cryptography Group نے 2025 میں cryptography کا جائزہ لیا۔

Vaultwarden کا بھی بیرونی ماہرین نے جائزہ لیا ہے، حالانکہ بعض لوگ یہ فرض کرتے ہیں کہ کوئی اس کا جائزہ نہیں لیتا۔ Germany's Federal Office for Information Security (BSI) نے Caos 3.0 code analysis project کے تحت February سے May 2024 کے درمیان mgm security partners سے اس کی testing کرائی، اور اس جائزے میں دو findings کو high severity دی گئی۔ الگ طور پر، ERNW نے 1.32.5 سے کم versions کو متاثر کرنے والا authentication bypass رپورٹ کیا (CVE-2024-55225)، جسے November 2024 میں ٹھیک کیا گیا۔ July 2026 میں Version 1.37.0 نے icon endpoint کے ذریعے SSRF (server side request forgery)، cross organisation cipher access، اور directory imports میں organisation policy bypass کے لیے fixes جاری کیے۔

یہ history ایسے project کی نشاندہی کرتی ہے جس میں vulnerability disclosure process کام کر رہا ہے۔ یہ اس attack surface کی طرف بھی اشارہ کرتی ہے جو بار بار سامنے آتا ہے: admin page۔ اس لیے اس page کو اتنا ہی حساس سمجھیں جتنا یہ حقیقتاً ہے۔ یہ ADMIN_TOKEN کے set ہونے تک بند رہتا ہے، اور آپ کو plaintext token کے بجائے hash محفوظ کرنا چاہیے۔

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

یہ ایک Argon2 PHC string (password hashing competition format) دکھاتا ہے، جسے ADMIN_TOKEN میں paste کریں۔ admin page کو enable کرنے سے پہلے HTTPS enable کریں، کیونکہ token request میں بھیجا جاتا ہے، اور plain HTTP connection پر plaintext token کو راستے میں موجود کوئی بھی فریق پڑھ سکتا ہے۔ جہاں ممکن ہو /admin کو public internet سے دور رکھیں، اور اسے host hardening کے معمول کے اقدامات کے ساتھ استعمال کریں، مثلاً server پر SSH access محدود کرنا۔

سرکاری API میں تبدیلی سے کیا متاثر ہوتا ہے

یہ وہ خطرہ ہے جسے لوگ کم اہم سمجھتے ہیں۔ Bitwarden کلائنٹس جاری کرتا ہے، اور یہ کلائنٹس راتوں رات app stores سے خود کو update کر لیتے ہیں۔ Vaultwarden کو ان تبدیلیوں کے ساتھ چلنا پڑتا ہے۔ جب کسی کلائنٹ کی release API contract تبدیل کرتی ہے تو update نہ کیا گیا Vaultwarden ایسے کلائنٹ سے دوچار ہوتا ہے جو پہلے ہی نئی API پر منتقل ہو چکا ہے۔ اس کے نتیجے میں ان devices پر login یا sync ناکام ہونا شروع ہو سکتا ہے جنہیں آپ نے خود تبدیل نہیں کیا۔

Release notes میں اس کی واضح مثال موجود ہے۔ Vaultwarden 1.37.0 میں لکھا ہے: "This update is required for support with clients with version 2026.7.0+, please update before reporting any issues with them." August 2026 تک موجودہ release 1.37.1 ہے، جو 29 July 2026 کو شائع ہوئی تھی۔

دو عادتیں اس مسئلے کو معمولی رکھتی ہیں۔ latest کے بجائے مخصوص image tag مقرر کریں، تاکہ unattended pull رات 3 بجے آپ کے server کو خود بخود نئی version پر منتقل نہ کر سکے۔ پھر release feed کو monitor کریں اور سوچ سمجھ کر upgrade کریں۔ پہلے notes پڑھیں، کیونکہ breaking changes وہیں درج ہوتی ہیں اور کہیں اور نہیں۔ مثال کے طور پر version 1.35.5 کے upgrade نے تمام موجودہ two-factor remember tokens کو invalid کر دیا، جس سے لوگوں کا login ختم ہو گیا، حالانکہ وہ سمجھتے تھے کہ انہوں نے یہ مرحلہ محفوظ کر لیا ہے۔

معیاری Bitwarden deployment میں اس مسئلے کی الٹ صورت موجود ہے۔ Upgrades ./bitwarden.sh updateself اور ./bitwarden.sh update کے ذریعے چلتے ہیں، اور update database migrations لاگو کرتی ہے۔ Migration سے پہلے لیا گیا backup اس کے بعد کے schema کے لیے rollback نہیں ہوتا۔ اس لیے backup لیں اور اس version کو بھی درج کریں جس پر یہ backup لیا گیا تھا۔

بیک اپ، جہاں لوگ حقیقت میں vaults کھو دیتے ہیں

Vaultwarden کی data directory ہی سرور کا بنیادی ڈیٹا ہے۔ یہ چیزیں محفوظ رکھیں:

• db.sqlite3
• ہر rsa_key* فائل، بشمول rsa_key.pem اور rsa_key.der
• attachments/
• config.json
• sends/

Container چلتے ہوئے db.sqlite3 کو cp کے ساتھ copy نہ کریں۔ SQLite اس وقت write کر رہا ہو سکتا ہے، اس لیے copy شدہ database خراب ہو سکتا ہے، اگرچہ restore کرنے تک بظاہر درست نظر آئے۔ اس کے بجائے online backup API استعمال کریں:

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

1.32.1 کے بعد image میں built-in /vaultwarden backup command بھی موجود ہے۔ دونوں صورتوں میں snapshot منتقل کیے جانے تک اسی disk پر رہتا ہے جس پر اصل data موجود ہے۔ اس لیے مقررہ schedule کے مطابق restic snapshots کو off-site storage پر بھیجیں۔ rsa_key فائلیں بھی database جتنی اہم ہیں۔ سرور اپنے session tokens پر اسی key سے دستخط کرتا ہے۔ اس لیے freshly generated key کے ساتھ database restore کرنے سے تمام users log out ہو جاتے ہیں اور زیرِ تکمیل organisation invitations ناکام ہو جاتی ہیں۔

Bitwarden standard اپنے زیادہ اجزا کا بیک اپ لیتا ہے۔ mssql container رات کے وقت database backups کو ./bwdata/mssql/backups میں لکھتا ہے اور ان میں سے 30 دن کے backups محفوظ رکھتا ہے، بشرطیکہ container چل رہا ہو۔ آپ backup زبردستی بھی بنا سکتے ہیں:

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

محفوظ رکھنے والی directories ./bwdata/env (environment variables، جن میں database اور certificate passwords شامل ہیں)، ./bwdata/core/attachments، ./bwdata/mssql/data، اور ./bwdata/core/aspnet-dataprotection ہیں۔ آخری directory اکثر بھول جاتی ہے۔ اس میں framework-level data protection material، بشمول authentication tokens اور database کے بعض columns، موجود ہوتا ہے۔ اس کے بغیر database restore کرنے سے وہ columns ناقابلِ مطالعہ رہ جاتے ہیں جن پر یہ protection لاگو تھی۔ Bitwarden lite خودکار backups بالکل نہیں لیتا۔ اس لیے lite منتخب کرنے کا مطلب ہے کہ dump schedule کی ذمہ داری آپ کی ہے، بالکل Vaultwarden کی طرح۔

دونوں سمتوں میں منتقلی

منتقلی servers کے بجائے clients کے ذریعے ہوتی ہے، کیونکہ export اور import client features ہیں۔ اسی لیے دونوں سمتوں میں طریقۂ کار یکساں رہتا ہے۔

ہر user web vault یا desktop app سے export بناتا ہے، نئے server پر account بناتا ہے، اور پھر import کرتا ہے۔ formats plaintext .json، plaintext .csv، encrypted .json، اور .zip ہیں، جس میں انفرادی vaults کے لیے JSON اور file attachments شامل ہوتے ہیں۔ Cards، identities، stored passkeys اور SSH keys صرف JSON forms میں محفوظ رہتے ہیں، اس لیے CSV migration انہیں خاموشی سے خارج کر دیتی ہے۔ کسی بھی export format میں trash items یا Sends شامل نہیں ہوتے، اور organisation کی ملکیت والا data انفرادی export کا حصہ نہیں ہوتا۔

plaintext export کو live secret سمجھیں، کیونکہ حقیقت میں یہ آپ کا مکمل vault disk پر clear text میں ہوتا ہے۔ اسے export کریں، import کریں، اور اسی نشست میں delete کر دیں۔ اسے کبھی email یا chat کے ذریعے نہ بھیجیں۔

منتقلی کے دوران ایک مسئلہ اکثر سامنے آتا ہے۔ آپ کے account سے وابستہ encrypted export کسی دوسرے account میں import نہیں کیا جا سکتا، اور server منتقل کرنے کا مطلب لازماً ایک مختلف account ہوتا ہے۔ اس کے بجائے password protected export option منتخب کریں، کیونکہ اسے منتقل کیا جا سکتا ہے۔

Vaultwarden سے Bitwarden standard کی سمت منتقلی زیادہ مشکل ہے، کیونکہ organisation structure export میں منتقل نہیں ہوتی۔ نئے server پر organisation دوبارہ بنائیں، users کو دوبارہ invite کریں، اور ہر user اپنا vault خود import کرے۔ اس کے لیے maintenance window پہلے سے مقرر کریں، تاکہ یہ مسئلہ منتقلی کے دن سامنے نہ آئے۔

کون سا چلانا چاہیے؟

اگر آپ اکیلے صارف، خاندان، یا 1 GB یا 2 GB VPS پر home lab چلا رہے ہیں تو Vaultwarden چلائیں۔ Organisations، Emergency Access اور Send مفت دستیاب ہیں، idle memory کا استعمال تقریباً ایک browser tab جتنا ہے، اور backup ایک SQLite فائل اور ایک چھوٹی directory پر مشتمل ہوتا ہے۔ یہی امتزاج اسے self-hosted password management کے لیے سب سے زیادہ مقبول بناتا ہے۔

جب دوسرے لوگ پیشہ ورانہ طور پر اس پر انحصار کرتے ہوں تو Bitwarden کا اپنا server چلائیں۔ مثال کے طور پر ایسی company جسے support contract درکار ہو، ایسی compliance requirement جس میں vendor کا نام لازمی ہو، یا وہ enterprise features جن کے لیے آپ پہلے ہی ادائیگی کر رہے ہوں۔ Standard deployment کو 4 GB memory دیں، اور licence file اور installation ID کو محض paperwork کے بجائے deployment کا حصہ سمجھیں۔

Bitwarden lite ایک غیر واضح درمیانی انتخاب ہے۔ یہ vendor کا code ہے اور اصل Bitwarden کے مقابلے میں بہت کم وسائل استعمال کرتا ہے، جو واقعی پرکشش ہے، لیکن Bitwarden اسے personal اور home lab استعمال کے لیے document کرتا ہے اور اس میں automatic backups نہیں ہیں۔ آپ کو Vaultwarden کا operational load اٹھانا پڑتا ہے، مگر Vaultwarden کا مفت feature set نہیں ملتا۔ اسے اس وقت منتخب کریں جب vendor code آپ کے لیے features سے زیادہ اہم ہو اور آپ database خود چلانے پر آمادہ ہوں۔

اگر آپ ابھی یہ فیصلہ کر رہے ہیں کہ box پر مزید کیا host کیا جائے، تو self-hosting کے وسیع تر مختصر انتخاب میں یہ فیصلہ ان دیگر services کے ساتھ دکھایا گیا ہے جو اسی RAM کے لیے مقابلہ کر رہی ہیں۔

FAQ

کیا Vaultwarden حقیقی password manager کے لیے کافی محفوظ ہے؟

ذاتی اور خاندانی استعمال کے لیے ہاں، مگر کچھ شرائط کے ساتھ۔ Clients، vault کو server تک پہنچنے سے پہلے encrypt کر دیتے ہیں، اس لیے Vaultwarden کو آپ کا master password یا کوئی plaintext معلوم نہیں ہوتا۔ اس کا بیرونی جائزہ بھی لیا جا چکا ہے: BSI نے mgm security partners سے February اور May 2024 کے درمیان اس کی testing کرائی، اور ERNW نے authentication bypass کی نشاندہی کی جسے 1.32.5 میں fix کر دیا گیا۔ Version کو current رکھیں، admin page کو disabled رکھیں یا Argon2 hashed ADMIN_TOKEN کے پیچھے رکھیں، اور اسے صرف HTTPS کے ذریعے serve کریں۔ جس business کو vendor support یا audit documentation درکار ہو، اسے Bitwarden کا اپنا server چلانا چاہیے۔

Bitwarden self-hosted کے مقابلے میں Vaultwarden کو کتنی RAM درکار ہوتی ہے؟

docker stats --no-stream سے ناپی گئی idle installations میں SQLite کے ساتھ Vaultwarden ایک container میں تقریباً 58 MB استعمال کر رہا تھا، جبکہ Bitwarden کی standard deployment تقریباً 2,400 MB استعمال کر رہی تھی، جو 12 containers میں پھیلی ہوئی تھی۔ اس کا زیادہ تر حصہ MSSQL database استعمال کر رہا تھا۔ Bitwarden standard stack کے لیے 2 GB کو minimum اور 4 GB کو recommended قرار دیتا ہے، جبکہ Bitwarden lite کے لیے 200 MB درج ہے۔ Vaultwarden 1 GB VPS پر بھی کافی اضافی گنجائش کے ساتھ چلتا ہے۔

کیا self-host کرنے کے لیے Bitwarden licence درکار ہے؟

مفت individual vault کے لیے نہیں۔ Server چلانا مفت ہے۔ Premium individual features اور کسی بھی paid organisation plan کو unlock کرنے کے لیے licence file درکار ہوتی ہے۔ اس میں Families، Teams اور Enterprise شامل ہیں۔ اسے cloud web vault سے download کر کے اپنی instance پر upload کریں۔ Organisation licences، ./bwdata/env/global.override.env میں محفوظ installation ID کے خلاف جاری کی جاتی ہیں۔ Vaultwarden کو کسی licence کی ضرورت نہیں ہوتی اور یہ organisation features خود فعال کر دیتا ہے۔

کیا میں بعد میں Vaultwarden سے Bitwarden، یا واپس Bitwarden سے Vaultwarden پر منتقل ہو سکتا ہوں؟

ہاں، دونوں سمتوں میں clients کے ذریعے منتقلی ممکن ہے۔ ہر user web vault یا desktop app سے اپنا vault export کرتا ہے، پھر نئی server پر account بنانے کے بعد اسے import کر دیتا ہے۔ .zip export میں individual vaults کے attachments شامل ہوتے ہیں، جبکہ JSON forms میں cards، identities، passkeys اور SSH keys شامل ہوتے ہیں۔ Trash items اور Sends کسی بھی export format میں شامل نہیں ہوتے۔ Organisation-owned items کو owner کو الگ export کرنا ہوتا ہے۔ اس لیے نئی server پر organisation دوبارہ بنائیں اور users کو دوبارہ invite کرنے کا منصوبہ بنائیں۔