เปรียบเทียบโปรแกรมแชทองค์กรแบบ Self-hosted ตัวไหนดี

ทางเลือกสำหรับ Slack แบบ self-hosted ที่คุณควรใช้งาน

ทางเลือกสำหรับ Slack แบบ self-hosted ที่คุ้มค่าต่อเวลาของทีมขนาดเล็ก ได้แก่ Mattermost, Rocket.Chat, Matrix ร่วมกับ Synapse และ Zulip หากต้องการเครื่องมือภายในทีมบนเซิร์ฟเวอร์เดียว ให้เลือกใช้ Mattermost หากเป็นชุมชนสาธารณะ ให้เลือกใช้ Zulip ส่วน Matrix ร่วมกับ Synapse ควรใช้เมื่อคุณจำเป็นต้องสื่อสารกับเซิร์ฟเวอร์ที่ผู้อื่นเป็นเจ้าของเท่านั้น เนื่องจากระบบสหพันธ์ (federation) เป็นสิ่งที่ตัวเลือกอื่นไม่สามารถเลียนแบบได้ และเป็นสิ่งที่เปลี่ยนลักษณะงานของคุณในฐานะผู้ดูแลระบบ

รายการฟีเจอร์ไม่สามารถใช้แยกความแตกต่างของทั้งสี่ตัวนี้ได้ เนื่องจากทั้งหมดรองรับช่องทางสนทนา (channels), กระทู้ (threads), การค้นหา, การอัปโหลดไฟล์ และแอปพลิเคชันบนมือถือ สิ่งที่แยกความแตกต่างคือภาระที่คุณต้องแบกรับในแต่ละเดือน ได้แก่ การใช้หน่วยความจำ, ฐานข้อมูลที่คุณต้องดูแลให้ทำงานอยู่เสมอ, เส้นทางการแจ้งเตือนบนมือถือ (mobile push path) ที่คุณอาจควบคุมไม่ได้ และใบอนุญาตที่กำหนดว่าฟีเจอร์ที่คุณต้องการนั้นต้องเสียค่าใช้จ่ายหรือไม่ การเปรียบเทียบด้านล่างนี้อ้างอิงตามปัจจัยดังกล่าว โดยคำนวณที่จำนวนผู้ใช้งาน 10 คน และ 100 คน

นิยามของทั้งสี่ระบบ

Mattermost คือเซิร์ฟเวอร์ที่เขียนด้วยภาษา Go ทำงานร่วมกับฐานข้อมูล PostgreSQL ประกอบด้วยไฟล์ binary หนึ่งไฟล์ ฐานข้อมูลหนึ่งชุด และไฟล์ตั้งค่าหนึ่งไฟล์ มีการทำงานคล้ายกับ Slack รวมถึงรองรับการสนทนาแบบ thread และ slash commands ถือเป็นระบบที่ดูแลรักษาง่ายที่สุดในบรรดาทั้งสี่ตัว ซึ่งนับเป็นข้อดี

Rocket.Chat คือแอปพลิเคชัน Node.js ที่ทำงานบน MongoDB มีชุดฟีเจอร์ที่กว้างขวางที่สุดในกลุ่มนี้ รวมถึงการโทรด้วยเสียงและวิดีโอ และกล่องข้อความรวม (omnichannel inbox) ที่ดึงบทสนทนาจากอีเมลและช่องทางโซเชียลมีเดียต่างๆ เข้ามาอยู่ในอินเทอร์เฟซเดียวกัน หากกล่องข้อความรวมนี้คือเหตุผลที่คุณกำลังมองหาโซลูชันนี้ โปรดพิจารณาเปรียบเทียบกับ ระบบสนับสนุน Chatwoot ก่อน เนื่องจากเซิร์ฟเวอร์แชทที่เน้นงานสนับสนุนลูกค้ามีลักษณะการทำงานที่แตกต่างจากเซิร์ฟเวอร์แชทที่เน้นการทำงานภายในทีม

Matrix เป็นโปรโตคอล ไม่ใช่ผลิตภัณฑ์ โดยมี Synapse เป็นเซิร์ฟเวอร์อ้างอิง (เขียนด้วย Python และใช้ PostgreSQL) และ Element เป็นไคลเอนต์ที่คนส่วนใหญ่นิยมใช้ นี่เป็นตัวเลือกเดียวในกลุ่มนี้ที่เซิร์ฟเวอร์ของคุณสามารถสื่อสารกับเซิร์ฟเวอร์อื่นที่คุณไม่ได้เป็นผู้ดูแลเองได้

