Vaultwarden على VPS: استضف كلمات مرورك

ما الذي تبنيه

مدير كلمات مرور تملكه أنت بالكامل: Vaultwarden يعمل في حاوية واحدة صغيرة خلف بروكسي عكسي (reverse proxy) ينهي اتصال HTTPS، مع تطبيقات Bitwarden الرسمية على هاتفك وحاسوبك المحمول ومتصفحك، كلها موجَّهة إليه. يعيد Vaultwarden تنفيذ واجهة برمجة تطبيقات خادم Bitwarden بلغة Rust، ويستخدم البروتوكول نفسه الذي يستخدمه bitwarden.com، فكل عميل رسمي يعمل معه دون أي تعديل — لكنه يكتفي بنحو 100 ميغابايت من ذاكرة RAM بدلًا من الحزمة الرسمية متعددة الحاويات.

التثبيت نفسه لا يتجاوز اثنَي عشر سطرًا من Compose. الأشياء الثلاثة التي تهم فعلًا — والتي تتعطل إن أُهملت — هي هذه: يجب أن يكون TLS قائمًا قبل أن تفتح الخزنة (vault) على الويب ولو مرة واحدة، ويجب إغلاق التسجيل العام لحظة إنشاء حسابك الخاص، ويجب أخذ نسخة احتياطية من مجلد البيانات واختبار استعادتها فعليًا، لأن هذا المجلد وحده يحتوي على كل كلمة مرور تملكها.

المتطلبات المسبقة والمزالق التي يجب معرفتها

• خادم VPS يعمل بمحرك Docker وإضافة Compose، على جهاز KVM بنظام Ubuntu 24.04 حديث التثبيت مع صلاحيات root أو sudo. يكفي فعلًا 512 ميغابايت من ذاكرة RAM؛ وغيغابايت واحد مريح. هذا من أخف الأشياء التي يمكنك تشغيلها — إذ يحتل مكانًا قريبًا من قمة قائمة الخدمات التي تستحق الاستضافة الذاتية.
• نطاق (domain) بسجل A (وسجل AAAA إن كان لديك IPv6) يوجّه vault.example.com إلى الخادم. شهادة TLS تُصدَر لهذا الاسم بالتحديد، فيجب أن يُحل DNS قبل أن تبدأ.
• المنفذان 80 و443 مفتوحان على الإنترنت، تنتهي عندهما اتصالات TLS عبر البروكسي العكسي الخاص بك — أبدًا عبر Vaultwarden مباشرة. المنفذ 80 يُستخدم فقط لتحدي شهادة ACME ولإعادة التوجيه من HTTP إلى HTTPS.
• أكبر مزلق منذ البداية: عملاء Bitwarden يرفضون الاتصال بخادم لا يعمل بـ HTTPS. لا وجود لخيار «جرّبه أولًا عبر http» — هذا المسار لا يعمل، لسبب محدد نشرحه بعد قليل.

لماذا Vaultwarden وليس حزمة Bitwarden الرسمية؟

العملاء أنفسهم، لكن بجزء يسير من الوزن. نسخة Bitwarden الرسمية للاستضافة الذاتية تُوزَّع كحزمة من الحاويات (MSSQL وNginx وIdentity وApi وAdmin وأكثر) وتطلب نحو 2 غيغابايت من ذاكرة RAM. أما Vaultwarden فهو ملف تنفيذي واحد يخزّن كل شيء في قاعدة بيانات SQLite افتراضيًا، ويستقر عند خمول في بضع عشرات من الميغابايتات. لشخص واحد أو عائلة أو فريق صغير، هو الخيار البديهي، ولأنه يطبّق واجهة برمجة تطبيقات Bitwarden بأمانة، تبقى بياناتك قابلة للنقل بينه وبين bitwarden.com.

ما تتنازل عنه هو معظم مساحة الاستخدام المؤسسي: لا يوجد توفير حسابات عبر SCIM (رغم أن دعم تسجيل الدخول الموحد التجريبي عبر OpenID Connect وصل في الإصدار 1.35.0)، وأنت المشغِّل، فتصحيح الثغرات وHTTPS والنسخ الاحتياطية مهمتك أنت. هذا الدليل هو تلك المهام الثلاث.

لماذا HTTPS ليس اختياريًا

خزنة Bitwarden على الويب وإضافات المتصفح تشتق مفاتيح التشفير الخاصة بك داخل المتصفح باستخدام واجهة Web Crypto (window.crypto.subtle). لا تكشف المتصفحات crypto.subtle إلا في سياق آمن (secure context) — أي عبر HTTPS، أو في الحالة الخاصة لـ http://localhost. أما عبر http://vault.example.com العادي فقيمتها undefined، فبمجرد أن يحاول التطبيق اشتقاق مفتاح يرمي خطأً، وتُظهر وحدة التحكم (console) ما يلي:

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

