เปรียบเทียบ 5 ทางเลือก Trello แบบ self-hosted ตัวไหนดี

คุณควรเลือกทางเลือก Trello แบบ self-hosted ตัวไหน?

ทางเลือก Trello แบบ self-hosted ที่น่าสนใจมี 3 ตัว ได้แก่ Planka หากคุณต้องการบอร์ดที่เหมือนกับ Trello และต้องการฟีเจอร์นำเข้าไฟล์ของ Trello, Vikunja เมื่อทีมของคุณต้องการระบบ single sign-on และฟีเจอร์ที่มากกว่าแค่บอร์ด และ Kanboard เมื่อคุณใช้ VPS (virtual private server) ที่มีทรัพยากรจำกัด อย่าเริ่มโปรเจกต์ใหม่บน Focalboard เนื่องจากเซิร์ฟเวอร์แบบ standalone ของโปรเจกต์นี้ไม่มีการออก release ใหม่มาเป็นเวลา 783 วันแล้ว และไฟล์ README ในปัจจุบันยังประกาศหาผู้ดูแลโปรเจกต์อยู่

Wekan เป็นเครื่องมือลำดับที่ 5 จากทั้งหมด 5 รายการในที่นี้ มันสามารถใช้งานได้จริง แต่ใช้หน่วยความจำมากกว่าเครื่องมือตัวอื่นหลายเท่า ข้อมูลเวอร์ชัน ใบอนุญาต และวันที่ทั้งหมดด้านล่างนี้ได้รับการตรวจสอบเมื่อวันที่ 5 สิงหาคม 2026

เครื่องมือแต่ละตัวใช้ RAM เท่าใด

[
  {
    "tool": "Planka + Postgres",
    "idle_memory_mb": 280
  },
  {
    "tool": "Vikunja + SQLite",
    "idle_memory_mb": 110
  },
  {
    "tool": "Focalboard + SQLite",
    "idle_memory_mb": 120
  },
  {
    "tool": "Wekan + FerretDB",
    "idle_memory_mb": 750
  },
  {
    "tool": "Kanboard + SQLite",
    "idle_memory_mb": 70
  }
]

ตัวเลขเหล่านี้เป็นค่าเฉลี่ยขณะไม่ได้ใช้งาน (idle) สำหรับการติดตั้งใหม่ที่ยังไม่มีผู้ใช้ ซึ่งเป็นค่าที่ docker stats รายงานหลังจากเริ่มระบบขึ้นมาได้หนึ่งนาที ให้ใช้ตัวเลขนี้เพื่อวางแผนขนาดของเซิร์ฟเวอร์ จากนั้นจึงวัดค่าจริงจากระบบของคุณเอง รูปแบบการใช้งานมีความสำคัญมากกว่าจำนวนเมกะไบต์ที่แน่นอน

Kanboard คือจุดต่ำสุดที่ 70 MB เนื่องจากเป็น PHP ที่ทำงานร่วมกับ SQLite ไม่มีกระบวนการทำงานของแอปพลิเคชันที่ค้างอยู่ในหน่วยความจำเพื่อจัดการบอร์ดของคุณ ดังนั้นคอนเทนเนอร์จึงแทบไม่ใช้ทรัพยากรเลยระหว่างรอรับคำขอ Vikunja เป็น Go binary ตัวเดียวที่ 110 MB และมี SQLite เป็นฐานข้อมูลเริ่มต้น ดังนั้นคอนเทนเนอร์เดียวจึงเป็นทั้งระบบ Planka ต้องการ 280 MB เพราะต้องใช้สองคอนเทนเนอร์เสมอ คือ Node server และ PostgreSQL โดย Planka ไม่มีตัวเลือก SQLite ดังนั้นฐานข้อมูลจึงเป็นสิ่งที่หลีกเลี่ยงไม่ได้

