מאת Matt Connor 2026-07-15 · עודכן 2026-07-24

איך להתקין Vaultwarden על VPS בעזרת Docker

Q: האם אני באמת חייב HTTPS, או שאני יכול להריץ את זה ב-http ברשת המקומית (LAN)?

נדרש HTTPS לכל מטרה פרט ל-localhost test. ה-web vault וה-extensions של Bitwarden משתמשים ב-Web Crypto API של הדפדפן, הזמין רק בהקשר מאובטח (secure context). לכן, בחיבור http רגיל, הלקוח יחזיר שגיאת Cannot read properties of undefined ולא יתבצע login. הכתובת היחידה ב-http שעובדת היא http://localhost, וזו הסיבה שבשלב 8 בבדיקת ה-restore נעשה שימוש ב-SSH tunnel.

Q: איך אני מונע מאנשים זרים להירשם לשרת שלי?

הגדר את SIGNUPS_ALLOWED: "false" בקובץ ה-Compose והרץ את docker compose up -d מיד לאחר יצירת החשבון שלך. לאחר מכן, הוסף משתמשים חדשים באמצעות כפתור ה-Invite User ב-/admin. הגדרת SMTP נדרשת כדי שהמשתמשים יקבלו את קישור ההזמנה. בדוק את רשימת משתמשי ה-admin מדי פעם כדי לוודא שלא נוצרו חשבונות לא צפויים.

Q: איך אני מגבה את ה-Vaultwarden vault שלי?

עצור את ה-container לזמן קצר וארכב את כל ה-vw-data volume — את הקבצים db.sqlite3, attachments/, sends/, config.json ו-rsa_key.* — ולאחר מכן העתק את הארכיון מהשרת, רצוי באמצעות cron יומי. העתקת קובץ SQLite פעיל בזמן שהשרת רץ עלולה לגרום לשגיאת snapshot corrupt, לכן בצע את הגיבוי כשהשרת כבוי (cold). הדבר החשוב ביותר הוא לבצע restore פעם אחת ב-container זמני ולהתחבר, כדי לוודא שהגיבוי תקין לפני שתסתמך עליו.

מדריך להרצת Vaultwarden בתוך Docker על שרת VPS. נלמד איך להגדיר HTTPS, להשתמש ב-Admin Token, להפעיל Fail2ban ולבצע גיבויים מסודרים לכל ה-Data Volume.

מה אתם בונים

מנהל סיסמאות בבעלות מלאה: Vaultwarden הפועל בתוך container אחד קטן מאחורי reverse proxy המבצע HTTPS termination, כאשר האפליקציות הרשמיות של Bitwarden בטלפון, במחשב ו בדפדפן מוגדרות للפנות אליו. Vaultwarden מממש מחדש את ה-API של השרת של Bitwarden בשפת Rust ומשתמש באותו פרוטוקול של bitwarden.com, לכן כל לקוח רשמי יעבוד מולו ללא שינוי — אך הוא צורך כ-100 MB של RAM, בניגוד למארג הרשמי המורכב ממספר containers.

תהליך ההתקנה כולל כ-12 שורות של Compose. שלושת הדברים הקריטיים — ואלו שעלולים להשתבש — הם אלו: חייב להיות TLS פעיל לפני הטעינה הראשונה של ה-web vault, יש לסגור את ההרשמה הציבורית (public signups) מיד לאחר יצירת החשבון האישי, ויש לגבות ולבצע שחזור בדיקה של ה-data volume, מכיוון שספרייה זו מכילה את כל הסיסמאות שלכם.

דרישות קדם ומכשולים נפוצים