الصفحة تتجمد أو تعرض خطأ تشفير عامًا، ولا يتم تسجيل الدخول إطلاقًا. عملاء سطح المكتب والموبايل والمتصفح يجرون فحصهم الخاص مقابل رابط الخادم المستضاف ذاتيًا، وأمام نقطة نهاية تعمل بـ 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 والبروكسي العكسي (TLS أولًا)

وجّه السجل إلى خادمك وتأكد من أنه يُحل إلى العنوان الصحيح:

dig +short vault.example.com

السطر الذي يطبعه يجب أن يكون عنوان IP الخاص بخادمك. إن كان فارغًا أو خاطئًا، فأصلح DNS وانتظر انقضاء مدة TTL — فإصدار الشهادة يفشل أمام اسم لا يُحل.

لواجهة HTTPS، يستخدم هذا الدليل Traefik، الذي يصدر شهادات Let's Encrypt ويجدّدها تلقائيًا ويندمج مباشرة مع Compose. إن لم تكن تشغّله بالفعل، فاتبع أولًا إعداد بروكسي Traefik العكسي وTLS التلقائي؛ فهو ينشئ شبكة Docker خارجية (proxy أدناه) ومحلِّل ACME (letsencrypt) تتصل بهما خدمة Vaultwarden. ويعمل nginx العادي بشهادة صادرة يدويًا بالطريقة نفسها تمامًا من جهة Vaultwarden.

تفضّل nginx وCertbot بدلًا من Traefik؟ ضع Vaultwarden على 127.0.0.1:8080 (أضف ports: ["127.0.0.1:8080:80"] إلى الخدمة واحذف تسميات (labels) Traefik)، ثم أصدر شهادة ووجّه البروكسي إليه. جزء الشهادة مشروح في إصدار شهادات Let's Encrypt بواسطة Certbot وnginx. الإضافة الحاسمة هنا هي ترقية WebSocket على مسار الإشعارات:

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. كل شيء آخر في هذا الدليل متطابق سواء كانت الواجهة Traefik أو nginx.

الخطوة 2 — ملف Compose

أنشئ مجلد المشروع أولًا. يستخدم هذا الدليل /opt/vaultwarden، وهذا يجعل اسم مشروع Compose — وبالتالي وحدة تخزين البيانات، vaultwarden_vw-data — قابلًا للتنبؤ؛ وخطوتا Fail2ban والنسخ الاحتياطي أدناه تعتمدان على هذا الاسم بالتحديد.

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

أنشئ ملف .env لسرّ الإدارة وملف Compose في المجلد نفسه.

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

ولّد ذلك الرمز (token) بالأمر openssl rand -base64 48 والصقه هناك. (الشكل الأقوى المُجزَّأ (hashed) مشروح بعد قليل؛ سلسلة عشوائية طويلة تكفي للبداية.)

# 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 العام الكامل: فهو مغروس في روابط المرفقات، وفي المصادقة الثنائية عبر WebAuthn، وفي نقطة نهاية الإشعارات، فقيمة خاطئة أو عبر http تكسر هذه الوظائف حتى حين يُحمَّل الموقع نفسه بنجاح. أما تسمية latest فهي استثناء متعمَّد من قاعدة تجنّب latest المعتادة: فـ Vaultwarden يُصدر إصداراته المستقرة كصورة واحدة متجددة، مع :testing كقناة منفصلة للإصدارات التجريبية — لذا حدّث بقرار واعٍ، واطّلع على ملاحظات الإصدار قبل أن تسحب الصورة الجديدة.

شغّله وراقب السجل:

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 دون أي حاجة إلى إفلات (escaping).

الشكل المعزَّز هو تجزئة Argon2 بصيغة PHC، بحيث لا يُخزَّن الرمز الصريح على القرص إطلاقًا. ولّد واحدة من الصورة نفسها:

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

يطلب الإدخال مرتين ثم يطبع سلسلة تبدأ بـ $argon2id$v=19$.... وها هو الفخّ الذي يكلّف الناس ساعة كاملة من وقتهم: يعامل Docker Compose علامة $ بوصفها استيفاءً لمتغيّر (variable interpolation)، فيجب عليك مضاعفة كل علامة $ إلى $$ عند لصق التجزئة في ملف Compose. ضعها مباشرة تحت environment:، لا عبر .env، ولا تضعها بين علامتي اقتباس:

    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، وسجّل ببريدك الإلكتروني وكلمة مرور رئيسية (master password) قوية. كلمة المرور الرئيسية هذه لا يمكن استعادتها أبدًا — لا وجود لإعادة تعيين — فخزّنها في مكان دائم أولًا.