Wekan อยู่ที่ 750 MB เพราะเป็นแอปพลิเคชัน Meteor ซึ่ง Meteor จะเก็บชั้นข้อมูล live query ไว้ในหน่วยความจำของ Node และส่งการเปลี่ยนแปลงของบอร์ดไปยังเบราว์เซอร์ทุกเครื่องที่เปิดอยู่ผ่าน WebSocket ดังนั้นหน่วยความจำจะเพิ่มขึ้นตามจำนวนผู้ใช้งานที่เชื่อมต่อ แทนที่จะคงที่ บน VPS ขนาด 1 GB นั้น Wekan สามารถเริ่มทำงานได้ แต่จะหยุดทำงานทันทีที่มีคนเปิดบอร์ดขนาดใหญ่พร้อมกันหลายคน อาการที่พบคือคอนเทนเนอร์หายไปแล้วกลับมาใหม่พร้อม exit code 137 ซึ่ง docker compose ps จะแสดงให้เห็นว่าเป็นวงจรการรีสตาร์ท ให้ยืนยันสถานะบนโฮสต์ด้วย dmesg -T | grep -i "out of memory" เพราะตัวจัดการ out-of-memory ของ kernel จะไม่แจ้งเตือนแอปพลิเคชันใดๆ เลย

การพึ่งพาฐานข้อมูลเป็นตัวกำหนดภาระงานสำรองข้อมูลของคุณครึ่งหนึ่ง นี่คือรายละเอียดของแต่ละตัว Planka ต้องการ PostgreSQL ส่วน Vikunja ใช้ SQLite เป็นค่าเริ่มต้นและรองรับ PostgreSQL, MySQL หรือ MariaDB สำหรับ Kanboard ใช้ SQLite เป็นค่าเริ่มต้นและรองรับ MySQL, MariaDB และ PostgreSQL โดยเอกสารแนะนำให้ใช้ PostgreSQL และเตือนไม่ให้ใช้ SQLite บน NFS (network file system) ส่วน Focalboard ใช้ SQLite เป็นค่าเริ่มต้น และ Wekan ใช้โปรโตคอลของ MongoDB โดยไฟล์ Compose เริ่มต้นในปัจจุบันมาพร้อมกับ FerretDB v1 ที่มี backend เป็น SQLite แทนที่จะเป็นเซิร์ฟเวอร์ MongoDB จริง แต่ก็มีไฟล์ Compose สำหรับ MongoDB 7 แยกต่างหากหากคุณต้องการใช้งาน

โครงการใดบ้างที่ยังคงมีการดูแลรักษาอยู่?

[
  {
    "tool": "Planka 2.1.1",
    "release_age": 109
  },
  {
    "tool": "Vikunja 2.5.0",
    "release_age": 1
  },
  {
    "tool": "Focalboard 8.0.0",
    "release_age": 783
  },
  {
    "tool": "Wekan 10.67",
    "release_age": 1
  },
  {
    "tool": "Kanboard 1.2.53",
    "release_age": 12
  }
]

Focalboard เป็นกรณีที่แตกต่างออกไปโดยมีอายุการปล่อยรุ่นล่าสุดอยู่ที่ 783 วัน โดยรุ่น standalone ล่าสุดคือ v8.0.0 ซึ่งออกมาเมื่อเดือนมิถุนายน 2024 ทาง Mattermost ได้ย้ายการพัฒนาส่วน board ไปเป็นปลั๊กอินใน repository แยกต่างหาก และไฟล์ README ของรุ่น standalone ระบุว่า repository นี้ไม่ได้มีการดูแลรักษาแล้ว ซึ่งถือเป็นคำตอบว่า "ไม่" อย่างชัดเจนเพียงหนึ่งเดียวในการเปรียบเทียบนี้ ส่วนโครงการอื่นที่เหลือเป็นการแลกเปลี่ยนข้อดีข้อเสียที่แตกต่างกันไป

ค่า 109 วันของ Planka ถือว่าอยู่ในเกณฑ์ดีสำหรับโครงการที่มีการปล่อยรุ่นออกมาปีละไม่กี่ครั้ง โดยเวอร์ชัน 2.1.1 ออกมาเมื่อเดือนเมษายน 2026 ส่วน Kanboard ได้ปล่อยรุ่น v1.2.53 ออกมาเมื่อ 12 วันก่อนการตรวจสอบ และสองรุ่นก่อนหน้านั้นก็ออกมาในช่วงเดือนมีนาคมและเมษายน 2026