שרת VPS עם Docker Engine ו-Compose plugin, על מערכת Ubuntu 24.04 KVM חדשה עם הרשאות root או sudo. זיכרון RAM של 512 MB מספיק בהחלט; 1 GB יספק נוחות. זהו אחד השירותים הקלים ביותר להרצה — הוא נמצא בראש רשימת השירותים ששווה לארח בעצמך.
דומיין עם רשומת A (ו-AAAA אם יש לך IPv6) המפנה את vault.example.com אל ה-VPS. תעודת ה-TLS מונפקת עבור השם הזה בדיוק, לכן ה-DNS חייב להיפתר לפני תחילת העבודה.
פורטים 80 ו-443 פתוחים לאינטרנט, ומנוהלים על ידי ה-reverse proxy שלך — לעולם לא ישירות על ידי Vaultwarden. פורט 80 משמש אך ורק עבור ACME certificate challenge ועבור הפניה מ-HTTP ל-HTTPS.
המכשול העיקרי: לקוחות Bitwarden מסרבים לתקשר עם שרת שאינו משתמש ב-HTTPS. אין אפשרות של "בדיקה דרך http תחילה" — המסלול הזה לא עובד, מהסיבה הספציפית שתפורט בהמשך.

Why Vaultwarden, not the official Bitwarden stack

אותם clients, אך עם משקל נמוך בהרבה. ה-stack הרשמי של Bitwarden בגרסת self-hosted מגיע כחבילה של containers (כגון MSSQL, Nginx, Identity, Api, Admin ועוד) ודורש כ-2 GB של RAM. Vaultwarden הוא binary יחיד אשר שומר הכל ב-SQLite database כברירת מחדל, וצורך רק עשרות megabytes במצב idle. עבור משתמש יחיד, משפחה או צוות קטן, זו הבחירה המתבקשת. מכיוון שהוא מממש את ה-Bitwarden API בצורה נאמנה, הנתונים שלך נשארים ניידים בין Vaultwarden לבין bitwarden.com.

מה שאתה מאבד הוא רוב תכונות ה-enterprise: אין SCIM provisioning (אם כי תמיכה ניסיונית ב-OpenID Connect SSO נוספה בגרסה 1.35.0), ואתה האחראי על המערכת, לכן patching, HTTPS ו-backups הם תפקידך. מדריך זה עוסק בשלושת התפקידים הללו.

מדוע HTTPS אינו אופציונלי

ה-web vault של Bitwarden והתוספים לדפדפן מפיקים את מפתחות ההצפנה בדפדפן באמצעות ה-Web Crypto API (window.crypto.subtle). דפדפנים חושפים את crypto.subtle רק בתוך secure context — כלומר ב-HTTPS, או במקרה המיוחד של http://localhost. בחיבור http://vault.example.com רגיל ה-API הוא undefined, ולכן ברגע שהאפליקציה מנסה להפיק מפתח היא קורסת, והקונסול מציג:

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

הדף נתקע או מציג שגיאת crypto כללית, ואין אפשרות להתחבר. הלקוחות של ה-desktop, ה-mobile והדפדפן מבצעים בדיקה עצמאית מול ה-URL המארח; מול endpoint ב-http (או endpoint שאינו נגיש) הם מסרבים עם השגיאה:

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

לשתי השגיאות יש את אותה סיבה: היעדר HTTPS תקף. לכן, יש להגדיר TLS תחילה ולא לפתוח את ה-vault מעל http, אפילו לא פעם אחת לצורך בדיקה מהירה.

Step 1 — DNS and the reverse proxy (TLS first)

הכו את הרשומה אל ה-VPS שלך וודא שהיא מתרגמת לכתובת הנכונה:

dig +short vault.example.com

השורה המודפסת חייבת להיות כתובת ה-IP של ה-VPS שלך. אם היא ריקה או שגויה, תקן את ה-DNS והמתן לסיום ה-TTL — הנפקת תעודה תיכשל אם השם אינו מתרגם לכתובת.

עבור ה-front end של ה-HTTPS, מדריך זה משתמש ב-Traefik, שמנפק ומחדש תעודות Let's Encrypt באופן אוטומטי ומתממשק ישירות ל-Compose. אם אינך מריץ אותו, בצע תחילה את הגדרת Traefik reverse proxy ו-automatic TLS. תהליך זה יוצר רשת Docker חיצונית (proxy להלן) ו-ACME resolver (letsencrypt) שאליו שירות Vaultwarden מתחבר. שימוש ב-nginx רגיל עם תעודה שהונפקה ידנית יעבוד בצורה זהה עבור Vaultwarden.