والآن أغلق الباب. عدّل ملف Compose لإيقاف التسجيل:

      SIGNUPS_ALLOWED: "false"

أعد التطبيق بالأمر docker compose up -d. هذا ليس تحصينًا يمكنك تأجيله. فإن تُرك مفتوحًا، يستطيع أي شخص يعثر على الرابط — والزواحف الآلية (crawlers) تعثر عليه فعلًا — إنشاء حساب على خادمك. لا يستطيعون قراءة خزنتك أنت، لكنهم يستهلكون الموارد ويحوّلون نسختك الخاصة إلى خدمة عامة مفتوحة. العلامة الدالة على أنك تركته مفعّلًا: /admin يسرد حسابات لم تُنشئها أنت قط.

لإضافة أفراد العائلة أو الزملاء لاحقًا دون إعادة فتح التسجيل العام، استخدم زر Invite User في /admin؛ وهذا المسار يحتاج إلى إعداد SMTP حتى يستلم المدعو رابطه.

الخطوة 5 — الوصول إلى /admin

تصفّح https://vault.example.com/admin وأدخل رمز الإدارة الصريح (السلسلة العشوائية، أو كلمة المرور التي جزّأتها — لا التجزئة نفسها). بداخلها يمكنك سرد المستخدمين، وضبط الإعدادات، وإرسال بريد اختباري، وأخذ لقطة (snapshot) من قاعدة البيانات.

إن أعادت الصفحة 404 Not Found، فإن ADMIN_TOKEN فارغ أو غير معرَّف، وهذا يعطّل اللوحة بالكامل — وهو خيار صالح بحد ذاته إن لم تكن تحتاج إليها إطلاقًا. وإن حُمِّلت الصفحة لكنها ترفض رمزك، فراجع فخّ إفلات علامتي $$ في قائمة أنماط الفشل أدناه. نسيت الرمز؟ لا وجود لأي وسيلة لاسترداد الرمز؛ عدّل .env أو ملف Compose، وضع رمزًا جديدًا، ثم نفّذ docker compose up -d.

الخطوة 6 — وصّل عملاء Bitwarden

كل عميل رسمي يمكنه التوجه إلى خادم مستضاف ذاتيًا، فثبّت عميل Bitwarden لسطح المكتب أو الموبايل أو المتصفح من المتاجر المعتادة — أنت لست بحاجة إلى نسخة خاصة لـ Vaultwarden.

قبل تسجيل الدخول، افتح ترس الإعدادات في شاشة الدخول (المُسمّى Self-hosted أو Region → Self-hosted)، واضبط Server URL على https://vault.example.com، واحفظ. ثم سجّل الدخول بالبريد الإلكتروني وكلمة المرور الرئيسية اللذين سجّلتهما؛ يجب أن يتصل العميل فورًا ويعرض تعبئة بيانات الاعتماد وحفظها.

إن أظهر عميل ما الرسالة This is not a recognized Bitwarden server. You may need to check with your provider or update your server.، فإن الرابط خاطئ، أو يستخدم http، أو أن الشهادة غير موثوقة — تحقق أولًا من أن https://vault.example.com يُحمَّل بسلامة في متصفح عادي. أما التحديثات البطيئة على الأجهزة الأخرى فمصدرها دفع WebSocket، ونشرحه أدناه.

الخطوة 7 — سجن Fail2ban لنقطة الدخول

يسجّل Vaultwarden كل محاولة دخول فاشلة في الملف الذي يحدده LOG_FILE — وهذا بالضبط ما يحتاجه حارس ضد القوة الغاشمة (brute-force). إن لم تكن تشغّل Fail2ban بالفعل، فالتثبيت والأساسيات موجودة في دليل تحصين SSH بواسطة Fail2ban؛ هنا نضيف سجنًا واحدًا للخزنة.

اعثر أولًا على مكان وحدة التخزين المسمّاة على المضيف، ليتمكن Fail2ban من قراءة السجل:

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

يطبع ذلك شيئًا شبيهًا بـ /var/lib/docker/volumes/vaultwarden_vw-data/_data؛ والسجل هو 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 وتأكد بالأمر sudo fail2ban-client status vaultwarden.