Zulip คือเซิร์ฟเวอร์ Python (ใช้ Django ร่วมกับ Tornado) โดยมี PostgreSQL, RabbitMQ, memcached และ Redis ทำงานอยู่เบื้องหลัง ติดตั้งเป็นหน่วยเดียวผ่านสคริปต์เฉพาะของระบบ รูปแบบการทำงานเน้นการแบ่งหัวข้อ (topics) ภายในช่องทาง (channels) ทำให้บทสนทนาจากวันอังคารยังคงสามารถค้นหาได้ในวันศุกร์ โดยเวอร์ชัน 12.0 ได้เปิดตัวในเดือนเมษายน 2026

ปริมาณ RAM และฐานข้อมูลที่แนะนำสำหรับผู้ใช้ 10 รายและ 100 ราย

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

[
  {
    "label": "Synapse",
    "published_ram_gb": 1,
    "notes": "Synapse install docs: at least 1 GB free RAM if you want to join large public rooms. PostgreSQL is required for production and is not sized."
  },
  {
    "label": "Mattermost",
    "published_ram_gb": 2,
    "notes": "Mattermost requirements: 1 to 1,000 users on 1 vCPU and 2 GB RAM, single server, database included."
  },
  {
    "label": "Zulip",
    "published_ram_gb": 2,
    "notes": "Zulip requirements: under 100 users on 1 CPU, 2 GB RAM and 2 GB swap. 100 users and above needs 2 CPUs and 4 GB."
  },
  {
    "label": "Rocket.Chat",
    "published_ram_gb": 8,
    "notes": "Rocket.Chat requirements: smallest published tier is 4 GiB for the app plus 4 GiB for MongoDB, rated up to 500 concurrent users."
  }
]

รูปแบบของแต่ละแถวไม่เหมือนกัน ซึ่งเป็นข้อค้นพบที่มีประโยชน์ประการแรก ค่า 1 GB ของ Synapse เป็นค่าขั้นต่ำสำหรับกระบวนการ Synapse โดยมีเงื่อนไขกำกับว่าเอกสารระบุให้มี RAM ว่าง อย่างน้อยเท่าจำนวนดังกล่าวหากต้องการเข้าร่วมห้องสาธารณะขนาดใหญ่ ส่วน PostgreSQL นั้นอยู่นอกเหนือจากตัวเลขนี้ ค่า 2 GB ของ Mattermost คือขนาดของเครื่องทั้งหมดรวมฐานข้อมูลแล้ว ซึ่งรองรับผู้ใช้ตั้งแต่ 1 ถึง 1,000 รายบน vCPU เดียว Zulip ระบุไว้ที่ 2 GB และ CPU หนึ่งตัวสำหรับผู้ใช้ต่ำกว่า 100 ราย พร้อม swap อีก 2 GB จากนั้นจะเพิ่มเป็น 4 GB และ CPU สองตัวสำหรับผู้ใช้ตั้งแต่ 100 รายขึ้นไป Rocket.Chat ระบุตัวเลขที่สูงที่สุดในที่นี้คือ 8 GB เนื่องจากมีการจัดสรรขนาดแอปพลิเคชันไว้ที่ 4 GiB และ MongoDB อีก 4 GiB โดยระดับนี้รองรับผู้ใช้พร้อมกันได้สูงสุด 500 ราย

ที่จำนวนผู้ใช้ 10 ราย ทั้ง 4 รายการสามารถทำงานบนฮาร์ดแวร์ทั่วไปที่คุณไม่ต้องกังวลเรื่องสเปก แต่เมื่อถึง 100 ราย คำตอบจะเริ่มแตกต่างกัน: Mattermost ยังคงอยู่ในระดับ 2 GB, Zulip ต้องการ 4 GB และ CPU ตัวที่สอง ส่วนระดับที่เล็กที่สุดที่ Rocket.Chat ระบุไว้ยังคงอยู่ที่ 8 GB เนื่องจากความต้องการหน่วยความจำของ MongoDB ขึ้นอยู่กับขนาดของเครื่องมากกว่าจำนวนผู้ใช้ของคุณ

