SSD Nodes Learn
Panduan Matt ConnorOleh Matt Connor · Dikemas kini 2026-07-24

Cara pasang Vaultwarden pada VPS guna Docker

Panduan lengkap hos sendiri Vaultwarden pada VPS menggunakan Docker. Pelajari cara tetapan HTTPS, token admin, Fail2ban dan cara sandaran data yang selamat.

Apa yang anda bina

Pengurus kata laluan milik penuh anda: Vaultwarden yang dijalankan dalam satu kontena kecil di belakang reverse proxy yang menamatkan HTTPS, dengan aplikasi Bitwarden rasmi pada telefon, komputer riba, dan pelayar anda yang dihalakan kepadanya. Vaultwarden melaksanakan semula API pelayan Bitwarden dalam Rust dan menggunakan protokol yang sama dengan bitwarden.com, jadi setiap klien rasmi berfungsi tanpa sebarang perubahan — tetapi ia hanya menggunakan sekitar 100 MB RAM berbanding stack rasmi yang menggunakan pelbagai kontena.

Proses pemasangan hanya memerlukan belasan baris Compose. Tiga perkara utama yang penting — dan yang sering menyebabkan kegagalan — adalah ini: TLS mesti tersedia sebelum anda memuatkan web vault, pendaftaran awam mesti ditutup sebaik sahaja akaun anda wujud, dan volum data mesti disandarkan serta diuji pemulihannya, kerana satu direktori tersebut menyimpan setiap kata laluan anda.

Prasyarat dan cabaran sebenar

  • VPS dengan Docker Engine dan plugin Compose, pada sistem Ubuntu 24.04 KVM yang baharu dengan akses root atau sudo. 512 MB RAM sudah mencukupi; 1 GB adalah lebih selesa. Ini adalah antara perkhidmatan paling ringan — ia berada dalam senarai teratas perkhidmatan yang berbaloi untuk self-hosting.
  • Domain dengan rekod A (dan AAAA jika anda menggunakan IPv6) yang menghala ke vault.example.com pada VPS. Sijil TLS dikeluarkan untuk nama ini, jadi DNS mesti diselesaikan sebelum anda bermula.
  • Port 80 dan 443 dibuka kepada internet, diuruskan oleh reverse proxy anda — jangan sekali-kali biarkan Vaultwarden menguruskannya secara terus. Port 80 hanya digunakan untuk cabaran sijil ACME dan penghalaan HTTP-ke-HTTPS.
  • Cabaran utama: klien Bitwarden tidak akan menyambung ke pelayan yang tidak menggunakan HTTPS. Tiada pilihan untuk "uji melalui http terlebih dahulu" — kaedah tersebut tidak berfungsi atas sebab khusus yang akan dijelaskan selepas ini.

Mengapa Vaultwarden, bukan stack Bitwarden rasmi

Pelanggan yang sama, penggunaan sumber yang jauh lebih rendah. Bitwarden rasmi yang dihoskan sendiri dihantar sebagai bundle kontena (MSSQL, Nginx, Identity, Api, Admin dan lain-lain) dan memerlukan sekitar 2 GB RAM. Vaultwarden adalah satu binari tunggal yang menyimpan semua data dalam pangkalan data SQLite secara lalai dan hanya menggunakan beberapa puluh megabait semasa dalam keadaan idle. Untuk seorang individu, keluarga atau pasukan kecil, ia adalah pilihan yang jelas, dan kerana ia melaksanakan Bitwarden API dengan tepat, data anda kekal boleh dipindahkan antara Vaultwarden dan bitwarden.com.

Apa yang anda korbankan adalah kebanyakan ciri perusahaan: tiada penyediaan SCIM (walaupun OpenID Connect SSO eksperimental telah diperkenalkan dalam 1.35.0), dan anda adalah pengendali, jadi proses menampal (patching), HTTPS dan sandaran adalah tugas anda. Panduan ini merangkumi ketiga-tiga tugas tersebut.