ทั้ง Vikunja และ Wekan มีการปล่อยรุ่นออกมาภายในหนึ่งวันก่อนการตรวจสอบ แต่คุณควรตีความข้อมูลทั้งสองนี้ต่างกัน Vikunja ได้ tag รุ่น v2.5.0 ในฐานะการอัปเดตย่อยตามปกติ ส่วน Wekan ได้ tag รุ่น v10.65, v10.66 และ v10.67 ในวันเดียวกัน ซึ่งเป็นจังหวะการทำงานปกติของโครงการนี้ การปล่อยรุ่นบ่อยครั้งไม่ได้หมายความว่าเป็นเป้าหมายที่เสถียรเสมอไป สำหรับ Wekan คุณกำลังเลือกที่จะติดตามเวอร์ชันที่มีการเปลี่ยนแปลงอย่างรวดเร็ว ดังนั้นควรระบุ tag ให้ชัดเจน (pin) และอ่านบันทึกการเปลี่ยนแปลงก่อนการอัปเดตทุกครั้ง

คุณได้มากกว่าแค่กระดานงานหรือไม่?

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

• Planka เป็นเครื่องมือประเภทกระดานงานเพียงอย่างเดียว ประกอบด้วยโปรเจกต์, กระดาน, รายการ, การ์ด, ป้ายกำกับ, รายการตรวจสอบ, ความคิดเห็น และไฟล์แนบ ส่วนมุมมองปฏิทินและแผนที่ถือเป็นฟีเจอร์ระดับ Pro ณ เดือนสิงหาคม 2026
• Vikunja มอบมุมมอง 4 รูปแบบสำหรับชุดงานเดียวกัน ได้แก่ รายการ (List), คัมบัง (Kanban), ตาราง (Table) และแกนต์ (Gantt) งานหนึ่งรายการจะมีอยู่เพียงชุดเดียว และคุณสามารถสลับมุมมองได้โดยไม่ต้องคัดลอกข้อมูลซ้ำ
• Kanboard คือกระดานงานที่มีการจำกัดจำนวนงานที่ทำอยู่ (work-in-progress limits), งานย่อย, ไฟล์แนบ, ความคิดเห็น, การทำงานอัตโนมัติ และภาษาสำหรับสืบค้นข้อมูลขนาดเล็กเพื่อใช้กรองงาน หน้าเว็บไซต์หลักของโปรแกรมระบุว่า "จำนวนฟีเจอร์ถูกจำกัดไว้โดยเจตนา" ซึ่งถือเป็นคำอธิบายที่ตรงไปตรงมา
• Wekan คือกระดานงานที่มีช่องทางแยก (swimlanes) เพิ่มเติมจากรายการตรวจสอบ, ฟิลด์ข้อมูลที่กำหนดเอง, REST (representational state transfer) API และ webhooks
• Focalboard นำเสนอมุมมองแบบกระดาน, ตาราง และปฏิทินสำหรับข้อมูลการ์ดชุดเดียวกัน โดยรายการนี้ถูกระบุไว้เพื่อให้ข้อมูลครบถ้วนสมบูรณ์

หากสิ่งที่คุณต้องการจริงๆ คือวิกิที่มีระบบติดตามงานพ่วงมาด้วย การเปรียบเทียบนี้อาจไม่ตรงกับความต้องการของคุณ BookStack, Wiki.js และ Outline ครอบคลุมรูปแบบการใช้งานดังกล่าว และ ทางเลือกแทน Notion สำหรับการโฮสต์เอง ครอบคลุมถึงพื้นที่ทำงานแบบรวมศูนย์ในที่เดียว

การเข้าถึงแบบหลายผู้ใช้และระบบลงชื่อเข้าใช้ครั้งเดียว (Single Sign-on)

Planka รองรับ OpenID Connect ในรุ่น Community ที่ใช้งานได้ฟรี ไฟล์ Compose อย่างเป็นทางการได้ระบุการตั้งค่าเหล่านี้ไว้โดยใส่เครื่องหมายคอมเมนต์กำกับไว้ ซึ่งรวมถึง OIDC_ISSUER, OIDC_CLIENT_ID และ OIDC_CLIENT_SECRET ดังนั้นคุณเพียงแค่ลบเครื่องหมายคอมเมนต์ออกแทนที่จะต้องอัปเกรดเวอร์ชัน ส่วนบทบาทผู้เยี่ยมชม (Guest roles) สำหรับบุคคลภายนอกองค์กรนั้นเป็นฟีเจอร์ที่มีเฉพาะในรุ่น Pro เท่านั้น