ثلاثة تفاصيل خاصة بـ Docker تحدد ما إذا كان هذا يحمي أي شيء فعلًا. أولًا، إن أظهر السجل IP: 127.0.0.1 أو عنوان البروكسي الخاص بك في كل محاولة فاشلة، فإن Vaultwarden يحظر البروكسي نفسه — اضبط IP_HEADER على الترويسة (header) التي يرسلها بروكسيك فعلًا (X-Forwarded-For لـ Traefik، وX-Real-IP لكتلة nginx أعلاه، وCF-Connecting-IP خلف Cloudflare). ثانيًا، سلسلة iptables الصحيحة تعتمد على بروكسيك: مع Traefik يعمل كحاوية بمنافذ منشورة، تمر حركة المرور عبر مسار FORWARD في Docker، فيجب أن يقع الحظر في DOCKER-USER كما أعلاه؛ لكن إن اخترت خيار nginx على المضيف من الخطوة 1، فالاتصالات تنتهي عند nginx في سلسلة INPUT الخاصة بالمضيف، ولن يراها حظر DOCKER-USER أبدًا — في هذه الحالة احذف سطر chain = DOCKER-USER ليستخدم Fail2ban سلسلة INPUT الافتراضية. ثالثًا، استخدم banaction = iptables-allports بدلًا من القيمة الافتراضية القائمة على المنفذ — فهذا السجن لا يحدد أي منفذ، وحظر كل المنافذ في DOCKER-USER يمنع المخالف تمامًا من كل خدمة منشورة على الجهاز.

الخطوة 8 — خذ نسخة احتياطية من الخزنة، ثم استعدها فعليًا

وحدة التخزين vw-data هي مدير كلمات مرورك. تضمّ db.sqlite3 (كل إدخال)، ومجلدَي attachments/ وsends/، وملفات rsa_key.* التي توقّع جلسات الدخول، وملف config.json من لوحة الإدارة. أي نسخة احتياطية تتجاوز أيًّا من هذه العناصر تفشل عندما تحتاج إليها فعلًا.

نسخ db.sqlite3 بينما يكتب Vaultwarden فيه قد يلتقط ملفًا نصف مكتوب وتالفًا، فخذ لقطة باردة (cold snapshot) — مدة التوقف بضع ثوانٍ فقط:

#!/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 خارج الجهاز — فنسخة احتياطية لا توجد إلا على الخادم الذي تحميه ليست نسخة احتياطية. الطريقة النظيفة لنقلها هي نسخة restic احتياطية ليلية إلى خادم آخر أو تخزين كائنات (object storage)، التي تشفّر الأرشيف وتزيل تكرار اللقطات المتعاقبة نيابة عنك. زر 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

من حاسوبك المحمول، افتح نفقًا (tunnel) إليه بالأمر ssh -L 8888:127.0.0.1:8888 you@your-vps وافتح http://localhost:8888. ولأن localhost سياق آمن، تكون crypto.subtle متاحة، وتُفكّ تشفير الخزنة هنا عبر http عادي — المكان الوحيد المسموح فيه بذلك. سجّل الدخول بكلمة مرورك الرئيسية وتأكد من وجود إدخالاتك: إن كانت موجودة، فقاعدة بياناتك ومفاتيح RSA وكلمة مرورك الرئيسية كلها تنجو من رحلة النسخ والاستعادة سليمة، ويمكنك إعادة البناء على خادم VPS جديد في دقائق. أوقف الحاوية بـ Ctrl-C واحذف /tmp/vw-restore.

أنماط الفشل، مع النصوص التي ستراها

Cannot read properties of undefined (reading 'importKey') في وحدة تحكم المتصفح. الخزنة حُمِّلت عبر http، فـ crypto.subtle غير معرَّفة؛ صِلها فقط عبر https:// وأضف إعادة التوجيه من HTTP إلى HTTPS عند البروكسي.

This is not a recognized Bitwarden server... في أحد العملاء. رابط الخادم عبر http، أو مكتوب خطأً، أو الشهادة غير موثوقة؛ تأكد من أن https://vault.example.com يُظهر قفلًا صالحًا، ثم أعد إدخاله في إعدادات الاستضافة الذاتية للعميل.

/admin يرفض كلمة المرور الصحيحة. تجزئة Argon2 فقدت إفلاتها — كل علامة $ يجب أن تصبح $$ في Compose — أو أنك أدخلت التجزئة نفسها بدلًا من النص الصريح الذي تمثله.