Mengapa HTTPS bukan pilihan

Bitwarden web vault dan sambungan pelayar menjana kunci penyulitan anda di dalam pelayar menggunakan Web Crypto API (window.crypto.subtle). Pelayar hanya mendedahkan crypto.subtle dalam konteks selamat — HTTPS, atau kes khas untuk http://localhost. Melalui http://vault.example.com biasa, ia adalah undefined, jadi sebaik sahaja aplikasi menjana kunci, ia akan gagal, dan konsol akan memaparkan:

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

Halaman akan tergantung atau memaparkan ralat kripto generik, dan tiada sesi log masuk berjaya. Klien desktop, mudah alih, dan pelayar menjalankan semakan sendiri terhadap URL yang dihoskan sendiri, dan terhadap titik akhir http (atau tidak boleh dicapai), ia akan ditolak dengan:

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

Kedua-duanya mempunyai punca yang sama: tiada HTTPS yang sah. Oleh itu, anda perlu menyediakan TLS terlebih dahulu dan jangan sesekali membuka vault melalui http, walaupun hanya sekali untuk semakan pantas.

Langkah 1 — DNS dan reverse proxy (TLS dahulu)

Arahkan rekod ke VPS anda dan sahkan ia resolusi ke alamat yang betul:

dig +short vault.example.com

Baris yang dipaparkan mestilah IP VPS anda. Jika kosong atau salah, betulkan DNS dan tunggu sehingga TTL tamat — pengeluaran sijil akan gagal jika nama tidak dapat diresolusi.

Untuk bahagian hadapan HTTPS, panduan ini menggunakan Traefik, yang mengeluarkan dan memperbaharui sijil Let's Encrypt secara automatik dan disepadukan terus ke dalam Compose. Jika anda belum menggunakannya, ikuti tetapan reverse proxy Traefik dan TLS automatik terlebih dahulu; ia mencipta rangkaian Docker luaran (proxy di bawah) dan resolver ACME (letsencrypt) yang akan disambungkan oleh perkhidmatan Vaultwarden. Nginx biasa dengan sijil manual berfungsi secara identikal dari sisi Vaultwarden.

Lebih suka nginx dan Certbot berbanding Traefik? Letakkan Vaultwarden pada 127.0.0.1:8080 (tambah ports: ["127.0.0.1:8080:80"] pada perkhidmatan dan buang label Traefik), kemudian keluarkan sijil dan proxy ke arahnya. Bahagian sijil dibincangkan dalam mengeluarkan sijil Let's Encrypt dengan Certbot dan nginx. Perkara tambahan yang kritikal ialah peningkatan WebSocket pada laluan pemberitahuan:

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";
    }
}

Perhatikan baris X-Real-IP — ia membolehkan Fail2ban melihat penyerang sebenar dan bukannya 127.0.0.1 pada masa hadapan. Semua perkara lain dalam panduan ini adalah sama sama ada Traefik atau nginx berada di hadapan.

Step 2 — fail Compose file

Cipta direktori projek terlebih dahulu. Panduan ini menggunakan /opt/vaultwarden, yang menjadikan nama projek Compose — dan seterusnya volum data, vaultwarden_vw-data — boleh diramal; langkah Fail2ban dan sandaran di bawah bergantung pada nama tepat tersebut.

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

Cipta .env untuk rahsia admin dan fail Compose di dalam direktori tersebut.

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

Jana token tersebut dengan openssl rand -base64 48 dan tampal ke dalamnya. (Bentuk hash yang lebih kuat akan dibincangkan selepas ini; rentetan rawak yang panjang sudah memadai untuk permulaan.)

# 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