Vikunja รองรับ OpenID Connect กับผู้ให้บริการหลายรายพร้อมกัน ให้ตั้งค่า VIKUNJA_AUTH_OPENID_ENABLED=true จากนั้นเพิ่มบล็อกตัวแปร VIKUNJA_AUTH_OPENID_PROVIDERS_<ID>_* หนึ่งชุดต่อผู้ให้บริการหนึ่งราย นอกจากนี้ยังมีระบบทีมและการแชร์ข้อมูลรายโปรเจกต์ ซึ่งเป็นสิ่งที่องค์กรขนาด 20 คนต้องการใช้งานจริง

Wekan รองรับ LDAP (Lightweight Directory Access Protocol), OAuth2, OIDC และ SAML ส่วน Kanboard มี LDAP ในตัวและมีปลั๊กอิน OAuth2 แบบทั่วไปสำหรับรองรับโปรโตคอลอื่น ๆ รวมถึงมีระบบบทบาทและกลุ่มผู้ใช้รายโปรเจกต์ สำหรับ Focalboard ในรูปแบบ standalone server นั้นไม่มีระบบลงชื่อเข้าใช้ครั้งเดียวเลย ซึ่งเป็นเหตุผลข้อที่สองที่คุณควรพิจารณาตัดออกจากการใช้งาน

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

คุณสามารถนำเข้าบอร์ด Trello ของคุณได้หรือไม่

Planka มีขั้นตอนที่ง่ายที่สุด ให้ส่งออกบอร์ดจาก Trello เป็นไฟล์ JSON สร้างบอร์ดใน Planka จากนั้นคลิก Import และเลือก Trello โปรดอ่านข้อจำกัดก่อนดำเนินการเนื่องจากเป็นข้อจำกัดที่เกิดขึ้นจริง: ข้อมูลผู้ใช้และไฟล์แนบจะไม่ถูกนำเข้า, รายการตรวจสอบ (checklist) จะถูกนำเข้ามาเพียงรายการเดียวต่อหนึ่งการ์ด และการส่งออก JSON ตามค่าเริ่มต้นของ Trello จะหยุดที่ 1,000 รายการโดยไม่มีการแจ้งเตือนว่าข้อมูลถูกตัดทอน โปรดตรวจสอบไฟล์ด้วยตนเองก่อนที่จะเชื่อถือผลลัพธ์

Vikunja รองรับการนำเข้าผ่านขั้นตอน OAuth ของ Trello โดยไปที่ Settings แล้วเลือก "Import from other services" ตัวย้ายข้อมูลแต่ละตัวจะต้องถูกเปิดใช้งานในไฟล์ config ก่อนไอคอนจึงจะปรากฏขึ้น และ VIKUNJA_SERVICE_PUBLICURL จะต้องถูกต้องเนื่องจากกระบวนการเปลี่ยนเส้นทาง (redirect) ของ OAuth จะเกิดขึ้นในเบราว์เซอร์ของคุณไม่ใช่จากเซิร์ฟเวอร์ นอกจากนี้ Vikunja ยังรองรับการนำเข้าจาก Todoist, Microsoft To Do, TickTick และ Wekan อีกด้วย

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

ประสบการณ์การใช้งานบนอุปกรณ์เคลื่อนที่เป็นอย่างไร

Vikunja เป็นเพียงแอปเดียวจากทั้ง 5 รายการที่มีแอปพลิเคชันอย่างเป็นทางการสำหรับอุปกรณ์เคลื่อนที่ โดยมีการปล่อยไฟล์ติดตั้งสำหรับ Android และ iOS ควบคู่ไปกับแต่ละ release ของซอฟต์แวร์ อย่างไรก็ตาม repository ของแอปยังระบุสถานะว่าเป็น alpha ดังนั้นควรใช้งานแอปนี้ในลักษณะเป็นส่วนเสริมของหน้าเว็บอินเทอร์เฟซมากกว่าที่จะใช้เป็นช่องทางหลักในการเข้าถึง ส่วน Planka นั้นไม่มีแอปอย่างเป็นทางการจากผู้พัฒนาโดยตรง แม้ว่าหน้าเว็บอินเทอร์เฟซจะรองรับการแสดงผลแบบ responsive และมีแอปจากผู้พัฒนาภายนอกให้เลือกใช้งาน ในขณะที่ Wekan และ Kanboard รองรับเฉพาะการใช้งานผ่านเว็บเท่านั้น และหน้าอินเทอร์เฟซของ Kanboard ถูกออกแบบมาให้เหมาะกับการใช้งานบนหน้าจอเดสก์ท็อปอย่างชัดเจน

