โดย Matt Connor 2026-08-04 · อัปเดตเมื่อ 2026-08-13

เปรียบเทียบ Vaultwarden กับ Bitwarden แบบ self-hosted

Q: Vaultwarden ใช้ RAM มากน้อยเพียงใดเมื่อเทียบกับการติดตั้ง Bitwarden ด้วยตนเอง?

จากการวัดผลการติดตั้งในสถานะ idle ด้วย docker stats --no-stream พบว่า Vaultwarden ที่ใช้ SQLite ใช้ RAM ประมาณ 58 MB ในคอนเทนเนอร์เดียว ในขณะที่การติดตั้งมาตรฐานของ Bitwarden ใช้ RAM ใกล้เคียงกับ 2,400 MB กระจายอยู่ใน 12 คอนเทนเนอร์ ซึ่งส่วนใหญ่เป็นภาระจากฐานข้อมูล MSSQL โดย Bitwarden ระบุความต้องการขั้นต่ำไว้ที่ 2 GB และแนะนำที่ 4 GB สำหรับ stack มาตรฐาน ส่วน Bitwarden lite ต้องการ 200 MB ทั้งนี้ Vaultwarden สามารถทำงานบน VPS ขนาด 1 GB ได้โดยยังมีทรัพยากรเหลือเฟือ

Bitwarden ต้องใช้ RAM 2 GB และคอนเทนเนอร์จำนวนมาก แต่ Vaultwarden รันด้วยคอนเทนเนอร์เดียวและใช้ SQLite อ่านรายละเอียดเพื่อตัดสินใจเลือกเซิร์ฟเวอร์ที่เหมาะสมกับ VPS ของคุณ

Vaultwarden และ Bitwarden แบบ self-hosted คืออะไรกันแน่

การเลือกระหว่าง Vaultwarden กับ Bitwarden แบบ self-hosted คือการเลือกระหว่างเซิร์ฟเวอร์สองตัวที่สื่อสารด้วย API ชุดเดียวกัน ไม่ใช่การเลือกระหว่างโปรแกรมจัดการรหัสผ่านสองตัว Stack ของ Bitwarden เองนั้นรันคอนเทนเนอร์ประมาณหนึ่งโหลอยู่เบื้องหลัง nginx โดยจัดเก็บข้อมูลทั้งหมดไว้ใน Microsoft SQL Server และผูกติดกับ installation ID ที่ต้องลงทะเบียนด้วยอีเมล ส่วน Vaultwarden เป็นการนำ Bitwarden client API มาเขียนใหม่โดยไม่เป็นทางการด้วยภาษา Rust ซึ่งรันเป็นคอนเทนเนอร์เดียวโดยใช้ไฟล์ SQLite เพียงไฟล์เดียว ส่วนขยายในเบราว์เซอร์และโทรศัพท์ของคุณไม่สามารถแยกความแตกต่างระหว่างสองตัวนี้ได้ เพราะทั้งคู่ตอบสนองต่อ endpoint เดียวกัน

การเข้ารหัสลับนั้นเหมือนกันทุกประการ ไคลเอนต์ของ Bitwarden จะเข้ารหัสข้อมูลใน vault ก่อนที่ข้อมูลใดๆ จะออกจากอุปกรณ์ ดังนั้นเซิร์ฟเวอร์จึงจัดเก็บเพียงข้อมูลที่อ่านไม่ออก และรูปแบบของ vault ก็เป็นของ Bitwarden ในทั้งสองกรณี สิ่งที่แตกต่างกันคือปริมาณทรัพยากรเครื่องที่คุณต้องเช่า ใครเป็นผู้ดูแลโค้ด ฟีเจอร์ใดบ้างที่ต้องเสียค่าใช้จ่าย และสิ่งที่คุณต้องสำรองข้อมูล

README ของ Vaultwarden ระบุสถานะไว้อย่างชัดเจนว่า: "โครงการนี้ไม่มีส่วนเกี่ยวข้องกับ Bitwarden หรือ Bitwarden, Inc." นี่เป็นโครงการอาสาสมัครที่ไม่มีฝ่ายสนับสนุนและไม่มีการรับประกัน ผู้ดูแลโครงการคนหนึ่งซึ่งทำงานอยู่ที่ Bitwarden ได้เข้ามามีส่วนร่วมในเวลาส่วนตัว ซึ่งถือเป็นความเอื้อเฟื้อมากกว่าการรับรองอย่างเป็นทางการ

ชุดซอฟต์แวร์ทั้ง 3 แบบที่คุณสามารถติดตั้งได้

การเปรียบเทียบส่วนใหญ่มักมองข้ามไปว่า Bitwarden มีผลิตภัณฑ์สำหรับการ self-host สองแบบที่แตกต่างกัน

Bitwarden standard. เป็นการติดตั้งแบบมาตรฐานจากผู้ผลิต ซึ่งขับเคลื่อนด้วย shell script

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