Dua perkara dalam fail ini menentukan keseluruhan reka bentuk. Tiada pemetaan ports:, jadi Vaultwarden hanya boleh dicapai melalui Traefik dan TLS — mendedahkan portnya pada hos akan menyebabkan pengguna mengakses vault melalui http secara tidak sengaja. Dan DOMAIN mestilah URL HTTPS awam yang lengkap: ia disepadukan ke dalam pautan lampiran, WebAuthn 2FA dan titik akhir pemberitahuan, jadi nilai yang salah atau http akan merosakkan fungsi tersebut walaupun laman web boleh dimuatkan. Tag latest adalah pengecualian sengaja kepada peraturan biasa jangan-latest — Vaultwarden mengeluarkan versi stabil sebagai imej tunggal yang sentiasa dikemas kini, dengan :testing sebagai saluran pra-pelancaran yang berasingan — jadi kemas kini dengan sengaja dan semak nota keluaran sebelum anda melakukan pull.

Jalankan dan perhatikan log:

docker compose up -d
docker compose logs -f vaultwarden

Permulaan yang betul akan berakhir dengan baris seperti Rocket has launched from http://0.0.0.0:80. Berikan Traefik beberapa saat untuk mengambil sijil, kemudian muat https://vault.example.com — anda sepatutnya mendapat Bitwarden web vault dengan ikon mangga yang sah dan tanpa amaran sijil.

Langkah 3 — ADMIN_TOKEN yang kuat, dan perangkap $$

ADMIN_TOKEN melindungi /admin, panel yang boleh membaca setiap pengguna dan tetapan pada instance anda, jadi layan ia seperti kata laluan root. Dua bentuk tersedia.

Bentuk ringkas ialah rentetan rawak yang telah anda jana dengan openssl rand -base64 48. Kerana base64 tidak pernah mengandungi $, ia boleh dimasukkan terus ke dalam .env tanpa perlu escaping.

Bentuk kukuh ialah hash Argon2 PHC, supaya token teks biasa tidak pernah disimpan pada cakera. Jana satu menggunakan imej yang sama:

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

Ia akan meminta input sebanyak dua kali dan mencetak rentetan yang bermula dengan $argon2id$v=19$.... Berikut ialah perangkap yang membuang masa pengguna selama sejam: Docker Compose menganggap $ sebagai interpolasi pemboleh ubah, jadi anda mesti menggandakan setiap $ kepada $$ apabila anda menampal hash tersebut ke dalam fail Compose. Letakkan ia terus di bawah environment:, bukan melalui .env, dan jangan bungkus ia dengan tanda petik:

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

Jika anda membiarkan tanda $ tunggal, Compose akan memberi amaran The "argon2id" variable is not set dan mengosongkan token tersebut, dan /admin kemudiannya akan menolak kata laluan anda yang betul. Jalankan docker compose up -d, dan simpan teks biasa yang anda taip semasa prompt di dalam stor kata laluan anda sendiri.

Langkah 4 — daftar akaun anda, kemudian kunci akses

Dengan SIGNUPS_ALLOWED: "true", buka https://vault.example.com, klik Create account, dan daftar menggunakan e-mel serta kata laluan utama yang kuat. Kata laluan utama ini tidak boleh dipulihkan — tiada fungsi tetapan semula — jadi simpan ia di tempat yang selamat terlebih dahulu.

Sekarang tutup akses tersebut. Edit fail Compose supaya pendaftaran ditutup:

      SIGNUPS_ALLOWED: "false"

Gunakan semula dengan docker compose up -d. Ini bukan langkah pengukuhan yang boleh ditangguhkan. Jika dibiarkan terbuka, sesiapa sahaja yang menemui URL tersebut — termasuk bot pencari — boleh mendaftar akaun pada pelayan anda. Mereka tidak boleh membaca vault anda, tetapi mereka menggunakan sumber sistem dan menukar instans peribadi anda menjadi perkhidmatan awam. Tanda jika anda membiarkannya terbuka: /admin menyenaraikan akaun yang tidak pernah anda daftar.