مزامنة بطيئة بين الأجهزة؛ وتُظهر وحدة التحكم WebSocket connection to 'wss://vault.example.com/notifications/hub' failed. البروكسي لا يمرّر ترويستَي Upgrade/Connection؛ Traefik يفعل ذلك تلقائيًا، بينما يحتاج nginx إلى سطري الترقية من الخطوة 1. الخزنة لا تزال تعمل، لكنها تتزامن فقط عند الفتح. المنفذ 3012 المخصص القديم اختفى منذ الإصدار v1.31.0، فلا حاجة إلى مسار WebSocket منفصل.

Fail2ban يبلّغ عن حظر لكن المهاجم يواصل الاتصال. إنه يحظر 127.0.0.1 لأن IP_HEADER خاطئ، أو أن الحظر يقع في سلسلة iptables الخاطئة — اضبط chain = DOCKER-USER وbanaction = iptables-allports.

التحديثات

اسحب الصورة الجديدة وأعد الإنشاء؛ وحدة التخزين المسمّاة وكل بياناتك تبقى كما هي:

docker compose pull
docker compose up -d

يُصدر Vaultwarden إصدارات متكررة. راقب ملاحظات إصدار المشروع بدلًا من تثبيت رقم إصدار محدد، لأن بعض الإصدارات تتضمن ملاحظات ترحيل. خذ نسخة احتياطية جديدة قبل أي قفزة إصدار كبيرة؛ ويمكنك التراجع باستعادة الأرشيف في وحدة تخزين جديدة.

FAQ

هل Vaultwarden هو نفسه Bitwarden؟

هو خادم متوافق ومستقل، لا الخادم الرسمي. يعيد Vaultwarden تنفيذ واجهة برمجة تطبيقات خادم Bitwarden بلغة Rust، فتعمل معه عملاء سطح المكتب والموبايل والمتصفح وسطر الأوامر الرسمية كلها، بجزء يسير من موارد الحزمة الرسمية. صيغة الخزنة نفسها، فيمكنك الانتقال في أي اتجاه بالتصدير والاستيراد.

هل أحتاج حقًا إلى HTTPS، أم يمكنني تشغيله عبر http على شبكتي المحلية؟

تحتاج إلى HTTPS في كل حالة عدا اختبار عبر localhost. خزنة Bitwarden على الويب وإضافاتها تستخدم واجهة Web Crypto الخاصة بالمتصفح، وهي غير متاحة إلا في سياق آمن، فعبر http العادي يرمي العميل الخطأ Cannot read properties of undefined ولا يسجّل الدخول أبدًا. العنوان الوحيد عبر http الذي يعمل هو http://localhost، ولهذا يستخدم اختبار الاستعادة في الخطوة 8 نفقًا عبر SSH.

كيف أمنع الغرباء من التسجيل على خادمي؟

اضبط SIGNUPS_ALLOWED: "false" في ملف Compose ونفّذ docker compose up -d، فور إنشاء حسابك الخاص. ومن حينها، أضف أشخاصًا جددًا عبر زر Invite User في /admin، الذي يحتاج إلى إعداد SMTP حتى يستلموا رابط الدعوة. راجع قائمة مستخدمي الإدارة بين الحين والآخر للتأكد من عدم ظهور أي حساب غير متوقع.

كيف أنسخ خزنة Vaultwarden احتياطيًا؟

أوقف الحاوية لفترة وجيزة وأرشِف وحدة التخزين vw-data بأكملها — db.sqlite3 وattachments/ وsends/ وconfig.json وملفات rsa_key.* — ثم انسخ الأرشيف خارج الخادم، ويُفضَّل عبر cron ليلي. نسخ ملف SQLite أثناء كتابة الخادم فيه يخاطر بلقطة تالفة، فخذها باردة. والأهم من كل ذلك، استعدها مرة واحدة في حاوية للاستعمال المؤقت وسجّل الدخول، حتى تعرف أن النسخة الاحتياطية حقيقية قبل أن تعتمد عليها.

هل من الآمن فعلًا استضافة كلمات مروري بنفسي؟

نعم، حين تنفّذ الأشياء الثلاثة التي يغطيها هذا الدليل: HTTPS حقيقي، وتسجيل مغلق مع رمز إدارة قوي، ونسخ احتياطية مُختبَرة. خزنتك مشفَّرة من جهة العميل بكلمة مرورك الرئيسية، فحتى الخادم لا يرى كلمات مرورك الصريحة أبدًا — وملف db.sqlite3 المسروق عديم الفائدة دونها. المقابل هو أن تصحيح الثغرات والنسخ الاحتياطية أصبحت مسؤوليتك أنت الآن، ولهذا ليس Fail2ban واختبار الاستعادة اختياريَّين هنا.