การเลือกฐานข้อมูลส่งผลต่อการอัปเกรดในอนาคตมากกว่าประสิทธิภาพการใช้งานรายวัน Mattermost ต้องการ PostgreSQL 14 หรือใหม่กว่า และได้ยกเลิกการรองรับ MySQL ตั้งแต่ v11 เป็นต้นไป ดังนั้นการติดตั้งด้วย MySQL ในวันนี้จึงหมายถึงการต้องย้ายระบบในวันหน้า Synapse ทำงานบน SQLite และเอกสารระบุไว้อย่างชัดเจนว่า SQLite เหมาะสำหรับการทดสอบเท่านั้น เนื่องจากมีประสิทธิภาพต่ำในห้องขนาดใหญ่ Rocket.Chat 8 ต้องการ MongoDB 8.0 ซึ่งหมายความว่าการอัปเกรดฐานข้อมูลและการอัปเกรดแอปแชทถือเป็นโครงการเดียวกัน ไม่ใช่สองโครงการแยกกัน

VPS ขนาด 2 GB ให้อะไรคุณได้บ้าง

แผน 2 GB เป็นขนาดเริ่มต้นของผู้ให้บริการส่วนใหญ่ และเป็นคำตอบที่แท้จริงสำหรับสองในสี่รายการนี้

• Mattermost ใช้งานได้ เป็นเพียงรายการเดียวที่ผู้ผลิตระบุขนาดนี้ไว้ชัดเจน รองรับผู้ใช้สูงสุด 1,000 คน โดยมี PostgreSQL อยู่บนเครื่องเดียวกัน การใช้งานสำหรับ 10 คนบน 2 GB ถือว่าสบายมาก
• Zulip ใช้งานได้ แต่ต้องใช้ swap เอกสารแนะนำให้ใช้ swap หากมี RAM ต่ำกว่า 5 GB และเตือนว่าเครื่องที่มี RAM น้อยจะพบข้อผิดพลาด out of memory ระหว่างการอัปเกรด ซึ่ง tools/webpack คือขั้นตอนที่มักจะล้มเหลว นี่เป็นปัญหาจริงที่คุณจะพบตอนอัปเกรด ไม่ใช่ตอนติดตั้ง
• Synapse ใช้งานได้ในขณะที่ไม่มีการใช้งานหนัก ค่าใช้จ่ายตอน idle นั้นต่ำ ปัญหาอยู่ที่ช่วงที่มีการใช้งานพุ่งสูงขึ้น ซึ่งส่วนเรื่อง federation ด้านล่างจะอธิบายที่มาของปัญหานี้
• Rocket.Chat คือสิ่งที่ควรหลีกเลี่ยงบน 2 GB สาเหตุมาจาก storage engine ของ MongoDB โดย WiredTiger จะกำหนดขนาด internal cache ไว้ที่ค่าที่มากกว่าระหว่าง 50% ของ (RAM ลบด้วย 1 GB) หรือ 256 MB ดังนั้นบนเครื่อง 2 GB มันจะจองพื้นที่ไว้ประมาณ 512 MB ก่อนที่ Node.js จะเริ่มทำงานเสียอีก ผลลัพธ์ไม่ใช่การปฏิเสธการทำงานอย่างตรงไปตรงมา แต่มันจะติดตั้งได้ ทำงานได้ แล้วค่อยๆ ช้าลงเมื่อประวัติการใช้งานเพิ่มขึ้น จนในที่สุด kernel out of memory killer จะสั่งหยุด process ที่ใช้หน่วยความจำมากที่สุดในขณะนั้น

ตรวจสอบสิ่งที่คุณมีจริงก่อนตัดสินใจ เพราะผู้ให้บริการนับ RAM ต่างจาก free:

free -h
swapon --show

โปรดจำไว้ว่า chat server ไม่ใช่สิ่งเดียวที่อยู่บนเครื่อง ทั้ง TLS (transport layer security) termination, การสำรองข้อมูล และ container runtime ต่างก็ต้องการหน่วยความจำทั้งสิ้น ไม่ว่าคุณจะเลือก server ตัวใด ให้วางไว้หลัง reverse proxy ที่คุณเข้าใจ เช่น Nginx, Caddy หรือ Traefik และหากคุณ deploy ด้วย container สิ่งที่ควรทำให้ถูกต้องตั้งแต่แรกคือ พื้นฐาน Docker Compose สำหรับ VPS

แอปมือถือจำเป็นต้องมี push server ของคุณเองหรือไม่

นี่คือประเด็นสำคัญที่ผู้ใช้งานมักพบหลังจากติดตั้งระบบไปแล้ว และเป็นปัจจัยหลักในการตัดสินใจเลือกใช้งาน