Untuk menambah ahli keluarga atau rakan sepasukan kemudian tanpa membuka semula pendaftaran awam, gunakan butang Invite User dalam /admin; laluan tersebut memerlukan konfigurasi SMTP supaya penerima menerima pautan mereka.

Step 5 — mengakses /admin

Layari https://vault.example.com/admin dan masukkan token admin teks biasa (rentetan rawak, atau kata laluan yang telah anda hash — bukan hash itu sendiri). Di dalamnya, anda boleh menyenaraikan pengguna, melaras tetapan, menghantar e-mel ujian, dan mengambil snapshot pangkalan data.

Jika halaman mengembalikan 404 Not Found, ADMIN_TOKEN adalah kosong atau tidak ditetapkan, yang akan menyahaktifkan panel sepenuhnya — ini adalah pilihan yang sah jika anda tidak memerlukannya. Jika ia dimuatkan tetapi menolak token anda, lihat perangkap escaping $$ dalam senarai kegagalan di bawah. Lupa token? Tiada arahan pemulihan; edit .env atau fail Compose, tetapkan token baharu, dan docker compose up -d.

Langkah 6 — sambungkan klien Bitwarden

Setiap klien rasmi boleh disambungkan ke pelayan hos sendiri. Pasang klien Bitwarden untuk desktop, mudah alih, atau pelayar daripada stor biasa — anda tidak memerlukan binaan Vaultwarden yang khas.

Sebelum log masuk, buka ikon tetapan pada skrin log masuk (berlabel Self-hosted atau Region → Self-hosted), tetapkan Server URL kepada https://vault.example.com, dan simpan. Kemudian log masuk menggunakan e-mel dan kata laluan utama yang telah didaftarkan; klien sepatutnya bersambung dengan segera dan menawarkan untuk mengisi serta menyimpan kredensial.

Jika klien memaparkan This is not a recognized Bitwarden server. You may need to check with your provider or update your server., URL adalah salah, menggunakan http, atau sijil tidak dipercayai — pastikan https://vault.example.com boleh dimuatkan dengan betul dalam pelayar terlebih dahulu. Kelewatan kemas kini pada peranti lain adalah disebabkan WebSocket push, yang dibincangkan di bawah.

Step 7 — jail Fail2ban untuk endpoint log masuk

Vaultwarden mencatat setiap kegagalan log masuk ke dalam fail yang ditetapkan oleh LOG_FILE — ini adalah keperluan untuk perlindungan brute-force. Jika anda belum menjalankan Fail2ban, pemasangan dan asasnya ada dalam panduan pengukuhan SSH Fail2ban; di sini kita menambah satu jail untuk vault.

Pertama, cari lokasi volume bernama pada host supaya Fail2ban boleh membaca log tersebut:

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

Ia akan memaparkan sesuatu seperti /var/lib/docker/volumes/vaultwarden_vw-data/_data; log berada di dalam vaultwarden.log. Cipta penapis (filter):

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

Dan 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

Muat semula dengan sudo systemctl restart fail2ban dan sahkan dengan sudo fail2ban-client status vaultwarden.

Tiga butiran Docker menentukan sama ada perlindungan ini berfungsi. Pertama, jika log menunjukkan IP: 127.0.0.1 atau alamat proxy anda pada setiap percubaan gagal, Vaultwarden akan menyekat proxy tersebut — tetapkan IP_HEADER kepada header yang dihantar oleh proxy anda (X-Forwarded-For untuk Traefik, X-Real-IP untuk blok nginx di atas, CF-Connecting-IP di belakang Cloudflare). Kedua, rantaian iptables yang betul bergantung pada proxy anda: jika Traefik berjalan sebagai container dengan port yang diterbitkan, trafik melalui laluan FORWARD Docker, jadi sekatan mesti berada dalam DOCKER-USER seperti di atas; tetapi jika anda memilih pilihan host-nginx dari Step 1, sambungan tamat pada nginx pada rantaian INPUT host dan sekatan DOCKER-USER tidak akan mengesan mereka — dalam kes ini, padam baris chain = DOCKER-USER supaya Fail2ban menggunakan rantaian INPUT lalai. Ketiga, gunakan banaction = iptables-allports berbanding tetapan lalai berasaskan port — jail ini tidak menetapkan port, dan sekatan semua port dalam DOCKER-USER akan menyekat pelaku daripada setiap perkhidmatan yang diterbitkan pada mesin tersebut dengan bersih.