ตัวติดตั้งจะสอบถามโดเมนของคุณ, การขอ certificate จาก Let's Encrypt, ชื่อฐานข้อมูล รวมถึง installation ID และ key ที่คุณต้องขอรับจาก https://bitwarden.com/host โดยการกรอกอีเมล จากนั้น ./bitwarden.sh start จะทำการดึง image และเริ่มการทำงานของ stack ทั้งหมด Bitwarden ระบุความต้องการขั้นต่ำไว้ที่ RAM 2 GB และพื้นที่จัดเก็บข้อมูล 12 GB โดยแนะนำที่ RAM 4 GB และพื้นที่ 25 GB พร้อมด้วย Docker Engine 26 หรือใหม่กว่าที่ติดตั้ง Compose plugin ไว้ ฐานข้อมูลที่ใช้คือ MSSQL Express image ซึ่งรุ่นดังกล่าวจะจำกัดขนาดฐานข้อมูลเชิงสัมพันธ์ไว้ที่ 10 GB เว้นแต่คุณจะกำหนดให้การติดตั้งชี้ไปยังฐานข้อมูลภายนอกแทน

Bitwarden lite. นี่คือรูปแบบการติดตั้งที่เคยถูกเรียกว่า Bitwarden Unified ซึ่งออกจากสถานะเบต้าและเปลี่ยนชื่อในเดือนธันวาคม 2025 ประกอบด้วย container แอปพลิเคชันหนึ่งตัวและฐานข้อมูลที่คุณเลือกเอง:

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 โดยใช้ RAM 200 MB และพื้นที่จัดเก็บข้อมูล 1 GB มีข้อควรระวังสองประการจากเอกสารของ Bitwarden เอง คือระบุไว้สำหรับการใช้งานส่วนบุคคลและ home lab ไม่ใช่สำหรับการใช้งานเชิงธุรกิจ และไม่มีการสำรองข้อมูลฐานข้อมูลอัตโนมัติ ดังนั้นงานส่วนนี้จึงเป็นความรับผิดชอบของคุณทั้งหมด

Vaultwarden. ประกอบด้วยหนึ่ง container ตามที่ระบุไว้ใน 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 ทำการ bind พอร์ต 8000 ไว้กับ loopback เท่านั้น ซึ่งเป็นการตั้งใจออกแบบมาเช่นนั้น Vaultwarden ให้บริการผ่าน plain HTTP และคาดหวังให้มี reverse proxy ทำหน้าที่จัดการ TLS (transport layer security) อยู่เบื้องหน้า การใช้ TLS ในที่นี้ไม่ใช่ทางเลือก: web vault ทำการเข้ารหัสด้วย WebCrypto API ของเบราว์เซอร์ ซึ่งเบราว์เซอร์จะเปิดใช้งานเฉพาะในบริบทที่ปลอดภัยเท่านั้น ดังนั้นหากใช้งานผ่าน http ธรรมดา หน้าล็อกอินจะล้มเหลวในเบราว์เซอร์ก่อนที่จะมีการร้องขอไปยังเซิร์ฟเวอร์ของคุณเสียอีก คำแนะนำการติดตั้ง Vaultwarden ฉบับสมบูรณ์ ครอบคลุมถึงการตั้งค่า proxy และ certificate ไว้แล้ว

Vaultwarden ใช้ RAM เท่าใดเมื่อเทียบกับ Bitwarden แบบ self-hosted?

ข้อกำหนดขั้นต่ำของผู้ผลิตระบุเพียงเงื่อนไขที่ตัวติดตั้งจะยอมทำงาน ไม่ใช่ปริมาณทรัพยากรที่ซอฟต์แวร์ใช้จริง ข้อมูลในตารางด้านล่างมาจาก docker stats --no-stream ในการติดตั้งที่ไม่มีการใช้งาน (idle) โดยมีผู้ใช้หนึ่งราย, vault ขนาดเล็ก และไม่มีไฟล์แนบ บนเครื่อง Ubuntu 24.04 ที่มี RAM 4 GB ส่วนพื้นที่ดิสก์คือขนาดของ image รวมกับไดเรกทอรีข้อมูลหลังจากการเริ่มทำงานครั้งแรกสำเร็จ

ChartIdle memory, container count and disk, measured on one Ubuntu 24.04 box

label

idle_ram_mb

containers

disk_gb

Vaultwarden (SQLite)

0.4

Bitwarden lite + MariaDB

470

1.6

Bitwarden standard (MSSQL)

2,400

6.5

The data behind this chart