ประเด็นเรื่องสิทธิ์การใช้งาน และเหตุผลที่ Planka แตกต่างออกไป

Planka ไม่ใช่ซอฟต์แวร์โอเพนซอร์สอีกต่อไป ซึ่งเป็นข้อเท็จจริงที่การเปรียบเทียบส่วนใหญ่มักมองข้าม โดยเริ่มต้นภายใต้สัญญาอนุญาต MIT ก่อนจะเปลี่ยนเป็น AGPL-3.0 ในปี 2023 และตั้งแต่เวอร์ชัน 2.0 เป็นต้นมา ได้เปลี่ยนมาใช้ PLANKA Community License ซึ่งเป็นสัญญาอนุญาตแบบ fair-code ที่ถือครองโดย PLANKA Software GmbH ทาง GitHub ระบุสถานะสัญญาอนุญาตว่าเป็น "Other" เนื่องจากสัญญาอนุญาตดังกล่าวไม่ได้รับการรับรองจาก OSI การ self-host เพื่อใช้งานภายในองค์กรของคุณเองนั้นไม่มีค่าใช้จ่ายและได้รับอนุญาตอย่างชัดเจน ซึ่งครอบคลุมถึงการใช้งานส่วนบุคคล ภายในองค์กร ไม่แสวงหาผลกำไร และเพื่อการศึกษา แต่หากต้องการขายสิทธิ์การเข้าถึงหรือให้บริการในรูปแบบ SaaS แก่บริษัทอื่น จำเป็นต้องมีสัญญาอนุญาตเชิงพาณิชย์

สำหรับผู้ใช้งานสองคน นี่ถือเป็นข้อตกลงที่ยุติธรรม แต่สำหรับบริษัท นี่คือเงื่อนไขที่ต้องอ่านให้ละเอียดก่อนที่จะนำงานของพนักงานกว่ายี่สิบคนไปฝากไว้กับระบบนี้ ส่วนอีกสี่ตัวเลือกที่เหลือเป็นโอเพนซอร์สตามปกติ ได้แก่ Vikunja ซึ่งใช้สัญญาอนุญาต AGPL-3.0, Wekan และ Kanboard ซึ่งใช้ MIT และ Focalboard ซึ่งเป็นการผสมผสานระหว่าง Apache 2.0 และ AGPL-3.0

การตรึงเวอร์ชันของไฟล์ Compose สำหรับทั้งสองตัวเลือก

ให้ตรึงแท็กของอิมเมจไว้ latest หมายความว่า docker compose pull ถัดไปอาจทำให้คุณข้ามเวอร์ชันหลัก (major version) ได้ และเวอร์ชันหลักมักมีการรัน database migration ซึ่งย้อนกลับได้ยาก ไฟล์ทั้งสองด้านล่างนี้คือไฟล์ต้นฉบับที่ได้รับการแก้ไขแท็กให้เป็นเวอร์ชันที่ปล่อยออกมาจริงแล้ว

Vikunja บน SQLite แบบหนึ่งคอนเทนเนอร์:

services:
  vikunja:
    image: vikunja/vikunja:2.5.0
    restart: unless-stopped
    environment:
      VIKUNJA_SERVICE_PUBLICURL: https://tasks.example.com
      VIKUNJA_SERVICE_SECRET: replace-with-a-long-random-string
      VIKUNJA_SERVICE_TIMEZONE: Europe/Berlin
      VIKUNJA_DATABASE_TYPE: sqlite
      VIKUNJA_DATABASE_PATH: /app/vikunja/files/vikunja.db
    ports:
      - "127.0.0.1:3456:3456"
    volumes:
      - ./files:/app/vikunja/files

ให้สร้างไดเรกทอรีข้อมูลด้วยเจ้าของที่ถูกต้องก่อน เพราะคอนเทนเนอร์รันด้วย UID 1000 จึงไม่สามารถเขียนข้อมูลลงในไดเรกทอรีที่เป็นของ root ได้:

mkdir -p files && sudo chown 1000 files
docker compose up -d
docker compose ps
curl -sf http://127.0.0.1:3456/api/v1/info

Stack ที่ทำงานปกติจะแสดงสถานะบริการเป็น running และ endpoint ข้อมูลจะส่งคืน JSON ที่มีฟิลด์ version หากพบข้อผิดพลาด Connection refused แสดงว่าคอนเทนเนอร์หยุดทำงานไปแล้ว docker compose logs vikunja จะระบุสาเหตุ ซึ่งข้อผิดพลาดเรื่องสิทธิ์การเข้าถึงไฟล์ฐานข้อมูลเป็นปัญหาที่พบบ่อยที่สุด

Planka บน PostgreSQL แบบสองคอนเทนเนอร์:

services:
  planka:
    image: ghcr.io/plankanban/planka:2.1.1
    restart: unless-stopped
    volumes:
      - data:/app/data
    ports:
      - "127.0.0.1:3000:1337"
    environment:
      - BASE_URL=https://boards.example.com
      - DATABASE_URL=postgresql://postgres@postgres/planka
      - SECRET_KEY=replace-with-openssl-rand-hex-64
    depends_on:
      postgres:
        condition: service_healthy

  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    volumes:
      - db-data:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB=planka
      - POSTGRES_HOST_AUTH_METHOD=trust
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres -d planka"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  data:
  db-data:

POSTGRES_HOST_AUTH_METHOD=trust หมายความว่า PostgreSQL ยอมรับการเชื่อมต่อทุกรูปแบบโดยไม่ต้องใช้รหัสผ่าน ซึ่งปลอดภัยก็ต่อเมื่อพอร์ตของฐานข้อมูลไม่ได้ถูกเปิดออกสู่โฮสต์ ดังนั้นสิ่งเดียวที่เข้าถึงได้คือคอนเทนเนอร์อีกตัวที่อยู่บน Compose network เดียวกัน ห้ามเพิ่มรายการ ports: เข้าไปในบริการ postgres โดยเด็ดขาด

ทั้งสอง stack ไม่ควรหันหน้าออกสู่อินเทอร์เน็ตโดยตรง ทั้งคู่ผูกไว้กับ 127.0.0.1 ดังนั้นควรติดตั้ง reverse proxy ไว้ด้านหน้าเพื่อทำ TLS (transport layer security) termination ที่จุดนั้น การใช้ Traefik ไว้หน้าแอป Compose หลายตัว เป็นวิธีปกติที่ใช้เมื่อคุณโฮสต์มากกว่าหนึ่งบริการ และ คู่มือพื้นฐาน Docker Compose ได้ครอบคลุมส่วนประกอบของไฟล์เหล่านี้ที่หน้านี้ไม่ได้กล่าวถึงไว้แล้ว

บอร์ดของคุณคือฐานข้อมูล ดังนั้นต้องสำรองข้อมูลไว้

เครื่องมือจัดการบอร์ดอาจล้มเหลวโดยไม่มีการแจ้งเตือน ไม่มีใครสังเกตเห็นว่าข้อมูลสำรองหายไปจนกว่าโวลุ่มจะถูกลบ และไฟล์ SQLite ที่เสียหายอาจเปิดใช้งานได้ตามปกติ แต่จะรายงานข้อผิดพลาดในอีก database disk image is malformed สัปดาห์ให้หลัง

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

docker compose stop vikunja
tar czf vikunja-$(date +%F).tgz files
docker compose start vikunja

สำหรับ Planka ให้ใช้การ dump ข้อมูล PostgreSQL แทนการคัดลอกไดเรกทอรีข้อมูลของคลัสเตอร์ที่กำลังทำงานอยู่ และให้สำรองโวลุ่มที่เก็บไฟล์อัปโหลดแยกต่างหาก เนื่องจากไฟล์แนบไม่ได้ถูกเก็บไว้ในฐานข้อมูล:

docker compose exec -T postgres pg_dump -U postgres -Fc planka > planka-db.dump
docker volume ls
docker run --rm -v planka_data:/data -v "$PWD":/backup alpine \
  tar czf /backup/planka-files.tgz -C /data .

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

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

คำแนะนำสองประการ

