23 Agustus 2026

Vaultwarden: Kompatibilitas Bitwarden di Server Sendiri

Catatan deployment Vaultwarden: server password manager self-hosted berbasis Rust yang kompatibel dengan klien Bitwarden resmi, termasuk arsitektur, deployment Docker Compose, syarat HTTPS, strategi backup SQLite WAL, dan keterbatasannya.

Vaultwarden adalah implementasi alternatif server Bitwarden dalam Rust: satu binary ringan yang kompatibel dengan klien Bitwarden resmi. Tulisan ini catatan deployment dan evaluasi, bukan klaim pengganti semua kebutuhan manajemen kredensial.

Mengapa server Bitwarden sendiri

Cloud Bitwarden nyaman — kliennya bagus — tapi ada tiga ganjalan: data tetap di server pihak ketiga walau terenkripsi; TOTP, attachment, dan organisasi butuh langganan premium; dan server resminya resource-heavy dan berbasis .NET, mahal untuk di-self-host. Vaultwarden menjawab ketiganya: kompatibel dengan semua klien resmi (extension browser, iOS/Android, desktop), ringan — RAM umumnya di bawah 50 MB — dan fitur premium gratis. Nilai utamanya kompatibilitas: klien tetap sama, hanya alamat server yang berubah.

Arsitektur: satu binary Rust di belakang API Bitwarden

Vaultwarden mengimplementasikan Bitwarden Client API hampir lengkap dalam satu binary Rust dengan SQLite sebagai backend bawaan; web vault yang disertakan adalah build Bitwarden resmi dengan patch, jadi UI-nya identik dengan bitwarden.com. Data dienkripsi di sisi klien; server hanya menyimpan ciphertext, master password tak pernah dikirim. Semua data ada dalam satu direktori: db.sqlite3 (plus file -wal/-shm), folder attachments/, sends/, config.json, dan key rsa_key.* untuk token autentikasi. Live-sync WebSocket untuk browser/desktop aktif bawaan sejak v1.29 dan berjalan di port HTTP utama sejak v1.31 (port 3012 lama dihapus); klien mobile memakai push FCM/APNs yang butuh kredensial dari cloud Bitwarden.

Deployment dengan Docker Compose

Berikut konfigurasi Compose yang dipakai:

services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      - WEBSOCKET_ENABLED=true
    volumes:
      - ./vw-data:/data
    ports:
      - "8008:80"

Volume ./vw-data memegang semua data persisten; port 8008 dipublish dari port 80. Jika lewat reverse proxy, set environment DOMAIN ke URL publik. Catatan: WEBSOCKET_ENABLED deprecated sejak v1.29 — WebSocket aktif bawaan, cukup pastikan proxy meneruskan header Upgrade/Connection. Image bawaan berjalan sebagai root; untuk least privilege tambahkan user: "1000:1000".

HTTPS wajib dan pengamanan admin panel

HTTPS bukan pilihan: web vault memakai Web Crypto API yang hanya tersedia di secure context, dan klien menolak HTTP polos kecuali localhost. Cara yang direkomendasikan: reverse proxy penangan TLS — Caddy, Nginx Proxy Manager, Traefik, Cloudflare Tunnel, atau Tailscale HTTPS — dengan sertifikat Let’s Encrypt atau origin certificate Cloudflare. HTTPS bawaan via ROCKET_TLS tidak disarankan: kurang matang, tanpa ECC, tanpa strict SNI. Aplikasi mobile butuh OCSP stapling yang benar; self-signed atau chain tak lengkap membuat login gagal di banyak perangkat.

Admin panel /admin aktif hanya jika ADMIN_TOKEN diset. Pakai string acak panjang (misal openssl rand -base64 32), sebaiknya hash argon2id via vaultwarden hash, aktifkan hanya setelah HTTPS berjalan. Registrasi publik aktif bawaan: set SIGNUPS_ALLOWED=false untuk instance pribadi. Pertimbangkan juga fail2ban untuk membatasi percobaan login berulang.

Backup database SQLite WAL

Hampir semua data brankas ada di db.sqlite3 dalam direktori /data. Mode WAL membuat salinan langsung saat container berjalan berisiko korup; cara yang benar: perintah .backup dari sqlite3 CLI (Online Backup API) atau VACUUM INTO, atau command bawaan sejak v1.32.1: docker exec vaultwarden /vaultwarden backup. Image Docker tidak menyertakan binary sqlite3 atau cron, jadi jadwal backup dijalankan di host.

Jangan lupa attachments/ (lampiran di luar database), config.json (token admin & SMTP plaintext), dan rsa_key.* (hilang = semua user login ulang). Backup sebaiknya dienkripsi — misalnya repositori Duplicati — dengan minimal satu salinan off-host. Saat restore, stop container dulu dan hapus file -wal lama.

Keterbatasan yang perlu diperhitungkan

  • Bukan proyek resmi Bitwarden. Dikelola relawan tanpa jadwal rilis; bug tidak bisa dilaporkan ke support Bitwarden.
  • Paritas fitur tidak 100%. Public API baru sebagian (untuk Directory Connector), login passkey masih proses, dan New Device Login Protection, custom roles, serta sebagian policy enterprise belum ada; SSO dan directory sync bukan prioritas.
  • Klien mobile tetap menyentuh cloud Bitwarden. Push FCM/APNs mobile butuh kredensial dari cloud Bitwarden — trade-off bagi yang ingin lepas total.
  • Sensitif terhadap konfigurasi TLS. Self-signed atau chain tak lengkap membuat klien gagal konek; mobile butuh OCSP stapling benar.
  • Satu failure domain. Server down = brankas tak bisa diakses sampai pulih; backup off-host tetap wajib, dan master password yang hilang berarti data tak bisa dibuka siapa pun.

Kesimpulan

Untuk homelab satu mesin yang nyaman dengan ekosistem Bitwarden, Vaultwarden pilihan rasional: kompatibilitas penuh dengan klien resmi, resource kecil, fitur premium tanpa langganan. Komprominya jelas — proyek non-resmi, beberapa fitur belum ada, push mobile menempel ke cloud Bitwarden, dan TLS harus benar. Dengan backup terenkripsi dan salinan off-host, ini fondasi manajemen kredensial yang jujur.

Referensi