[
  {
    "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 ใช้ RAM ขณะ idle อยู่ที่ 58 MB ในคอนเทนเนอร์เดียว ในขณะที่ Bitwarden stack มาตรฐานใช้ RAM ขณะ idle ใกล้เคียงกับ 2,400 MB กระจายอยู่ใน 12 คอนเทนเนอร์ ซึ่งคอนเทนเนอร์ MSSQL เป็นส่วนที่ใช้ทรัพยากรมากที่สุด ส่วน Bitwarden รุ่น lite ใช้ RAM อยู่ที่ 470 MB โดยมีคอนเทนเนอร์ MariaDB เป็นส่วนประกอบ ให้รันคำสั่งเดียวกันบนเครื่องของคุณเองก่อนที่จะเชื่อถือตัวเลขเหล่านี้ เนื่องจากค่าดังกล่าวจะเปลี่ยนแปลงตามจำนวนผู้ใช้, ไฟล์แนบ และปริมาณ traffic ในการ sync อีกทั้ง MSSQL จะขยายขนาดหน่วยความจำที่ใช้งาน (working set) ยิ่งรันต่อเนื่องนานขึ้น

ในทางปฏิบัติสำหรับ VPS ขนาดเล็ก: Vaultwarden ที่ใช้ SQLite สามารถทำงานได้อย่างราบรื่นบนแผน 1 GB ในขณะที่ Bitwarden stack มาตรฐานจะไม่สามารถเริ่มทำงานได้บนแผนดังกล่าว สำหรับแผน 2 GB นั้น stack มาตรฐานจะผ่านเกณฑ์ขั้นต่ำตามเอกสาร แต่จะเหลือทรัพยากรให้ระบบปฏิบัติการน้อยมาก จนอาจเกิดเหตุการณ์ที่ kernel out of memory killer เข้ามาจัดการ process ได้ เมื่อเหตุการณ์นั้นเกิดขึ้น dmesg จะแสดงบรรทัดที่ระบุชื่อ process ที่ถูกสั่งยุติการทำงาน ซึ่งใน stack นี้มักจะเป็น sqlservr ดังนั้นควรจัดสรร RAM ให้กับการติดตั้งแบบมาตรฐานที่ 4 GB

ฟีเจอร์แบบเสียเงินใดบ้างที่ใช้งานได้ฟรีใน Vaultwarden?

การรันเซิร์ฟเวอร์ Bitwarden นั้นไม่มีค่าใช้จ่าย แต่ฟีเจอร์แบบเสียเงินจะถูกล็อกไว้จนกว่าคุณจะอัปโหลดไฟล์ใบอนุญาต (licence file) บัญชีผู้ใช้ส่วนบุคคลแบบ Premium และทุกระดับขององค์กรแบบเสียเงิน (Families, Teams, Enterprise) จำเป็นต้องใช้ใบอนุญาตดังกล่าว คุณสามารถดาวน์โหลดได้จาก cloud web vault ในส่วน Settings แล้วไปที่ Subscription สำหรับบัญชีส่วนบุคคล หรือใน Admin Console ที่ส่วน Billing แล้วไปที่ Subscription สำหรับองค์กร จากนั้นจึงอัปโหลดไปยัง instance ของคุณ ใบอนุญาตขององค์กรจะถูกออกให้โดยอ้างอิงจาก installation ID ที่เก็บไว้ใน ./bwdata/env/global.override.env ดังนั้นองค์กรที่โฮสต์เอง (self-hosted) จึงยังคงต้องมีสถานะการสมัครสมาชิกแบบเสียเงินและยังคงต้องเชื่อมต่อกับระบบคลาวด์ของ Bitwarden เพื่อการเรียกเก็บเงิน

Vaultwarden จะเปิดใช้งานฟีเจอร์เดียวกันทั้งหมดโดยไม่ต้องใช้ใบอนุญาตและไม่ต้องสมัครสมาชิก โดยวิกิของโปรเจกต์ได้ระบุรายการไว้ดังนี้:

องค์กร (organisations), คอลเลกชัน (collections) และกลุ่ม (groups)
ไฟล์แนบ (file attachments)
การล็อกอินสองชั้น (two-step login) ด้วยอีเมล, Duo, YubiKey และ FIDO2
การเข้าถึงฉุกเฉิน (Emergency Access)
Bitwarden Send
API keys ส่วนบุคคล
SSO ผ่าน OpenID Connect

SSO เป็นฟีเจอร์ใหม่ล่าสุดในกลุ่มนี้และกำหนดค่าได้ด้วย SSO_ENABLED, SSO_AUTHORITY, SSO_CLIENT_ID และ SSO_CLIENT_SECRET โดยฟีเจอร์นี้จะทำหน้าที่ยืนยันตัวตนสำหรับการล็อกอินเท่านั้น วิกิระบุไว้อย่างชัดเจนว่ายังคงต้องใช้ master password และรหัสผ่านนี้จะไม่ถูกควบคุมโดย identity provider ของคุณ เนื่องจากรหัสผ่านดังกล่าวถูกนำไปใช้สร้างคีย์สำหรับถอดรหัส vault ให้ชี้ SSO_AUTHORITY ไปยัง discovery issuer ของ ผู้ให้บริการยืนยันตัวตน Authentik ที่โฮสต์เอง เพื่อให้ผู้ใช้ล็อกอินผ่านช่องทางนั้น จากนั้นจึงปลดล็อกด้วย master password ค่าที่ระบุต้องตรงกับฟิลด์ issuer ที่ discovery endpoint ส่งกลับมา โดยไม่ต้องใส่ส่วนต่อท้าย /.well-known/openid-configuration ไว้ที่ท้ายสุด

สิ่งที่คุณจะไม่ได้รับจาก Vaultwarden คือผู้ให้บริการ (vendor) อย่างเป็นทางการ Bitwarden ได้รับการรับรองมาตรฐาน SOC 2 Type 2 และ ISO 27001 มีการเผยแพร่รายงานการตรวจสอบจากบุคคลที่สาม และมีการรันโปรแกรม bug bounty บน HackerOne ซึ่งการรับรองเหล่านี้ครอบคลุมถึงโค้ดและบริการของ Bitwarden ไม่ใช่เซิร์ฟเวอร์ที่คุณติดตั้งเอง ดังนั้นหากผู้ตรวจสอบต้องการชื่อซัพพลายเออร์ที่รับผิดชอบเบื้องหลังโปรแกรมจัดการรหัสผ่านของคุณ การใช้ซอฟต์แวร์ที่พัฒนาโดยอาสาสมัครอาจเป็นประเด็นที่อธิบายได้ยากในการสนทนาทางธุรกิจ

แอปอย่างเป็นทางการของ Bitwarden ใช้งานร่วมกับ Vaultwarden ได้หรือไม่

ได้ Vaultwarden มีการใช้งาน client API ตามมาตรฐาน ดังนั้นส่วนขยายเบราว์เซอร์, แอปเดสก์ท็อป, แอปมือถือ และ web vault ที่มาพร้อมกับระบบจึงสามารถใช้งานร่วมกันได้ทั้งหมด ในแต่ละไคลเอนต์ คุณต้องตั้งค่า URL ของเซิร์ฟเวอร์ที่โฮสต์เองในหน้าจอตั้งค่าสภาพแวดล้อมก่อนทำการล็อกอิน ไม่ใช่หลังจากล็อกอินแล้ว

มีฟีเจอร์หนึ่งที่ต้องมีการตั้งค่าเพิ่มเติม คือการแจ้งเตือนแบบ push ไปยังแอปมือถือ หากไม่มีฟีเจอร์นี้ แอปจะทำการซิงค์ข้อมูลเมื่อคุณเปิดแอปหรือตามรอบเวลาที่กำหนดไว้ ดังนั้นรหัสผ่านที่เปลี่ยนบนแล็ปท็อปของคุณจะไม่ปรากฏบนโทรศัพท์จนกว่าคุณจะเปิดแอปขึ้นมาดู Vaultwarden สามารถใช้บริการ push relay ของ Bitwarden ได้ โดยจำเป็นต้องใช้ installation ID และ key จากหน้า https://bitwarden.com/host เดียวกันกับที่ตัวติดตั้งอย่างเป็นทางการใช้งาน

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

เซิร์ฟเวอร์ในภูมิภาค EU จำเป็นต้องใช้ PUSH_RELAY_URI=https://api.bitwarden.eu และ PUSH_IDENTITY_URI=https://identity.bitwarden.eu ด้วยเช่นกัน ในวิกิมีเอกสารระบุถึงข้อควรระวังสองประการที่คุณควรรู้ก่อนจะเสียเวลาแก้ไขปัญหาเป็นชั่วโมง แอปที่ติดตั้งจาก F-Droid หรือ Neo Store จะไม่มีการรองรับ Firebase และจะไม่ได้รับ push notification ไม่ว่าเซิร์ฟเวอร์จะตั้งค่าไว้อย่างไรก็ตาม สำหรับแอปที่เคยเชื่อมต่อก่อนเวอร์ชัน Vaultwarden 1.30.2 จำเป็นต้องล้างข้อมูลแอปเพื่อให้มีการลงทะเบียน push token ใหม่อีกครั้ง

การนำไปเขียนใหม่ (reimplementation) มีความปลอดภัยเพียงใด?

ประวัติการตรวจสอบของ Bitwarden นั้นยาวนานและเปิดเผยต่อสาธารณะ Cure53 ได้ตรวจสอบซอฟต์แวร์ในปี 2018, 2021, 2022 และ 2023 ส่วน IOActive และ Mandiant ได้ตรวจสอบไคลเอนต์ในปี 2024 ทาง Fracture Labs ได้ทำการประเมินเว็บและเครือข่ายตลอดปี 2024 และ 2025 ทาง Unit 42 ได้ประเมินแอปมือถือในปี 2025 และกลุ่ม Applied Cryptography Group แห่ง ETH Zurich ได้ตรวจสอบระบบการเข้ารหัสในปี 2025

Vaultwarden เองก็ได้รับการตรวจสอบจากบุคคลภายนอกเช่นกัน ซึ่งสร้างความประหลาดใจให้กับผู้ที่เข้าใจว่าไม่มีใครตรวจสอบซอฟต์แวร์นี้ สำนักงานความมั่นคงปลอดภัยสารสนเทศแห่งสหพันธ์สาธารณรัฐเยอรมนี (BSI) ได้ให้บริษัท mgm security partners ทำการทดสอบระหว่างเดือนกุมภาพันธ์ถึงพฤษภาคม 2024 ภายใต้โครงการวิเคราะห์โค้ด Caos 3.0 ซึ่งการตรวจสอบดังกล่าวจัดระดับความสำคัญของช่องโหว่ที่พบไว้ที่ระดับสูงจำนวน 2 รายการ นอกจากนี้ ERNW ยังได้รายงานช่องโหว่การข้ามผ่านการยืนยันตัวตน (authentication bypass) ซึ่งส่งผลกระทบต่อเวอร์ชันที่ต่ำกว่า 1.32.5 (CVE-2024-55225) โดยได้รับการแก้ไขในเดือนพฤศจิกายน 2024 ส่วนเวอร์ชัน 1.37.0 ในเดือนกรกฎาคม 2026 ได้มีการแก้ไขช่องโหว่ SSRF (server side request forgery) ผ่านทาง icon endpoint, การเข้าถึง cipher ข้ามองค์กร และการข้ามผ่านนโยบายองค์กรในการนำเข้า directory

ประวัติเหล่านี้แสดงให้เห็นถึงโครงการที่มีกระบวนการเปิดเผยช่องโหว่ที่ใช้งานได้จริง และยังชี้ให้เห็นถึงจุดเสี่ยงที่มักปรากฏขึ้นซ้ำๆ นั่นคือหน้า admin ดังนั้นควรปฏิบัติต่อหน้าดังกล่าวเสมือนเป็นส่วนที่มีความสำคัญสูง โดยควรปิดการใช้งานไว้เว้นแต่จะมีการตั้งค่า ADMIN_TOKEN และคุณควรจัดเก็บค่า hash แทนที่จะเป็นโทเค็นแบบข้อความธรรมดา (plaintext)

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

คำสั่งดังกล่าวจะแสดงผลลัพธ์เป็นสตริง Argon2 PHC (รูปแบบการแข่งขันการทำ password hashing) เพื่อนำไปวางใน ADMIN_TOKEN โปรดเปิดใช้งาน HTTPS ก่อนเปิดใช้งานหน้า admin เนื่องจากโทเค็นจะถูกส่งไปพร้อมกับคำขอ และหากโทเค็นอยู่ในรูปแบบข้อความธรรมดาบนการเชื่อมต่อ HTTP ปกติ ข้อมูลดังกล่าวจะสามารถถูกอ่านได้โดยทุกจุดที่อยู่บนเส้นทางเครือข่าย ควรเก็บ /admin ให้ห่างจากอินเทอร์เน็ตสาธารณะหากทำได้ และใช้งานควบคู่ไปกับการเพิ่มความปลอดภัยให้กับโฮสต์ตามปกติ เช่น การจำกัดการเข้าถึง SSH บนเซิร์ฟเวอร์

สิ่งที่เสียหายเมื่อ API อย่างเป็นทางการมีการเปลี่ยนแปลง

นี่คือความเสี่ยงที่ผู้คนมักประเมินต่ำเกินไป Bitwarden ปล่อยตัวไคลเอนต์ออกมา และไคลเอนต์เหล่านั้นจะอัปเดตตัวเองจาก app store ในช่วงข้ามคืน Vaultwarden จำเป็นต้องปรับตัวตาม เมื่อไคลเอนต์รุ่นใหม่เปลี่ยนสัญญา API (API contract) Vaultwarden ที่ยังไม่ได้อัปเกรดจะพบกับไคลเอนต์ที่เปลี่ยนไปแล้ว ส่งผลให้การเข้าสู่ระบบหรือการซิงค์ข้อมูลล้มเหลวบนอุปกรณ์ที่คุณไม่ได้เข้าไปแตะต้องเลย

บันทึกประจำรุ่น (release notes) มีตัวอย่างที่ชัดเจน Vaultwarden 1.37.0 ระบุว่า: "การอัปเดตนี้จำเป็นสำหรับการรองรับไคลเอนต์เวอร์ชัน 2026.7.0 ขึ้นไป โปรดอัปเดตก่อนรายงานปัญหาใดๆ ที่เกี่ยวข้อง" ณ เดือนสิงหาคม 2026 รุ่นปัจจุบันคือ 1.37.1 ซึ่งเผยแพร่เมื่อวันที่ 29 กรกฎาคม 2026

นิสัยสองอย่างจะช่วยให้เรื่องนี้ไม่กลายเป็นปัญหาใหญ่ ประการแรก ให้ระบุ image tag ที่เฉพาะเจาะจงแทนการใช้ latest เพื่อป้องกันไม่ให้การดึงอิมเมจแบบอัตโนมัติ (unattended pull) เปลี่ยนแปลงเซิร์ฟเวอร์ของคุณตอนตี 3 ประการที่สอง ให้ติดตามฟีดการปล่อยรุ่นและอัปเกรดอย่างตั้งใจ โดยอ่านบันทึกก่อนเสมอ เพราะการเปลี่ยนแปลงที่ส่งผลกระทบ (breaking changes) จะปรากฏอยู่ที่นั่นที่เดียวเท่านั้น ตัวอย่างเช่น เวอร์ชัน 1.35.5 ทำให้โทเค็นการจดจำปัจจัยที่สอง (two factor remember token) ทั้งหมดที่มีอยู่ใช้งานไม่ได้หลังการอัปเกรด ซึ่งส่งผลให้ผู้ใช้ถูกออกจากระบบในขั้นตอนที่พวกเขาคิดว่าบันทึกไว้แล้ว

การติดตั้ง Bitwarden แบบมาตรฐานก็ประสบปัญหาในลักษณะเดียวกัน การอัปเกรดจะดำเนินการผ่าน ./bitwarden.sh updateself และ ./bitwarden.sh update และการอัปเดตจะทำการย้ายข้อมูลในฐานข้อมูล (database migration) การสำรองข้อมูลที่ทำไว้ก่อนการย้ายข้อมูลไม่สามารถใช้เป็นตัวย้อนกลับ (rollback) สำหรับโครงสร้างฐานข้อมูลหลังจากนั้นได้ ดังนั้นควรสำรองข้อมูลและจดบันทึกเวอร์ชันที่คุณใช้สำรองข้อมูลไว้ด้วย

การสำรองข้อมูล ซึ่งเป็นจุดที่ผู้ใช้งานมักทำข้อมูล Vault สูญหาย

ไดเรกทอรีข้อมูลของ Vaultwarden คือตัวเซิร์ฟเวอร์ทั้งหมด คุณต้องเก็บรักษาข้อมูลต่อไปนี้:

db.sqlite3
ไฟล์ rsa_key* ทุกไฟล์ รวมถึง rsa_key.pem และ rsa_key.der
attachments/
config.json
sends/

ห้ามคัดลอก db.sqlite3 ด้วย cp ในขณะที่คอนเทนเนอร์กำลังทำงานอยู่ เนื่องจาก SQLite อาจอยู่ในระหว่างการเขียนข้อมูล ซึ่งอาจทำให้ไฟล์ที่คัดลอกมาเป็นฐานข้อมูลที่เสียหายโดยดูภายนอกเหมือนปกติจนกว่าคุณจะนำไปกู้คืน ให้ใช้ API สำหรับการสำรองข้อมูลแบบออนไลน์แทน:

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

ตั้งแต่เวอร์ชัน 1.32.1 เป็นต้นมา ภายในอิมเมจยังมีคำสั่ง /vaultwarden backup มาให้ด้วย ไม่ว่าจะใช้วิธีใด สแนปชอตจะยังคงอยู่ในดิสก์ลูกเดียวกับข้อมูลต้นฉบับจนกว่าคุณจะย้ายมันออกไป ดังนั้นควรส่งข้อมูลออกไปนอกเครื่องด้วย การสำรองข้อมูลด้วย restic ไปยังที่จัดเก็บภายนอก ตามตารางเวลาที่กำหนด ไฟล์ rsa_key มีความสำคัญไม่น้อยไปกว่าฐานข้อมูล เนื่องจากเซิร์ฟเวอร์ใช้คีย์นี้ในการลงนาม session token ดังนั้นหากกู้คืนฐานข้อมูลโดยใช้คีย์ที่สร้างขึ้นใหม่ จะทำให้ผู้ใช้ทุกคนถูกออกจากระบบและคำเชิญเข้าองค์กรที่ค้างอยู่จะใช้งานไม่ได้

Bitwarden รุ่นมาตรฐานมีการสำรองข้อมูลตัวเองมากกว่า คอนเทนเนอร์ mssql จะเขียนไฟล์สำรองฐานข้อมูลรายคืนลงใน ./bwdata/mssql/backups และเก็บไว้เป็นเวลา 30 วัน ตราบเท่าที่คอนเทนเนอร์ยังทำงานอยู่ และคุณสามารถสั่งให้สำรองข้อมูลทันทีได้ด้วยคำสั่ง:

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

ไดเรกทอรีที่ต้องเก็บรักษาคือ ./bwdata/env (ตัวแปรสภาพแวดล้อม รวมถึงรหัสผ่านฐานข้อมูลและใบรับรอง), ./bwdata/core/attachments, ./bwdata/mssql/data และ ./bwdata/core/aspnet-dataprotection ไดเรกทอรีสุดท้ายนี้คือสิ่งที่ผู้คนมักลืม มันเก็บข้อมูลการป้องกันระดับเฟรมเวิร์ก รวมถึงโทเค็นการยืนยันตัวตนและคอลัมน์บางส่วนของฐานข้อมูล ดังนั้นการกู้คืนฐานข้อมูลโดยไม่มีไดเรกทอรีนี้จะทำให้คอลัมน์ที่ถูกป้องกันไว้ไม่สามารถอ่านได้ สำหรับ Bitwarden รุ่น lite จะไม่มีการสำรองข้อมูลอัตโนมัติเลย ดังนั้นการเลือกใช้รุ่น lite หมายความว่าคุณต้องรับผิดชอบการกำหนดตารางเวลาสำรองข้อมูลด้วยตนเองเช่นเดียวกับ Vaultwarden

การย้ายข้อมูลในทุกทิศทาง

การย้ายข้อมูลจะดำเนินการผ่านฝั่งไคลเอนต์ ไม่ใช่ฝั่งเซิร์ฟเวอร์ เนื่องจากฟังก์ชันการส่งออก (export) และการนำเข้า (import) เป็นคุณสมบัติของไคลเอนต์ ทำให้ขั้นตอนการย้ายข้อมูลในทุกทิศทางมีลักษณะเหมือนกัน

ผู้ใช้แต่ละรายต้องทำการส่งออกข้อมูลจาก web vault หรือแอปเดสก์ท็อป สร้างบัญชีใหม่บนเซิร์ฟเวอร์ปลายทาง แล้วจึงนำเข้าข้อมูล รูปแบบไฟล์ที่รองรับได้แก่ plaintext .json, plaintext .csv, encrypted .json และ .zip ซึ่งเก็บข้อมูล JSON พร้อมไฟล์แนบสำหรับ vault แต่ละรายการ ข้อมูลประเภทบัตร, ข้อมูลระบุตัวตน, passkeys ที่บันทึกไว้ และ SSH keys จะคงอยู่เฉพาะในรูปแบบ JSON เท่านั้น ดังนั้นการย้ายข้อมูลด้วย CSV จะทำให้ข้อมูลเหล่านี้สูญหายโดยไม่มีการแจ้งเตือน รูปแบบการส่งออกไม่มีรูปแบบใดที่รวมรายการในถังขยะหรือ Sends ไว้ และข้อมูลที่อยู่ภายใต้การดูแลขององค์กรจะไม่ถูกรวมอยู่ในการส่งออกข้อมูลส่วนบุคคล

ให้ถือว่าไฟล์ส่งออกที่เป็น plaintext เป็นความลับที่ใช้งานได้จริง เพราะนั่นคือสิ่งที่มันเป็น นั่นคือ vault ทั้งหมดของคุณที่อยู่ในรูปแบบข้อความธรรมดาบนดิสก์ ให้ดำเนินการส่งออก นำเข้า และลบไฟล์ทิ้งในคราวเดียว ห้ามส่งไฟล์นี้ผ่านอีเมลหรือแชทโดยเด็ดขาด

มีกับดักหนึ่งที่มักพบระหว่างการย้ายข้อมูล คือการส่งออกข้อมูลแบบเข้ารหัสที่ผูกกับบัญชีเดิมจะไม่สามารถนำเข้าสู่บัญชีอื่นได้ และการย้ายเซิร์ฟเวอร์โดยนิยามแล้วหมายถึงการใช้บัญชีใหม่ ดังนั้นให้เลือกตัวเลือกการส่งออกที่ป้องกันด้วยรหัสผ่าน (password protected export) แทน ซึ่งสามารถนำไปใช้งานต่อได้

การย้ายจาก Vaultwarden ไปยัง Bitwarden มาตรฐานเป็นทิศทางที่ยากกว่า เนื่องจากโครงสร้างองค์กรไม่สามารถย้ายไปพร้อมกับการส่งออกข้อมูลได้ คุณต้องสร้างองค์กรใหม่บนเซิร์ฟเวอร์ปลายทาง เชิญผู้ใช้อีกครั้ง และให้ผู้ใช้แต่ละรายนำเข้า vault ของตนเอง ควรวางแผนช่วงเวลาบำรุงรักษาสำหรับงานนี้แทนที่จะไปพบปัญหาในวันใช้งานจริง

คุณควรเลือกใช้งานตัวไหน?

ให้เลือกใช้ Vaultwarden หากคุณใช้งานคนเดียว เป็นครอบครัว หรือทำโฮมแล็บบน VPS ขนาด 1 GB หรือ 2 GB ฟีเจอร์ Organisations, Emergency Access และ Send นั้นใช้งานได้ฟรี การใช้หน่วยความจำขณะไม่ได้ใช้งานมีปริมาณพอๆ กับแท็บเบราว์เซอร์หนึ่งแท็บ และการสำรองข้อมูลทำได้ง่ายเพียงแค่คัดลอกไฟล์ SQLite และไดเรกทอรีขนาดเล็ก ด้วยเหตุนี้ Vaultwarden จึงเป็นตัวเลือกหลักสำหรับการจัดการรหัสผ่านแบบ self-hosted

ให้เลือกใช้เซิร์ฟเวอร์ของ Bitwarden เองเมื่อมีผู้อื่นต้องใช้งานในเชิงธุรกิจ เช่น บริษัทที่ต้องการสัญญาการสนับสนุน (support contract), ข้อกำหนดด้านการปฏิบัติตามกฎระเบียบ (compliance) ที่ระบุชื่อผู้ให้บริการ หรือฟีเจอร์ระดับองค์กรที่คุณจ่ายเงินซื้ออยู่แล้ว สำหรับการติดตั้งแบบมาตรฐานควรจัดสรรหน่วยความจำให้ 4 GB และให้ถือว่าไฟล์ใบอนุญาต (licence file) และ installation ID เป็นส่วนหนึ่งของการติดตั้ง ไม่ใช่แค่เอกสารประกอบ

Bitwarden lite อยู่ในจุดกึ่งกลางที่ค่อนข้างลำบาก มันเป็นโค้ดจากผู้ให้บริการโดยตรงที่มีขนาดเบากว่ามาก ซึ่งถือว่าน่าสนใจ แต่ Bitwarden ระบุไว้ว่าเหมาะสำหรับการใช้งานส่วนตัวหรือโฮมแล็บเท่านั้นและไม่มีระบบสำรองข้อมูลอัตโนมัติ คุณจะต้องรับภาระในการดูแลระบบในระดับเดียวกับ Vaultwarden โดยที่ไม่ได้รับฟีเจอร์ฟรีเหมือนกับ Vaultwarden ให้เลือกใช้ตัวนี้ก็ต่อเมื่อคุณให้ความสำคัญกับโค้ดจากผู้ให้บริการมากกว่าฟีเจอร์ และคุณยินดีที่จะดูแลจัดการฐานข้อมูลด้วยตนเอง

หากคุณยังตัดสินใจไม่ได้ว่าจะติดตั้งบริการอื่นใดบนเซิร์ฟเวอร์นี้ รายการบริการ self-hosting ที่แนะนำ จะช่วยให้คุณเปรียบเทียบตัวเลือกนี้กับบริการอื่นๆ ที่ต้องใช้หน่วยความจำในระดับเดียวกันได้

FAQ

Vaultwarden ปลอดภัยเพียงพอสำหรับการเป็นโปรแกรมจัดการรหัสผ่านจริงหรือไม่?

สำหรับการใช้งานส่วนตัวและในครอบครัว ถือว่าเพียงพอหากปฏิบัติตามเงื่อนไขที่กำหนด ตัวแอปพลิเคชันฝั่งไคลเอนต์จะเข้ารหัสข้อมูลใน vault ก่อนส่งถึงเซิร์ฟเวอร์ ดังนั้น Vaultwarden จะไม่เห็นรหัสผ่านหลัก (master password) หรือข้อมูลใดๆ ในรูปแบบข้อความปกติ (plaintext) ซอฟต์แวร์นี้ผ่านการตรวจสอบจากภายนอกมาแล้ว โดย BSI ได้ให้ mgm security partners ทำการทดสอบระหว่างเดือนกุมภาพันธ์ถึงพฤษภาคม 2024 และ ERNW ได้รายงานช่องโหว่การข้ามผ่านการยืนยันตัวตนซึ่งได้รับการแก้ไขแล้วในเวอร์ชัน 1.32.5 ผู้ใช้งานควรหมั่นอัปเดตเวอร์ชันให้เป็นปัจจุบัน ปิดใช้งานหน้า admin หรือจำกัดการเข้าถึงด้วย Argon2 hashed ADMIN_TOKEN และให้บริการผ่าน HTTPS เท่านั้น สำหรับองค์กรที่ต้องการการสนับสนุนจากผู้จำหน่ายหรือเอกสารสำหรับการตรวจสอบ (audit) ควรใช้งานเซิร์ฟเวอร์ของ Bitwarden โดยตรง

Vaultwarden ใช้ RAM มากน้อยเพียงใดเมื่อเทียบกับการติดตั้ง Bitwarden ด้วยตนเอง?

จากการวัดผลการติดตั้งในสถานะ idle ด้วย docker stats --no-stream พบว่า Vaultwarden ที่ใช้ SQLite ใช้ RAM ประมาณ 58 MB ในคอนเทนเนอร์เดียว ในขณะที่การติดตั้งมาตรฐานของ Bitwarden ใช้ RAM ใกล้เคียงกับ 2,400 MB กระจายอยู่ใน 12 คอนเทนเนอร์ ซึ่งส่วนใหญ่เป็นภาระจากฐานข้อมูล MSSQL โดย Bitwarden ระบุความต้องการขั้นต่ำไว้ที่ 2 GB และแนะนำที่ 4 GB สำหรับ stack มาตรฐาน ส่วน Bitwarden lite ต้องการ 200 MB ทั้งนี้ Vaultwarden สามารถทำงานบน VPS ขนาด 1 GB ได้โดยยังมีทรัพยากรเหลือเฟือ

ฉันจำเป็นต้องมีไลเซนส์ Bitwarden เพื่อติดตั้งใช้งานเองหรือไม่?

ไม่จำเป็นสำหรับการใช้งาน vault ส่วนบุคคลแบบฟรี การรันเซิร์ฟเวอร์นั้นไม่มีค่าใช้จ่าย จำเป็นต้องใช้ไฟล์ไลเซนส์ก็ต่อเมื่อต้องการปลดล็อกฟีเจอร์ระดับพรีเมียมสำหรับบุคคลทั่วไป หรือแผนองค์กรแบบชำระเงิน ซึ่งครอบคลุมถึงแผน Families, Teams และ Enterprise คุณสามารถดาวน์โหลดไฟล์ไลเซนส์จาก cloud web vault แล้วอัปโหลดไปยัง instance ของคุณได้ สำหรับไลเซนส์องค์กรจะถูกออกให้โดยอ้างอิงจาก installation ID ที่เก็บไว้ใน ./bwdata/env/global.override.env ส่วน Vaultwarden ไม่ต้องการไลเซนส์และสามารถเปิดใช้งานฟีเจอร์ระดับองค์กรได้ด้วยตัวเอง

ฉันสามารถย้ายจาก Vaultwarden ไปยัง Bitwarden หรือย้ายกลับในภายหลังได้หรือไม่?

ได้ ทั้งสองทิศทางผ่านทางแอปพลิเคชันไคลเอนต์ ผู้ใช้แต่ละคนสามารถส่งออก (export) ข้อมูล vault จาก web vault หรือแอปเดสก์ท็อป แล้วนำเข้า (import) ไปยังเซิร์ฟเวอร์ใหม่หลังจากสร้างบัญชีที่นั่น การส่งออกด้วยรูปแบบ .zip จะรวมไฟล์แนบสำหรับ vault ส่วนบุคคล และรูปแบบ JSON จะรวมข้อมูลบัตร, ข้อมูลประจำตัว, passkeys และ SSH keys อย่างไรก็ตาม รายการในถังขยะและข้อมูลใน Sends จะไม่อยู่ในรูปแบบการส่งออกใดๆ และรายการที่เป็นขององค์กรจะต้องถูกส่งออกแยกต่างหากโดยเจ้าของ ดังนั้นควรวางแผนสร้างองค์กรใหม่และเชิญผู้ใช้อีกครั้งบนเซิร์ฟเวอร์ใหม่

#vaultwarden#bitwarden#password-manager#self-hosting #docker