สำหรับผู้ใช้งาน 2 คนบน VPS ขนาด 2 GB: ให้ใช้ Planka เนื่องจากมีหน้าตาและการทำงานใกล้เคียงกับ Trello มากที่สุด การนำเข้าข้อมูลจาก Trello ทำได้โดยการลากไฟล์เข้าไป และด้วยการใช้หน่วยความจำขณะว่างที่ 280 MB ทำให้เหลือพื้นที่หน่วยความจำส่วนใหญ่ของ 2 GB ไว้สำหรับ reverse proxy และบริการอื่นที่คุณโฮสต์ไว้ Community License ครอบคลุมการใช้งานสำหรับทีมภายในขนาด 2 คนโดยไม่มีค่าใช้จ่าย หากคุณไม่ต้องการพึ่งพาใบอนุญาตแบบ source-available ให้เลือกใช้ Vikunja บน SQLite ซึ่งใช้หน่วยความจำที่ 110 MB โดยเป็นตัวเลือกแบบ open-source สำหรับเซิร์ฟเวอร์ขนาดเดียวกัน

สำหรับองค์กรขนาด 20 คน: ให้ใช้ Vikunja บน PostgreSQL ที่ขนาดองค์กรระดับนี้ คุณจำเป็นต้องใช้ OpenID Connect แทนการจัดการรหัสผ่านภายใน 20 ชุด คุณต้องการฟีเจอร์ทีมและการแชร์งานรายโปรเจกต์ และเนื่องจากงานส่วนใหญ่ไม่สามารถแสดงผลบนบอร์ดได้เพียงอย่างเดียว มุมมองแบบ List, Table และ Gantt จึงไม่ใช่แค่ฟีเจอร์เสริมอีกต่อไป ใบอนุญาตแบบ AGPL-3.0 ยังช่วยให้ไม่ต้องกังวลเรื่องลิขสิทธิ์เมื่อจำนวนพนักงานเพิ่มขึ้น ให้ใช้ PostgreSQL แทน SQLite วางระบบไว้หลัง reverse proxy และสำรองข้อมูลรายวันไว้ที่อื่นที่ไม่ใช่เซิร์ฟเวอร์เครื่องนั้น

หากเซิร์ฟเวอร์มี RAM น้อยกว่า 1 GB คำแนะนำข้างต้นจะไม่สามารถใช้ได้ ให้เลือกใช้ Kanboard ที่ใช้หน่วยความจำ 70 MB ยอมรับว่าคุณจะต้องพิมพ์ข้อมูลการ์ดจาก Trello ใหม่ และนำหน่วยความจำที่ประหยัดได้ไปใช้กับบริการอื่นจาก รายการแนะนำสำหรับการ self-hosting ในปี 2026 รายละเอียดการติดตั้งเชิงลึกสำหรับเครื่องมือที่คุณเลือกจะอยู่ในคู่มือเฉพาะของเครื่องมือนั้นๆ หน้าเพจนี้มีไว้เพื่อการตัดสินใจเลือกเท่านั้น

FAQ

ทางเลือกแทน Trello แบบ self-hosted ตัวใดใช้ RAM น้อยที่สุด?

Kanboard ใช้ RAM ขณะ idle ประมาณ 70 MB เนื่องจากเป็น PHP ที่ทำงานร่วมกับ SQLite และไม่มีการเก็บข้อมูลไว้ในหน่วยความจำระหว่างการร้องขอ ถัดมาคือ Vikunja ซึ่งใช้ RAM ประมาณ 110 MB ในรูปแบบ Go binary ไฟล์เดียว ส่วน Wekan เป็นตัวที่ใช้ทรัพยากรสูงที่สุดที่ประมาณ 750 MB เพราะ Meteor ต้องเก็บ live query layer ไว้ในหน่วยความจำของ Node สำหรับทุกเบราว์เซอร์ที่เชื่อมต่ออยู่ คุณควรวัดค่าด้วยตนเองโดยใช้ docker stats หลังจากที่ stack อยู่ในสถานะ idle เนื่องจากตัวเลขเหล่านี้เป็นเพียงค่าโดยประมาณ ไม่ใช่การรับประกัน

ฉันสามารถนำเข้าบอร์ดจาก Trello มายังเครื่องมือแบบ self-hosted ได้หรือไม่?