Step 8 — sandarkan vault, kemudian lakukan pemulihan

Volume vw-data adalah pengurus kata laluan anda. Ia mengandungi db.sqlite3 (setiap entri), direktori attachments/ dan sends/, fail rsa_key.* yang menandatangani sesi log masuk, dan config.json daripada panel admin. Sandaran yang melangkau mana-mana komponen ini akan gagal apabila diperlukan.

Menyalin db.sqlite3 semasa Vaultwarden sedang menulis boleh menghasilkan fail yang separa ditulis dan rosak, jadi ambil snapshot sejuk — tempoh henti hanya beberapa saat:

#!/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

Jalankan ia melalui cron setiap malam dan salin .tgz keluar daripada mesin tersebut — sandaran yang hanya disimpan pada pelayan yang sedang dilindungi bukanlah sandaran yang sah. Cara terbaik untuk menghantarnya adalah sandaran restic setiap malam ke pelayan lain atau storan objek, yang menyulitkan arkib dan melakukan deduplikasi untuk snapshot yang berulang. Butang Backup Database pada panel admin adalah snapshot pantas bagi fail SQLite sahaja, tetapi ia tidak menyertakan lampiran dan kunci.

Sekarang, langkah yang membezakan sandaran sebenar daripada sandaran yang sekadar harapan — pulihkan sekali dan buktikan ia berfungsi:

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

Dari komputer riba anda, buat terowong ke arahnya dengan ssh -L 8888:127.0.0.1:8888 you@your-vps dan buka http://localhost:8888. Kerana localhost adalah konteks selamat, crypto.subtle tersedia dan vault dinyahsulit melalui http biasa di sini — satu-satunya tempat yang dibenarkan. Log masuk dengan kata laluan utama anda dan sahkan entri anda ada di situ: jika ada, pangkalan data, kunci RSA dan kata laluan utama anda semuanya berjaya melalui proses pemulihan, dan anda boleh membina semula pada VPS baharu dalam masa beberapa minit. Hentikan kontena dengan Ctrl-C dan padam /tmp/vw-restore.

Mod kegagalan, dengan rentetan yang akan anda lihat

Cannot read properties of undefined (reading 'importKey') dalam konsol pelayar. Vault dimuatkan melalui http, maka crypto.subtle adalah tidak ditakrifkan; akses hanya melalui https:// dan tambahkan penghalaan HTTP-ke-HTTPS pada proxy.

This is not a recognized Bitwarden server... pada klien. URL Pelayan adalah http, tersalah taip, atau sijil tidak dipercayai; sahkan https://vault.example.com menunjukkan mangga yang sah, kemudian masukkan semula dalam tetapan hos sendiri klien.

/admin menolak kata laluan yang betul. Hash Argon2 kehilangan escaping — setiap $ mestilah $$ dalam Compose — atau anda memasukkan hash dan bukannya teks biasa yang diwakilinya.

Penyinkronan rentas peranti yang perlahan; konsol menunjukkan WebSocket connection to 'wss://vault.example.com/notifications/hub' failed. Proxy tidak menghantar pengepala Upgrade/Connection; Traefik melakukan ini secara automatik, nginx memerlukan dua baris upgrade daripada Langkah 1. Vault masih berfungsi, cuma penyinkronan berlaku semasa dibuka. Port khas 3012 yang lama telah ditiadakan sejak v1.31.0, jadi tiada laluan WebSocket berasingan diperlukan.