กลไกการทำงานมีดังนี้ Apple Push Notification service (APNs) และ Firebase Cloud Messaging (FCM) จะยอมรับการแจ้งเตือนจากผู้ที่ถือครองข้อมูลรับรอง (signing credentials) ของแอปนั้นๆ เท่านั้น เซิร์ฟเวอร์ของคุณไม่สามารถส่ง push ไปยังแอปที่คุณไม่ได้เป็นผู้สร้างได้ ดังนั้นเซิร์ฟเวอร์แชทแบบ self-hosted ที่ใช้แอปจาก App Store ของผู้พัฒนาหลัก จึงต้องส่งการแจ้งเตือนผ่านเกตเวย์ของผู้พัฒนานั้นๆ ซึ่งจะเป็นผู้กำหนดเงื่อนไขการใช้งาน

• Mattermost. ช่องทางฟรีคือ Test Push Notification Service (TPNS) ที่ https://push-test.mattermost.com ซึ่งเอกสารระบุว่าไม่แนะนำให้ใช้ในสภาพแวดล้อมจริง (production) และไม่มีข้อตกลงระดับการให้บริการ (SLA) บริการนี้ใช้งานได้กับแอปที่ติดตั้งจาก App Store และ Play Store เท่านั้น ส่วน Hosted Push Notification Service (HPNS) เป็นบริการระดับ production ซึ่งต้องสมัครสมาชิกแบบเสียค่าใช้จ่าย ช่องทางที่สามคือการคอมไพล์ push proxy ด้วยตนเอง ซึ่งจำเป็นต้องสร้างแอปของคุณเองโดยใช้ข้อมูลรับรอง APNs และ FCM ของคุณเอง
• Rocket.Chat. การใช้งาน push ต้องลงทะเบียน workspace กับ Rocket.Chat Cloud โดย workspace รุ่น community จะถูกจำกัดการส่ง push notification ไว้ที่ 10,000 ครั้งต่อเดือน ซึ่งเท่ากับประมาณ 330 ครั้งต่อวันสำหรับทั้ง workspace เมื่อโควตาหมด การแจ้งเตือนจะหยุดทำงานจนกว่าจะถึงรอบเดือนถัดไป ซึ่งผู้ใช้จะรู้สึกว่าแอปมีปัญหา
• Matrix with Element. Synapse จะส่งการแจ้งเตือนไปยัง push gateway และแอป Element อย่างเป็นทางการจะชี้ไปยังเกตเวย์ที่ matrix.org ดูแลอยู่ที่ https://matrix.org/_matrix/push/v1/notify ข้อมูลที่ส่งจะประกอบด้วยตัวระบุเหตุการณ์และห้อง (event and room identifiers) แทนที่จะเป็นข้อความจริง โดยแอปจะดึงเนื้อหาจากเซิร์ฟเวอร์ของคุณโดยตรง ทำให้เกตเวย์เห็นเพียง metadata ไม่ใช่เนื้อหาบทสนทนา การรัน Sygnal gateway ของตนเองสามารถทำได้ แต่หมายความว่าคุณต้องสร้างและแจกจ่ายแอปของคุณเอง สำหรับ Android มีทางเลือกสายกลางคือการใช้ UnifiedPush ร่วมกับเซิร์ฟเวอร์ ntfy ที่คุณโฮสต์เอง
• Zulip. แผนบริการฟรีรองรับบริการ mobile push สำหรับผู้ใช้สูงสุด 10 คน หากเกิน 10 คน คุณจำเป็นต้องสมัครแผนบริการ โดยแผน Community แบบฟรีครอบคลุมองค์กรที่ไม่แสวงหาผลกำไรจำนวนมาก ทั้งนี้ Zulip 12.0 ซึ่งเปิดตัวในเดือนเมษายน 2026 ได้เพิ่มการเข้ารหัสแบบ end-to-end สำหรับข้อมูล push payload

ที่จำนวนผู้ใช้ 10 คน ทุกแพลตฟอร์มข้างต้นให้การแจ้งเตือนที่ใช้งานได้โดยไม่มีค่าใช้จ่าย แต่เมื่อถึง 100 คน สถานการณ์จะเปลี่ยนไป: Zulip จำเป็นต้องใช้แผนบริการ, Mattermost ยังคงใช้บริการทดสอบได้โดยไม่มี SLA และไม่มีการสนับสนุน, ข้อจำกัดรายเดือนของ Rocket.Chat จะกลายเป็นอุปสรรค, ส่วน Matrix จะไม่ได้รับผลกระทบเนื่องจากเกตเวย์เปิดให้ใช้งานได้ฟรี