מעדיף nginx ו-Certbot במקום Traefik? מקם את Vaultwarden ב-127.0.0.1:8080 (הוסף את ports: ["127.0.0.1:8080:80"] לשירות והסר את ה-Traefik labels), ולאחר מכן הנפק תעודה ובצע proxy אליה. החלק של התעודה מוסבר ב-הנפקת תעודות Let's Encrypt באמצעות Certbot ו-nginx. ההבדל הקריטי הנוסף הוא ה-WebSocket upgrade בנתיב ה-notifications:

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 נמצאים בחזית.

Step 2 — קובץ ה-Compose

ראשית, צור את ספריית הפרויקט. מדריך זה משתמש ב-/opt/vaultwarden, מה שהופך את שם פרויקט ה-Compose — ולכן גם את ה-data volume, vaultwarden_vw-data — לצפוי; השלבים הבאים של Fail2ban וגיבוי תלויים בשם המדויק הזה.

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

צור .env עבור ה-admin secret וקובץ ה-Compose בתוך אותה ספרייה.

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

צור את ה-token באמצעות openssl rand -base64 48 והדבק אותו. (שימוש בפורמט hash חזק יותר יוסבר בהמשך; מחרוזת אקראית ארוכה תספיק בשלב זה.)

# 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 שלו — פרסום ה-port שלו על ה-host גורם לכך שמשתמשים מגיעים ל-vault ב-http בטעות. בנוסף, ה-DOMAIN חייב להיות ה-URL הציבורי המלא ב-HTTPS: הוא מוטמע בקישורי קבצים מצורפים, ב-WebAuthn 2FA וב-notifications endpoint, ולכן ערך שגוי או ערך http ישברו אותם גם אם האתר נטען. התג latest הוא חריג מכוון לכלל ה-never-latest המקובל — Vaultwarden מספקת גרסאות יציבות כ-single rolling image, כאשר :testing משמש כערוץ ה-pre-release נפרד — לכן בצע עדכון בכוונה וקרא את ה-release notes לפני ה-pull.

הפעל את המערכת ועקוב אחר ה-log:

docker compose up -d
docker compose logs -f vaultwarden

הפעלה תקינה מסתיימת בשורה כזו: Rocket has launched from http://0.0.0.0:80. תן ל-Traefik מספר שניות להשיג את ה-certificate, ולאחר מכן טען את https://vault.example.com — אתה אמור לקבל את ה-Bitwarden web vault עם סמל מנעול תקף וללא אזהרת תעודה.

Step 3 — a strong ADMIN_TOKEN, and the $$ trap

ADMIN_TOKEN מגן על /admin, הפאנל שיכול לקרוא כל משתמש והגדרה ב-instance שלך, לכן יש להתייחס אליו כמו לסיסמת root. שתי דרכים עובדות.

הדרך הפשוטה היא המחרוזת האקראית שכבר יצרת באמצעות openssl rand -base64 48. מכיוון ש-base64 לעולם אינו מכיל את $, הוא נכנס ישירות לתוך .env ללא צורך ב-escaping.

הדרך המאובטחת היא Argon2 PHC hash, כך שה-token בפורמט plaintext לעולם אינו נשמר על הדיסק. צור אחד מול אותו image:

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

התהליך מבקש את הקלט פעמיים ומדפיס מחרוזת שמתחילה ב-$argon2id$v=19$.... להלן המלכודת שגורמת לאנשים לבזבז שעה: Docker Compose מתייחס ל-$ כ-variable interpolation, לכן עליך להכפיל כל $ ב-$$ כאשר אתה מדביק את ה-hash בתוך קובץ ה-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 וימחוק את ה-token, ואז /admin יסרב לסיסמה הנכונה שלך. הרץ את docker compose up -d, ושמור את ה-plaintext שהקלדת ב-prompt בתוך מנהל הסיסמאות האישי שלך.

Step 4 — register your account, then lock the door