Fail2ban melaporkan sekatan tetapi penyerang terus menyambung. Ia menyekat 127.0.0.1 kerana IP_HEADER adalah salah, atau sekatan berada dalam rantaian iptables yang salah — tetapkan chain = DOCKER-USER dan banaction = iptables-allports.

Upgrades

Muat turun imej baharu dan bina semula; volume bernama dan semua data anda akan kekal:

docker compose pull
docker compose up -d

Vaultwarden mengeluarkan kemas kini dengan kerap. Rujuk nota keluaran projek berbanding menetapkan versi tampalan tertentu, kerana sesetengah keluaran mengandungi nota migrasi. Buat sandaran baharu sebelum sebarang peningkatan versi yang besar; anda boleh melakukan pemulihan dengan memulihkan fail tarball ke dalam volume baharu.

FAQ

Adakah Vaultwarden sama dengan Bitwarden?

Ia adalah pelayan bebas yang serasi, bukan pelayan rasmi. Vaultwarden melaksanakan semula API pelayan Bitwarden dalam Rust, jadi semua klien desktop, mudah alih, pelayar dan CLI rasmi boleh berfungsi dengannya menggunakan sumber yang jauh lebih rendah. Format peti simpanan adalah sama, jadi anda boleh migrasi ke mana-mana arah dengan mengeksport dan mengimport data.

Adakah saya benar-benar memerlukan HTTPS, atau bolehkah saya menjalankannya melalui http pada LAN saya?

Anda memerlukan HTTPS untuk apa jua tujuan kecuali ujian localhost. Web vault dan sambungan Bitwarden menggunakan Web Crypto API pelayar, yang hanya tersedia dalam konteks selamat. Melalui http biasa, klien akan mengeluarkan ralat Cannot read properties of undefined dan tidak boleh log masuk. Satu-satunya alamat http yang berfungsi ialah http://localhost, sebab itu ujian pemulihan dalam Langkah 8 menggunakan terowong SSH.

Bagaimanakah cara untuk menghalang orang asing daripada mendaftar pada pelayan saya?

Tetapkan SIGNUPS_ALLOWED: "false" dalam fail Compose dan jalankan docker compose up -d sejurus selepas anda mencipta akaun sendiri. Selepas itu, tambah pengguna baharu melalui butang Invite User dalam /admin, yang memerlukan konfigurasi SMTP supaya mereka menerima pautan jemputan. Periksa senarai pengguna admin secara berkala untuk memastikan tiada akaun yang tidak dikenali muncul.

Bagaimanakah cara untuk membuat sandaran (backup) peti simpanan Vaultwarden saya?

Hentikan kontena buat seketika dan arkibkan keseluruhan volum vw-data — fail db.sqlite3, attachments/, sends/, config.json dan rsa_key.* — kemudian salin arkib tersebut keluar dari pelayan, sebaik-baiknya melalui cron harian. Menyalin fail SQLite yang sedang aktif berisiko menyebabkan snapshot rosak, jadi lakukan proses ini semasa pelayan tidak aktif. Yang paling penting, cuba pulihkan sandaran tersebut sekali ke dalam kontena sementara dan log masuk, supaya anda tahu sandaran itu berfungsi sebelum anda bergantung kepadanya.

Adakah selamat untuk hos sendiri (self-host) kata laluan saya?

Ya, jika anda melakukan tiga perkara yang dibincangkan dalam panduan ini: HTTPS yang sebenar, pendaftaran ditutup beserta token admin yang kuat, dan sandaran yang telah diuji. Peti simpanan anda disulitkan di sebelah klien dengan kata laluan utama anda, jadi pelayan tidak akan melihat kata laluan anda dalam bentuk teks biasa — db.sqlite3 yang dicuri tidak berguna tanpanya. Risikonya ialah proses menampal (patching) dan sandaran kini menjadi tanggungjawab anda, sebab itulah Fail2ban dan ritual pemulihan adalah wajib di sini.

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