ตัวเลือกใดบ้างที่ให้ใช้งาน Single sign-on ได้ฟรี

Single sign-on (SSO) เป็นจุดที่โมเดลธุรกิจแบบ open core แสดงให้เห็นชัดเจนที่สุด

• Zulip รวม SAML (security assertion markup language) และ LDAP (lightweight directory access protocol) ไว้ในเซิร์ฟเวอร์แบบ self-hosted โดยไม่มีค่าใช้จ่าย ไม่มีการแบ่งระดับการใช้งานที่ต้องซื้อเพิ่ม
• Synapse รองรับ OpenID Connect (OIDC), SAML และ CAS ในไฟล์คอนฟิกูเรชันของตนเองโดยไม่มีค่าใช้จ่าย การติดตั้งใหม่ในปัจจุบันนิยมใช้ Matrix Authentication Service ซึ่งเป็นบริการแยกต่างหากที่มีการย้ายข้อมูลแบบทางเดียวจากระบบยืนยันตัวตนแบบเดิมของ Synapse ดังนั้นควรวางแผนการย้ายระบบไว้ล่วงหน้าแทนที่จะไปพบปัญหาภายหลัง
• Rocket.Chat รุ่น community edition รองรับการล็อกอินผ่าน LDAP และ SAML ขั้นพื้นฐาน ส่วนการซิงค์คุณลักษณะผู้ใช้เพิ่มเติม, การแมปกลุ่มและทีม, และการซิงโครไนซ์เบื้องหลังจำเป็นต้องใช้ใบอนุญาตระดับ enterprise
• Mattermost รุ่น Team Edition ที่ใช้งานได้ฟรีให้เฉพาะ GitLab OAuth เท่านั้น ส่วน SAML, AD/LDAP และ OpenID Connect เป็นฟีเจอร์ที่ต้องเสียค่าใช้จ่าย

หากคุณวางแผนที่จะรันหลายบริการภายใต้การล็อกอินเดียว ให้ติดตั้ง ผู้ให้บริการระบุตัวตน Authentik แบบ self-hosted ไว้ด้านหน้าบริการเหล่านั้น และตรวจสอบว่าบริการทั้งสี่ตัวใดบ้างที่สามารถเชื่อมต่อกับระบบดังกล่าวได้จริงภายใต้ใบอนุญาตที่คุณถืออยู่

ต้นทุนที่แท้จริงของการทำ Federation

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

นอกจากนี้ยังเป็นเหตุผลที่ทำให้ Synapse มีภาระงานที่แตกต่างออกไป เมื่อผู้ใช้ของคุณเข้าร่วมห้องแบบ federated เซิร์ฟเวอร์ของคุณจะรับสำเนาสถานะและเหตุการณ์ของห้องนั้นมา และจะแคชสื่อที่ผู้ใช้บนเซิร์ฟเวอร์อื่นโพสต์ไว้ เช่น รูปโปรไฟล์ รูปภาพ และไฟล์ต่างๆ ดังนั้นการใช้งานดิสก์ของคุณจึงถูกกำหนดโดยห้องที่คุณไม่ได้สร้างขึ้นและโดยผู้ที่ไม่มีบัญชีบนเซิร์ฟเวอร์ของคุณ นี่คือเหตุผลที่การติดตั้ง Synapse มักจะมีขนาดของ media store ใหญ่กว่าปริมาณข้อความที่ผู้ใช้ของตนเองส่งจริง และเป็นเหตุผลว่าทำไมการเข้าร่วมห้องสาธารณะขนาดใหญ่จึงเป็นปฏิบัติการที่เอกสารระบุเงื่อนไขด้านหน่วยความจำไว้โดยเฉพาะ

ควรกำหนดนโยบายการเก็บรักษาข้อมูล (retention policy) ตั้งแต่วันแรก แทนที่จะรอจนกว่าดิสก์จะเต็ม:

media_retention:
  local_media_lifetime: 90d
  remote_media_lifetime: 14d

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

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

การอัปเกรดมีขั้นตอนอย่างไร

Zulip ทำได้ง่ายที่สุด ใช้สคริปต์เพียงตัวเดียว และมีเวลาหยุดทำงานตามเอกสารระบุไว้ไม่เกิน 30 วินาที เว้นแต่จะมีการย้ายฐานข้อมูลขนาดใหญ่ การติดตั้งและการอัปเกรดมีลักษณะดังนี้ ซึ่งคุณต้องรันบนเซิร์ฟเวอร์:

cd $(mktemp -d)
curl -fLO https://download.zulip.com/server/zulip-server-latest.tar.gz
tar -xf zulip-server-latest.tar.gz

ให้รันตัวติดตั้งในฐานะ root โดย flag --push-notifications จะลงทะเบียนเซิร์ฟเวอร์กับบริการ mobile push ระหว่างการติดตั้ง และระบบจะขอให้คุณยอมรับข้อกำหนดในการให้บริการในขณะนั้น ดังนั้นโปรดอ่านข้อกำหนดก่อนเริ่มดำเนินการ

sudo ./zulip-server-*/scripts/setup/install --push-notifications --certbot \
    --email=YOUR_EMAIL --hostname=YOUR_HOSTNAME

การอัปเกรดในภายหลังจะใช้ tarball เดียวกันบวกกับคำสั่งเดียว:

curl -fLO https://download.zulip.com/server/zulip-server-latest.tar.gz
sudo /home/zulip/deployments/current/scripts/upgrade-zulip zulip-server-latest.tar.gz

Mattermost มีความคาดเดาได้ ให้แทนที่ไฟล์ binary แล้วรีสตาร์ท จากนั้นการย้ายข้อมูลจะทำงานตอนเริ่มต้นระบบ นับตั้งแต่รุ่นเดือนสิงหาคม 2025 เป็นต้นไป แทร็ก Extended Support Release (ESR) จะออกทุก 9 เดือนพร้อมการสนับสนุน 12 เดือน และการอัปเกรดจาก ESR ไปยัง ESR เป็นเส้นทางที่ผ่านการทดสอบแล้ว การข้ามรุ่น ESR หลายรุ่นพร้อมกันสามารถทำได้แต่ไม่ผ่านการทดสอบ ซึ่งในทางปฏิบัติหมายความว่าคุณจะเป็นผู้ทดสอบด้วยตนเอง

Rocket.Chat ผูกการอัปเกรดสามส่วนเข้าด้วยกัน ณ เดือนสิงหาคม 2026 รุ่น 8.x เป็นรุ่นปัจจุบัน โดยรุ่น 8.7.0 ได้รับการปล่อยออกมาเมื่อวันที่ 6 สิงหาคม 2026 ซึ่งต้องการ MongoDB 8.0 และเวอร์ชัน Node.js ที่ตรงกัน การข้ามเวอร์ชันหลักเป็นสาเหตุที่ทำให้ผู้ใช้พบกับปัญหาฐานข้อมูลที่แอปพลิเคชันปฏิเสธที่จะเปิดใช้งาน คู่มือการติดตั้ง Rocket.Chat ด้วย Docker Compose จะกำหนดเวอร์ชันเหล่านี้ไว้ให้คุณ ซึ่งเป็นเหตุผลหลักที่แนะนำให้ใช้รูปแบบคอนเทนเนอร์ในกรณีนี้

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

ข้อกำหนดสิทธิ์การใช้งานในภาษาที่เข้าใจง่าย

Mattermost แจกจ่ายไฟล์ที่คอมไพล์แล้วของ Team Edition ภายใต้สิทธิ์การใช้งานแบบ MIT ในขณะที่ซอร์สโค้ดเสนอให้ภายใต้ AGPLv3 หรือสิทธิ์การใช้งานเชิงพาณิชย์ โดยมีบางส่วนของ repository ที่อยู่ภายใต้ Mattermost Source Available License ซึ่งกำหนดให้ต้องมีสิทธิ์การใช้งานแบบชำระเงินเพื่อใช้งานในสภาพแวดล้อม production ส่วน Rocket.Chat ใช้สิทธิ์ MIT ยกเว้นไดเรกทอรี ee/ ซึ่งมีสิทธิ์การใช้งานระดับองค์กรของตนเอง Synapse เปลี่ยนจาก Apache 2.0 มาเป็น AGPLv3 ตั้งแต่เวอร์ชัน 1.99.0 และผู้ร่วมพัฒนาต้องลงนามใน CLA ซึ่งอนุญาตให้ Element ขายข้อยกเว้นสำหรับสิทธิ์การใช้งานนั้นได้ ส่วน Zulip ใช้สิทธิ์ Apache 2.0 โดยไม่มีไดเรกทอรีสำหรับองค์กรแยกต่างหาก ซึ่งเป็นเหตุผลว่าทำไมฟีเจอร์ SSO ของ Zulip จึงไม่มีเงื่อนไขเพิ่มเติม