באמצעות SIGNUPS_ALLOWED: "true", פתח את https://vault.example.com, לחץ על Create account, והירשם באמצעות כתובת ה-email שלך וסיסמת מאסטר חזקה. לא ניתן לשחזר את סיסמת המאסטר הזו — אין אפשרות לאיפוס — לכן שמור אותה במקום בטוח לפני המשך התהליך.

כעת, סגור את הגישה. ערוך את קובץ ה-Compose כדי לבטל את הרששום החדש (signups):

      SIGNUPS_ALLOWED: "false"

הפעל מחדש באמצעות docker compose up -d. פעולה זו אינה חלק מתהליך ה-hardening וניתן לדחות אותה. אם תשאיר את ההרשמה פתוחה, כל מי שימצא את ה-URL — כולל crawlers — יוכל ליצור חשבון בשרת שלך. הם לא יוכלו לקרוא את ה-vault שלך, אך הם יצריכו משאבים ויפכו את ה-instance הפרטי שלך לשירות פתוח. סימן לכך שהשארת את ההרשמה פתוחה: /admin יציג חשבונות שמעולם לא יצרת.

כדי להוסיף בני משפחה או חברי צוות בהמשך מבלי לפתוח מחדש את ההרשום הציבורי, השתמש בכפתור Invite User בתוך /admin; נתיב זה דורש הגדרת SMTP כדי שהמוזמן יקבל את הקישור שלו.

Step 5 — גישה ל- /admin

גלוש ל-https://vault.example.com/admin והזן את ה-admin token בפורמט plaintext (מחרוזת אקראית, או הסיסמה שעליה הרצת hash — לא ה-hash עצמו). בתוך הממשק ניתן לרשום משתמשים, לכוון הגדרות, לשלוח אימייל בדיקה ולבצע snapshot לבסיס הנתונים.

אם הדף מחזיר 404 Not Found, סימן ש-ADMIN_TOKEN ריק או לא מוגדר, מה שמכבה את הפאנל לחלוטין — אפשרות תקפה אם אין צורך בו. אם הדף נטען אך דוחה את ה-token, עיין בבעיית ה-escaping של $$ ברשימת השגיאות להלן. שכחת את ה-token? אין אפשרות לשחזור; ערוך את .env או את ה-Compose file, הגדר token חדש, ובצע את docker compose up -d.

Step 6 — חיבור לקליינטים של Bitwarden

כל קליינט רשמי יכול להתחבר לשרת self-hosted. התקינו את ה-Bitwarden desktop, mobile או browser מהחנויות הרגילות — אין צורך בגרסת Vaultwarden מיוחדת.

לפני ההתחברות, פתחו את גלגל השיניים של ההגדרות במסך ההתחברות (מסומן כ-Self-hosted או Region → Self-hosted), הגדירו את ה-Server URL ל-https://vault.example.com, ושמרו. לאחר מכן התחברו עם כתובת ה-email וה-master password שנרשמו; הקליינט אמור להתחבר באופן מיידי ולהציע למלא ולשמור פרטי גישה.

אם קליינט מציג 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, ונושא זה נסקר בהמשך.

Vaultwarden רושמת כל ניסיון התחברות שנכשל לקובץ שהוגדר על ידי LOG_FILE — בדיוק מה שנדרש להגנה מפני brute-force. אם Fail2ban אינו מותקן אצלכם, ניתן למצוא את ההתקנה והיסודות בתוך מדריך ה-SSH hardening של Fail2ban; כאן נוסיף jail אחד עבור ה-vault.