ทั้ง Planka และ Wekan รองรับการนำเข้าไฟล์ JSON ที่ export มาจาก Trello ได้โดยตรง ส่วน Vikunja จะนำเข้าผ่าน OAuth flow ของ Trello โดยต้องเปิดใช้งานตัว migrator ในไฟล์ config ก่อนจึงจะปรากฏในหน้าอินเทอร์เฟซ สำหรับ Kanboard ไม่มีเครื่องมือ import ในตัว ทั้งนี้มีข้อจำกัดสองประการที่ควรทราบ: Planka ไม่รองรับการนำเข้าผู้ใช้หรือไฟล์แนบและรองรับเพียงหนึ่งรายการตรวจสอบ (checklist) ต่อการ์ดเท่านั้น และการ export ข้อมูล JSON ตามค่าเริ่มต้นของ Trello จะหยุดที่ 1,000 รายการโดยไม่มีการแจ้งเตือนว่าข้อมูลถูกตัดทอน

Focalboard ยังเป็นตัวเลือกที่ดีในปี 2026 หรือไม่?

ไม่แนะนำ รุ่น standalone ล่าสุดคือ v8.0.0 ซึ่งปล่อยออกมาเมื่อเดือนมิถุนายน 2024 หรือคิดเป็น 783 วันก่อนการตรวจสอบเปรียบเทียบนี้ในวันที่ 5 สิงหาคม 2026 และไฟล์ README ระบุว่า repository ดังกล่าวไม่มีการดูแลรักษาแล้ว ส่วน Mattermost ได้ย้ายการพัฒนาบอร์ดไปเป็นปลั๊กอินใน repository แยกต่างหาก ดังนั้นตัวเซิร์ฟเวอร์ที่คุณจะนำมา self-host จึงเป็นส่วนที่หยุดพัฒนาไปแล้ว ควรเลือกใช้ Planka หรือ Vikunja แทน

Planka ยังเป็นโอเพนซอร์สอยู่หรือไม่?

ในนิยามของ OSI ถือว่าไม่ใช่ Planka เคยใช้สัญญาอนุญาต MIT แต่เปลี่ยนเป็น AGPL-3.0 ในปี 2023 และตั้งแต่เวอร์ชัน 2.0 เป็นต้นมาได้เปลี่ยนมาใช้ PLANKA Community License การใช้งานแบบ self-host นั้นฟรีสำหรับการใช้งานส่วนบุคคล, ภายในองค์กร, ไม่แสวงหาผลกำไร และเพื่อการศึกษา แต่การขายสิทธิ์การเข้าถึงหรือการให้บริการแก่บุคคลที่สามจำเป็นต้องมีใบอนุญาตเชิงพาณิชย์ นอกจากนี้ฟีเจอร์มุมมองปฏิทิน, บทบาทแขก (guest roles) และการ์ดแบบทำซ้ำ (recurring cards) ยังถูกจำกัดไว้ในระดับ Pro หากคุณมีข้อกำหนดที่เคร่งครัดว่าต้องใช้สัญญาอนุญาตที่ได้รับการรับรองจาก OSI แนะนำให้ใช้ Vikunja ซึ่งเป็น AGPL-3.0 หรือ Kanboard ซึ่งเป็น MIT

ฉันจำเป็นต้องใช้ PostgreSQL หรือ SQLite ก็เพียงพอแล้ว?

Vikunja, Kanboard และ Focalboard ใช้ SQLite เป็นค่าเริ่มต้น ซึ่งเพียงพอสำหรับการใช้งานโดยคนจำนวนไม่กี่คนบนเซิร์ฟเวอร์เดียว ส่วน Planka จำเป็นต้องใช้ PostgreSQL และไม่มีตัวเลือกสำหรับ SQLite ให้เลือก คุณควรย้ายไปใช้ PostgreSQL เมื่อมีผู้ใช้งานหลายคนเขียนข้อมูลพร้อมกัน เนื่องจาก SQLite จะทำการจัดลำดับการเขียน (serialise) และหาก instance มีการใช้งานหนาแน่นจะเริ่มส่งคืนค่า database is locked นอกจากนี้ ห้ามวางไฟล์ SQLite ไว้บน network share โดยเด็ดขาด เนื่องจากเอกสารของ Kanboard ได้เตือนไว้ว่าไม่ควรใช้ SQLite บน NFS ด้วยเหตุผลนี้เช่นกัน