ในทางปฏิบัติ: AGPL จะมีผลกับคุณก็ต่อเมื่อคุณวางแผนที่จะแก้ไขเซิร์ฟเวอร์และให้บริการแก่ผู้อื่น สิ่งที่สำคัญกว่าสำหรับทีมขนาดเล็กคือแนวคิด open core ซึ่งหมายถึงฟีเจอร์ที่ขาดหายไปจากรุ่นฟรี Zulip มีฟีเจอร์ที่ขาดหายไปน้อยที่สุด ในขณะที่ Mattermost มีมากที่สุด

ควรเลือกตัวไหน

เครื่องมือสำหรับทีมภายใน: Mattermost เป็นตัวเลือกที่ใช้ทรัพยากรน้อยที่สุดตามเอกสารประกอบ การอัปเกรดมีความเสถียรสูง และมีอินเทอร์เฟซที่คุ้นเคยซึ่งไม่จำเป็นต้องมีการอธิบายเพิ่มเติม ควรวางแผนงบประมาณสำหรับแผนแบบเสียค่าใช้จ่ายในวันที่คุณต้องการใช้งาน SSO เพราะวันนั้นจะมาถึงสำหรับทีมส่วนใหญ่ในที่สุด

เซิร์ฟเวอร์สำหรับชุมชน: Zulip ระบบหัวข้อ (topics) ช่วยให้ช่องสาธารณะที่มีการพูดคุยหนาแน่นยังคงอ่านง่ายแม้เวลาผ่านไปหลายเดือน การใช้งาน SAML และ LDAP ไม่มีค่าใช้จ่าย และการอัปเกรดทำได้ด้วยคำสั่งเดียว หากชุมชนของคุณเน้นการโพสต์และตอบกลับมากกว่าการแชทสด ให้เปรียบเทียบกับ ซอฟต์แวร์ฟอรัมแบบ self-hosted ก่อน เนื่องจากฟอรัมรองรับการทำดัชนีในเครื่องมือค้นหาได้ดีกว่าและไม่จำเป็นต้องมีโครงสร้างพื้นฐานสำหรับ push notification เลือกใช้ Rocket.Chat แทนเมื่อคุณต้องการฟีเจอร์ด้านเสียง วิดีโอ และการสื่อสารแบบ omnichannel และสามารถจัดสรรทรัพยากร RAM ขนาด 8 GB ตามที่เอกสารประกอบระบุไว้ได้

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

FAQ

ทางเลือกในการทำ self-hosted แทน Slack ที่ดีที่สุดสำหรับทีมขนาดเล็กคืออะไร?

Mattermost คือคำตอบสำหรับทีมภายในส่วนใหญ่ เอกสารระบุว่าสามารถรองรับผู้ใช้ตั้งแต่ 1 ถึง 1,000 คนบน 1 vCPU และ RAM 2 GB โดยใช้ PostgreSQL บนเครื่องเดียวกัน ซึ่งเหมาะสมกับแผน VPS ระดับเริ่มต้นที่ผู้ให้บริการส่วนใหญ่มีจำหน่าย ข้อควรพิจารณาคือเรื่อง single sign-on โดย Team Edition รุ่นฟรีจะรองรับเฉพาะ GitLab OAuth เท่านั้น ส่วน SAML, AD/LDAP และ OpenID Connect จำเป็นต้องใช้แผนแบบชำระเงิน หากการทำ SSO ฟรีมีความสำคัญมากกว่าอินเทอร์เฟซที่คล้าย Slack ให้เลือกใช้ Zulip แทน

ฉันสามารถรันเซิร์ฟเวอร์แชทแบบ self-hosted บน VPS ขนาด 2 GB ได้หรือไม่?