ראשית, מצאו היכן נמצא ה-named volume על ה-host, כדי ש-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 או את כתובת ה-proxy בכל ניסיון כושל, Vaultwarden תחסום את ה-proxy — הגדירו את IP_HEADER לכותרת (header) שה-proxy שלכם שולח בפועל (X-Forwarded-For עבור Traefik, X-Real-IP עבור ה-nginx block לעיל, CF-Connecting-IP מאחורי Cloudflare). שנית, ה-iptables chain המתאים תלוי ב-proxy שלכם: אם Traefik רץ כ-container עם ports שפורסמו, התעבורה עוברת דרך ה-FORWARD path של Docker, ולכן החסימה חייבת להיות ב-DOCKER-USER כפי שמוצג לעיל; אך אם בחרתם באופציית ה-host-nginx מ-Step 1, החיבורים מסתיימים ב-nginx ב-INPUT chain של ה-host, וחסימת DOCKER-USER לעולם לא תראה אותם — במקרה זה, מחקו את שורת chain = DOCKER-USER כדי ש-Fail2ban ישתמש ב-INPUT chain ברירת המחדל. שלישית, השתמשו ב-banaction = iptables-allports במקום ברירת המחדל המבוססת על port — ה-jail הזה אינו מגדיר port, וחסימה של כל ה-ports ב-DOCKER-USER תחסום את המפר על כל שירות שפורסם על המכונה.

Step 8 — גיבוי ה-vault, ולאחר מכן שחזור בפועל

ה-volume ‏vw-data הוא מנהל הסיסמאות שלך. הוא מכיל את db.sqlite3 (כל רשומה), את התיקיות attachments/ ו-sends/, את הקבצים rsa_key.* החותמים על סשני התחברות, ואת config.json מלוח הבקרה. גיבוי שמ пропуска כל אחד מהמרכיבים הללו ייכשל בעת הצורך.

העתקת db.sqlite3 בזמן ש-Vaultwarden כותב עלולה לייצר קובץ פגום וחצוי, לכן יש ליצור snapshot כשהשירות כבוי (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 יומי לשרת אחר או לאחסון אובייקטים, אשר מצפין את הארכיון ומבצע deduplication ל-snapshots חוזרים. כפתור ה-Backup Database בלוח הבקרה הוא כלי נוח ליצירת snapshot מהיר של קובץ ה-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 הוא context מאובטח, crypto.subtle יהיה זמין וה-vault יתפרוש (decrypt) באמצעות http רגיל — המקום היחיד המורשה לכך. התחבר עם סיסמת המקור (master password) וודא שהרשומות שלך קיימות: אם הן קיימות, מסד הנתונים, מפתחות ה-RSA וסיסמת המקור עברו תהליך מלא, ותוכל לשחזר את המערכת ב-VPS חדש תוך דקות. עצור את ה-container באמצעות Ctrl-C ומחק את /tmp/vw-restore.

מצבי כשל, עם המחרוזות שיוצגו

Cannot read properties of undefined (reading 'importKey') בקונסול של הדפדפן. ה-vault נטען מעל http, לכן crypto.subtle אינו מוגדר; יש לגשת אליו רק דרך https:// ולהוסיף הפניית HTTP-to-HTTPS ב-proxy.

This is not a recognized Bitwarden server... בלקוח (client). ה-Server URL הוא http, הוקש בטעות, או שהתעודה (certificate) אינה מהימנה; ודא ש-https://vault.example.com מציג מנעול תקין, ולאחר מכן הקש אותו מחדש בהגדרות ה-self-hosted של הלקוח.

/admin דוחה את הסיסמה הנכונה. ה-Argon2 hash איבד את ה-escaping שלו — כל $ חייב להיות $$ ב-Compose — או שהקלדת את ה-hash במקום את הטקסט הגלוי (plaintext) שהוא מייצג.

סנכרון איטי בין מכשירים; הקונסול מציג WebSocket connection to 'wss://vault.example.com/notifications/hub' failed. ה-proxy אינו מעביר את ה-headers של Upgrade/Connection; Traefik מבצע זאת באופן אוטומטי, nginx דורש את שתי שורות ה-upgrade מ-Step 1. ה-vault עדיין עובד, הוא פשוט מסנכרן בעת הפתיחה. הפורט הייעודי הישן 3012 הוסר החל מגרסה v1.31.0, לכן אין צורך בנתיב WebSocket נפרד.

Fail2ban מדווח על חסימה אך התוקף ממשיך להתחבר. הוא חוסם את 127.0.0.1 מכיוון ש-IP_HEADER אינו נכון, או שהחסימה נמצאת ב-iptables chain לא נכונה — הגדר את chain = DOCKER-USER ו-banaction = iptables-allports.

Upgrades

הורד את ה-image החדש והרם מחדש; ה-named volume וכל הנתונים שלך יישארו קיימים:

docker compose pull
docker compose up -d

Vaultwarden מפיק גרסאות בתדירות גבוהה. מומלץ לעקוב אחר הערות הגרסה של הפרויקט במקום לקבע גרסת patch, מכיוון שחלק מהגרסאות כוללות הערות על migration. בצע גיבוי חדש לפני כל עדכון גרסה משמעותי; ניתן לבצע rollback על ידי שחזור ה-tarball לתוך volume חדש.

FAQ

האם Vaultwarden זהה ל-Bitwarden?

זהו שרת עצמאי ותואם, לא השרת הרשמי. Vaultwarden מממש מחדש את ה-API של שרת Bitwarden בשפת Rust, ולכן כל הלקוחות הרשמיים (desktop, mobile, browser ו-CLI) עובדים מולו בצריכת משאבים נמוכה משמעותית מהמערכת הרשמית. פורמט ה-vault זהה, לכן ניתן לבצע מיגרציה לכל כיוון באמצעות ייצוא וייבוא.

האם אני באמת חייב HTTPS, או שאני יכול להריץ את זה ב-http ברשת המקומית (LAN)?

נדרש HTTPS לכל מטרה פרט ל-localhost test. ה-web vault וה-extensions של Bitwarden משתמשים ב-Web Crypto API של הדפדפן, הזמין רק בהקשר מאובטח (secure context). לכן, בחיבור http רגיל, הלקוח יחזיר שגיאת Cannot read properties of undefined ולא יתבצע login. הכתובת היחידה ב-http שעובדת היא http://localhost, וזו הסיבה שבשלב 8 בבדיקת ה-restore נעשה שימוש ב-SSH tunnel.

איך אני מונע מאנשים זרים להירשם לשרת שלי?

הגדר את SIGNUPS_ALLOWED: "false" בקובץ ה-Compose והרץ את docker compose up -d מיד לאחר יצירת החשבון שלך. לאחר מכן, הוסף משתמשים חדשים באמצעות כפתור ה-Invite User ב-/admin. הגדרת SMTP נדרשת כדי שהמשתמשים יקבלו את קישור ההזמנה. בדוק את רשימת משתמשי ה-admin מדי פעם כדי לוודא שלא נוצרו חשבונות לא צפויים.

איך אני מגבה את ה-Vaultwarden vault שלי?

עצור את ה-container לזמן קצר וארכב את כל ה-vw-data volume — את הקבצים db.sqlite3, attachments/, sends/, config.json ו-rsa_key.* — ולאחר מכן העתק את הארכיון מהשרת, רצוי באמצעות cron יומי. העתקת קובץ SQLite פעיל בזמן שהשרת רץ עלולה לגרום לשגיאת snapshot corrupt, לכן בצע את הגיבוי כשהשרת כבוי (cold). הדבר החשוב ביותר הוא לבצע restore פעם אחת ב-container זמני ולהתחבר, כדי לוודא שהגיבוי תקין לפני שתסתמך עליו.

האם זה באמת בטוח לארח את הסיסמאות שלי בעצמי (self-host)?

כן, כאשר מבצעים את שלושת הדברים המפורטים במדריך זה: HTTPS אמיתי, חסימת הרשמה עצמית (closed signups) בתוספת admin token חזק, וגיבויים שנבדקו. ה-vault שלך מוצפן בצד הלקוח באמצעות ה-master password שלך, ולכן השרת לעולם לא רואה את הסיסמאות בפורמט גלוי — db.sqlite3 גנוב יהיה חסר ערך ללא הסיסמה. המחיר הוא שעדכוני אבטחה (patching) וגיבויים הם באחריותך, ולכן שימוש ב-Fail2ban וביצוע טקס ה-restore אינם אופציונליים.

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