Mattermost สามารถทำได้ ส่วน Zulip ก็ทำได้หากคุณเพิ่ม swap ซึ่งเอกสารของ Zulip เองแนะนำให้ทำหากมี RAM ต่ำกว่า 5 GB สำหรับ Rocket.Chat คุณอาจผิดหวัง เนื่องจากเอนจิน WiredTiger ของ MongoDB จะจองพื้นที่แคชไว้ที่ 50% ของ (RAM ลบด้วย 1 GB) หรือ 256 MB แล้วแต่ว่าค่าใดจะมากกว่า ดังนั้น RAM ประมาณ 512 MB ของเครื่องขนาด 2 GB จะถูกใช้ไปก่อนที่แอปพลิเคชันจะเริ่มทำงานเสียอีก มันสามารถติดตั้งได้แต่ประสิทธิภาพจะลดลงเมื่อประวัติการแชทเพิ่มขึ้น จนนำไปสู่ปัญหา out of memory kill ในที่สุด สเปกขั้นต่ำที่ Rocket.Chat แนะนำคือ 4 GiB สำหรับแอปพลิเคชันและ 4 GiB สำหรับ MongoDB

เซิร์ฟเวอร์แชทแบบ self-hosted จำเป็นต้องมีเซิร์ฟเวอร์ push notification ของตัวเองหรือไม่?

โดยปกติแล้วไม่จำเป็น เนื่องจาก APNs ของ Apple และ FCM ของ Google จะยอมรับการแจ้งเตือนจากผู้ที่ลงนามในแอปเท่านั้น ดังนั้นแอปของผู้ให้บริการจึงใช้เกตเวย์ของผู้ให้บริการนั้นๆ โดยมีเงื่อนไขที่แตกต่างกันไป Mattermost มีบริการทดสอบฟรีที่ไม่มี SLA และบริการแบบโฮสต์ที่ต้องชำระเงิน Rocket.Chat จำกัดพื้นที่ทำงานแบบชุมชนไว้ที่ 10,000 การแจ้งเตือนต่อเดือน หากเกินกว่านั้นการส่งการแจ้งเตือนจะหยุดลงจนกว่าจะขึ้นรอบเดือนใหม่ Zulip ให้บริการ push ฟรีสำหรับผู้ใช้สูงสุด 10 คนและต้องใช้แผนที่สูงกว่านั้นหากมีผู้ใช้มากกว่านี้ ส่วน Matrix homeserver จะส่งการแจ้งเตือนผ่านเกตเวย์ที่แอป Element ใช้งานโดยไม่มีค่าใช้จ่าย คุณจำเป็นต้องมีเกตเวย์ของตัวเองก็ต่อเมื่อคุณสร้างและแจกจ่ายแอปของคุณเองเท่านั้น

ฉันควรทำ self-host Matrix และ Synapse สำหรับทีมที่ไม่เคยคุยกับเซิร์ฟเวอร์อื่นหรือไม่?

ไม่ควร การทำ Federation คือจุดประสงค์หลักของ Synapse และเป็นสิ่งที่ทำให้มันกินทรัพยากรสูง การเข้าร่วมห้องบนเซิร์ฟเวอร์อื่นจะดึงสถานะและแคชสื่อต่างๆ มาเก็บไว้ในดิสก์ของคุณ ทำให้พื้นที่จัดเก็บข้อมูลเพิ่มขึ้นโดยไม่เกี่ยวข้องกับผู้ใช้ของคุณเอง ควรตั้งค่า media_retention ด้วย remote_media_lifetime ที่สั้นก่อนที่จะเกิดเหตุการณ์ดังกล่าว ทีมที่คุยกันเองภายในจะได้รับเพียงภาระด้านการดูแลรักษาโดยไม่ได้รับประโยชน์ใดๆ ในขณะที่ Mattermost หรือ Zulip สามารถทำงานเดียวกันได้โดยใช้ทรัพยากรฮาร์ดแวร์ที่น้อยกว่า

ทางเลือกในการทำ self-hosted แทน Slack ตัวไหนที่มี single sign-on ฟรี?

Zulip และ Synapse โดย Zulip รวม SAML และ LDAP ไว้ในเซิร์ฟเวอร์แบบ self-hosted โดยไม่มีค่าใช้จ่าย ส่วน Synapse รองรับ OpenID Connect, SAML และ CAS ในการตั้งค่า โดยการติดตั้งรุ่นใหม่ๆ กำลังเปลี่ยนไปใช้ Matrix Authentication Service แยกต่างหาก สำหรับ Rocket.Chat รุ่น community รองรับการล็อกอินด้วย LDAP และ SAML พื้นฐาน แต่จำกัดฟีเจอร์การซิงค์แอตทริบิวต์, การแมปกลุ่ม และการซิงค์เบื้องหลังไว้ในใบอนุญาตระดับองค์กร (enterprise) ส่วน Team Edition รุ่นฟรีของ Mattermost รองรับเฉพาะ GitLab OAuth เท่านั้น