สแตกเพิ่มประสิทธิภาพนักพัฒนาแบบโฮสต์เอง: แทนที่ GitHub, Vercel และ Sentry บน VPS เครื่องเดียวในปี 2026

ที่ราคาตามรายการปัจจุบัน ทีมขนาด 3 คนที่ใช้ GitHub Team, Vercel Pro, Sentry Team, Linear Basic และ Notion Plus เริ่มต้นราว 158 ดอลลาร์ต่อเดือน ก่อนรวม 1Password ค่าบริการตามการใช้งาน และส่วนเสริม สแตกแบบโฮสต์เองที่กำหนดขอบเขตอย่างรอบคอบช่วยลดค่าใช้จ่ายนี้ได้มาก แต่การเปรียบเทียบที่เป็นธรรมต้องรวม VPS ที่ใหญ่กว่าขั้นต่ำระดับห้องทดลอง 4 GB และเวลาบำรุงรักษาที่ทุกคนมักลืม

คู่มือนี้เขียนให้นักพัฒนาหรือทีมเล็กที่ตัดสินใจแล้วว่า “บิลค่า SaaS น่ารำคาญ” และ “การเก็บโค้ดส่วนตัวกับเวิร์กโฟลว์การพัฒนาไว้บนโครงสร้างพื้นฐานของบุคคลที่สามนั้นไม่สบายใจ” และตอนนี้อยากรู้ว่าควรรันอะไรกันแน่ สแตกนี้มีสี่ชั้น ได้แก่ โค้ด บิลด์และดีพลอย รัน และเอกสาร แต่ละชั้นจะมีเครื่องมือที่แนะนำหนึ่งตัว ทางเลือกหนึ่งตัว ต้นทุนทรัพยากร และรูปแบบความล้มเหลว ขอบเขตคือการใช้งานส่วนตัวและในทีมบน VPS เครื่องเดียว ส่วนการโฮสต์อีเมล DNS การยืนยันตัวตนสำหรับลูกค้า และ Kubernetes อยู่นอกขอบเขต ด้วยเหตุผลที่เราจะระบุไว้ในจุดที่เหมาะสม

เวอร์ชันสั้น

หากคุณอ่านเฉพาะหัวข้อย่อย:

• รหัส: เลือก Forgejo เป็นค่าเริ่มต้น ใช้ GitLab CE ก็ต่อเมื่อคุณต้องการ git, CI/CD, รีจิสทรี และการติดตามงานในผลิตภัณฑ์เดียว โดยเกณฑ์พื้นฐานปัจจุบันของ GitLab แบบโหนดเดียวคือ RAM 16 GB ส่วน 8 GB สงวนไว้สำหรับสภาพแวดล้อมที่หน่วยความจำจำกัด
• บิลด์และดีพลอย: Coolify on the current stable release (v4.3.0 at QC time), with the dashboard kept off the public internet. Dokku suits solo developers; pure Docker Compose suits teams that prefer visible moving parts.
• รัน: Vaultwarden สำหรับข้อมูลรับรองที่ใช้ร่วมกัน, Uptime Kuma สำหรับการมอนิเตอร์, GlitchTip สำหรับติดตามข้อผิดพลาด และ Portainer หรือ Dockge สำหรับจัดการคอนเทนเนอร์ GlitchTip เป็นการติดตั้งที่เล็กกว่า Sentry แบบโฮสต์เองมาก ซึ่งมีขั้นต่ำอย่างเป็นทางการที่ RAM 16 GB บวกสว็อป 16 GB
• เอกสาร: Docmost สำหรับเอกสาร และ OpenProject (หรือ Plane) สำหรับติดตามงาน ส่วน AFFiNE เหมาะกับทีมที่ชอบโมเดลแบบ Notion ที่เป็นผืนผ้าใบ
• การกำหนดขนาด ให้มอง 4 GB เป็นขนาดห้องทดลองสำหรับบริการเบา ๆ ไม่กี่ตัว, 8 GB เป็นไพลอตแบบลดทอนที่ไม่มี OpenProject, Plane หรือการบิลด์ในเครื่อง และ 16 GB เป็นจุดเริ่มต้นที่ใช้งานได้จริงสำหรับสแตกบน Forgejo แบบครบชุดในคู่มือนี้ เกณฑ์ 8 vCPU/16 GB ของ GitLab ใช้กับตัว GitLab เอง ดังนั้นสแตกกล่องเดียวที่อิง GitLab จึงต้องมีกำลังเพิ่มหรือการทดสอบภาระงานแยกต่างหาก
• จุดที่เสียเปรียบ: โครงการโอเพนซอร์สสาธารณะที่มีผู้ร่วมพัฒนาจากภายนอก ผลกระทบเชิงเครือข่ายของ GitHub นั้นมีอยู่จริง และการโฮสต์เองทำให้คุณเสียโอกาสถูกค้นพบ

ข้อกำหนดเบื้องต้น

ก่อนอ่านต่อ คู่มือนี้ตั้งสมมติฐานว่า:

• VPS ที่ใช้ Linux พร้อมติดตั้ง Docker และ Docker Compose วางแผน RAM ราว 16 GB สำหรับสแตกบน Forgejo แบบครบชุด ส่วน 8 GB เหมาะกับไพลอตแบบลดทอนที่ตัดเครื่องมือบริหารโครงการตัวหนัก ๆ และการบิลด์ในเครื่องออกไป
• เวลาโฟกัส 30 ถึง 60 นาทีต่อชั้นสำหรับการดีพลอยครั้งแรก
• ความคุ้นเคยในการอ่านไฟล์ Compose และปรับตัวแปรสภาพแวดล้อม
• ความเต็มใจที่จะรักษาช่วงเวลาอัปเดตอย่างสม่ำเสมอ ติดตั้งแพตช์ความปลอดภัยโดยเร็ว และตรวจสอบข้อมูลสำรองจริง ไม่ใช่แค่ตั้งค่าไว้

ถ้าข้อใดข้อหนึ่งเป็นอุปสรรคที่รับไม่ได้ ชุด SaaS ก็คือคำตอบที่ถูกต้องสำหรับทีมของคุณจริง ๆ นั่นเป็นจุดยืนที่มีเหตุผลรองรับ ไม่ใช่ความล้มเหลว

ชั้นที่ 1 โค้ด: Forgejo, Gitea หรือ GitLab CE

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

Forgejo ออกแบบมาสำหรับโครงสร้างพื้นฐานขนาดย่อม และมีทั้ง pull request การติดตามงาน บอร์ดโครงการ วิกิ รีจิสทรีแพ็กเกจ และ Forgejo Actions เวิร์กโฟลว์ของมันใช้รูปแบบสไตล์ GitHub Actions แต่ความเข้ากันได้ไม่ใช่ทั้งหมด จึงควรทดสอบ action จากภายนอกทุกตัวที่ไปป์ไลน์ของคุณพึ่งพา

เลือก Gitea เฉพาะเมื่อคุณพึ่งพาฟีเจอร์ที่มีเฉพาะใน Gitea อยู่แล้ว หรือเครื่องมือของคุณถูกตรึงไว้กับ Gitea เวอร์ชันหนึ่ง ตัวโค้ดเบสไม่มีอะไรผิด การเปรียบเทียบอย่างเป็นทางการ ของ Forgejo ระบุว่าการแยกสายเกิดขึ้นหลังจากที่โดเมนและเครื่องหมายการค้าของ Gitea ถูกโอนให้บริษัทแสวงหากำไรในเดือนตุลาคม 2022 โดยไม่ผ่านความเห็นชอบของชุมชน ส่วน ประกาศเรื่องสัญญาอนุญาต ของ Forgejo ระบุว่าเวอร์ชันตั้งแต่ v9.0 เป็นต้นไปใช้ GPL v3+

เลือก GitLab CE ถ้าคุณต้องการผลิตภัณฑ์เดียวที่ครอบคลุม git, CI/CD, รีจิสทรีคอนเทนเนอร์ และการติดตามงาน และคุณรับภาระทรัพยากรขั้นต่ำของมันไหว ข้อกำหนดปัจจุบันของ GitLab กำหนดให้ RAM 16 GB และ 8 vCPU เป็นเกณฑ์พื้นฐานของโหนดเดียว ส่วน 8 GB ไว้สำหรับสภาพแวดล้อมที่หน่วยความจำจำกัด Gitea เบาพอที่จะรันอินสแตนซ์ส่วนตัวขนาดเล็กในราว 1 ถึง 2 GB และ Forgejo ก็ใกล้เคียงกัน แต่การกำหนดขนาดในโปรดักชันของทั้งคู่ยังขึ้นอยู่กับจำนวนรีโพ รันเนอร์ และผู้ใช้พร้อมกัน

เรื่อง CI ควรพูดถึงเป็นพิเศษ Gitea Actions ออกแบบให้เข้ากันได้กับ GitHub Actions เป็นส่วนใหญ่ ขณะที่ Forgejo Actions ตั้งใจมุ่งไปที่ความคุ้นเคยมากกว่าความเข้ากันได้เต็มรูปแบบ เวิร์กโฟลว์จำนวนมากต้องแก้เพียงเล็กน้อย แต่อิมเมจของรันเนอร์ สิทธิ์ คอนเท็กซ์ เลเบล และ action จากภายนอกอาจทำงานต่างออกไป ควรทดสอบทุกเวิร์กโฟลว์และทุก action ที่ไปป์ไลน์ของคุณพึ่งพาก่อนย้ายระบบ

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

กำหนดขนาดเซิร์ฟเวอร์จากภาระงานจริง ไม่ใช่จากชื่อแพ็กเกจของผู้ให้บริการ บริการ Forgejo หรือ Gitea เดี่ยว ๆ สำหรับใช้งานส่วนตัวแบบเบา อาจเริ่มที่ราว 1 ถึง 2 vCPU และ RAM 1 ถึง 2 GB สแตกแบบลดทอนที่ไม่มี OpenProject, Plane หรือการบิลด์ในเครื่อง อาจเริ่มที่ราว 4 vCPU และ RAM 8 GB ส่วนสแตกบน Forgejo แบบครบชุดที่อธิบายไว้ที่นี่ ให้เริ่มที่ราว 8 vCPU และ RAM 16 GB แล้วตรวจสอบภายใต้ภาระงานจริงของ CI และแอปพลิเคชัน เกณฑ์ทางการของ GitLab ที่ 8 vCPU/16 GB ใช้กับตัว GitLab เอง จึงอย่าถือว่าเพียงพอสำหรับ GitLab บวกกับสแตกที่เหลือ ใช้พื้นที่จัดเก็บแบบ SSD หรือ NVMe แยกงบสำหรับรีโพ อิมเมจคอนเทนเนอร์ ล็อก ฐานข้อมูล และข้อมูลสำรอง และเหลือกำลังว่างไว้ 20 ถึง 30% สำหรับการอัปเดตและช่วงโหลดพุ่ง

ประเด็นสำคัญของส่วนนี้: Forgejo คือคำแนะนำเริ่มต้นสำหรับชั้นโค้ดในปี 2026 ส่วน Gitea ยังคงแข็งแรงดี และ GitLab CE จะเป็นตัวเลือกแบบรวมทุกอย่างก็ต่อเมื่อคุณรับพื้นฐาน 16 GB ไหว หรือยอมรับการทำงานในค่าคอนฟิกจำกัดที่ 8 GB อย่างรู้ตัว

ชั้นที่ 2 บิลด์และดีพลอย: Coolify (พร้อมข้อแม้), Dokku หรือ Docker Compose ล้วน

พูดกันตรง ๆ คือ Coolify เป็นตัวเลือก PaaS ที่แนะนำสำหรับสแตกนี้ ถ้าคุณรันรีลีสโปรดักชันล่าสุด กันแดชบอร์ดผู้ดูแลออกจากอินเทอร์เน็ตสาธารณะ และติดตามประกาศด้านความปลอดภัย ณ เวลาตรวจคุณภาพ GitHub ระบุว่า Coolify v4.3.0 Coolify v4.1.2 เป็นเวอร์ชันล่าสุด จงถือว่าการแพตช์และการแยกระนาบผู้ดูแลเป็นข้อกำหนดในการดำเนินงาน ไม่ใช่การเสริมความแข็งแกร่งแบบเลือกได้

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

ทางเลือกสำหรับนักพัฒนาเดี่ยวคือ Dokku ซึ่งเป็น PaaS ขนาดกะทัดรัดที่ดีพลอยด้วย git push สไตล์ Heroku และรองรับ buildpack มันมีพื้นที่ผิวเล็กกว่า Coolify และชุดฟีเจอร์ก็เล็กลงตามกัน จึงเป็น “ตัวเลือกที่น่าเบื่อ” ซึ่งมีเหตุผลรองรับ สำหรับนักพัฒนาหนึ่งหรือสองคนที่ไม่ต้องการแดชบอร์ด

ตัวเลือกที่สามที่ผู้ดูแลระบบซึ่งมีประสบการณ์มักเลือกใช้คือ ไม่ใช้ PaaS เลย ใช้แค่ Docker Compose. ถ้าทีมของคุณเขียนไฟล์ Compose อยู่แล้วและชอบให้เห็นชิ้นส่วนที่ทำงานอยู่ นี่ก็เป็นคำตอบที่สมเหตุสมผลอย่างยิ่ง เพิ่ม Dockge หรือ Portainer เป็นชั้นอินเทอร์เฟซสำหรับจัดการสแตกเมื่อคุณอยากรีสตาร์ตด้วยการคลิกแทนการพิมพ์ docker compose restart ข้อแลกเปลี่ยนอยู่ที่การปฏิบัติงาน ไม่มีสภาพแวดล้อมพรีวิว ไม่มีการทำ TLS อัตโนมัติในตัว และไม่มีการดีพลอยแบบไม่มีดาวน์ไทม์หากไม่ลงแรง ฟีเจอร์เหล่านี้ต้องแลกมาด้วยการเขียนสคริปต์ ส่วนใน Coolify มีมาให้พร้อม พร้อมกับประวัติด้านความปลอดภัยที่ติดมาด้วย

อ่าน

ทางเลือกแทน Heroku และ Vercel แบบ Self-Hosted ที่ดีที่สุด: Coolify, Dokku และอื่นๆ

คู่มือเครื่องมือ CI/CD ที่ดีที่สุดของ Cloudzy เจาะลึกไปป์ไลน์การบิลด์สำหรับทีมที่ต้องมีรันเนอร์แยก ซึ่งทีมเล็ก ๆ จำนวนมากไม่จำเป็นต้องมี เมื่อมี Forgejo Actions หรือ CI/CD ของ GitLab อยู่แล้ว

ประเด็นสำคัญของส่วนนี้: Coolify เป็น PaaS ที่แนะนำก็ต่อเมื่ออยู่บนรีลีสเสถียรปัจจุบันและจำกัดระนาบผู้ดูแลไว้ ส่วน Dokku คือตัวเลือกอนุรักษนิยมสำหรับคนเดียว และ Docker Compose ล้วนยังเป็นตัวเลือกที่สามซึ่งมีเหตุผลรองรับ

ชั้นที่ 3 รัน: Vaultwarden, Uptime Kuma, GlitchTip และการจัดการคอนเทนเนอร์

ช่องว่างด้านทรัพยากรที่ชัดเจนที่สุดของสแตกนี้อยู่ตรงนี้ ข้อกำหนดอย่างเป็นทางการของ Sentry แบบโฮสต์เอง ระบุขั้นต่ำไว้ที่ซีพียู 4 คอร์, RAM 16 GB, สว็อป 16 GB และดิสก์ว่าง 20 GB โดยแนะนำ RAM 32 GB คู่มือการติดตั้งของ GlitchTip แนะนำ RAM 512 MB ต้องใช้ PostgreSQL และให้ Valkey เป็นทางเลือก สำหรับทีมเล็กบน VPS เครื่องเดียว GlitchTip คือค่าเริ่มต้นที่ใช้งานได้จริง

เครื่องมืออีกสี่ตัวในชั้นนี้เล่าสั้น ๆ ได้

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

Uptime Kuma คือเครื่องมือมอนิเตอร์และแจ้งเตือนตัวเล็ก รองรับการตรวจแบบ HTTP, TCP, ping, push, การหมดอายุของใบรับรอง และมีหน้าสถานะให้เลือกใช้ การแจ้งเตือนส่งผ่านแชท อีเมล หรือเว็บฮุกได้ การใช้ทรัพยากรแปรผันตามจำนวนมอนิเตอร์และระยะเก็บข้อมูล การตั้งให้เตือนเมื่อล้มเหลวครั้งที่สองติดกันเป็นวิธีที่ได้ผลในการกดสัญญาณรบกวนช่วงสั้น ๆ

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

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

แนวทางใช้ Compose ที่สะดวกสำหรับชั้นนี้: เก็บเครื่องมือแต่ละตัวไว้ในไดเรกทอรีย่อยของตัวเองพร้อมไฟล์ compose.yml ของตัวเอง แชร์เครือข่าย Docker เฉพาะจุดที่ต้องมีทราฟฟิกข้ามเครื่องมือ และวางรีเวิร์สพร็อกซีตัวเดียวไว้ด้านหน้าเพื่อจบการเชื่อมต่อ TLS

# /opt/stack/glitchtip/compose.yml (excerpt)
services:
  web:
    image: "glitchtip/glitchtip:${GLITCHTIP_VERSION:?Set GLITCHTIP_VERSION in .env}"
    environment:
      DATABASE_URL: "${DATABASE_URL:?Set DATABASE_URL in .env}"
      SECRET_KEY: "${GLITCHTIP_SECRET_KEY:?Set GLITCHTIP_SECRET_KEY in .env}"
      GLITCHTIP_DOMAIN: "https://errors.example.com"
      DEFAULT_FROM_EMAIL: "[email protected]"
    ports:
      - "127.0.0.1:8000:8000"

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

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

ชั้นที่ 4 เอกสาร: Docmost, AFFiNE และการติดตามงานด้วย OpenProject หรือ Plane

อินเทอร์เฟซของ Notion นั้นดีอยู่ จนกระทั่งวิกิที่โตขึ้นทำให้การนำทางและการค้นหารู้สึกอืด สำหรับทีมเล็ก การแบ่งงานที่แนะนำคือใช้ Docmost สำหรับเอกสารและวิกิ ควบคู่กับ OpenProject สำหรับติดตามงาน ให้เปลี่ยน OpenProject เป็น Plane หากทีมของคุณต้องการโมเดลเชิงภาพแบบ Linear โดยเฉพาะ และพร้อมดูแลการติดตั้งแบบโฮสต์เองที่รองรับของมัน

Docmost คือตัวแทน Notion แบบโฮสต์เองที่ใกล้เคียงที่สุดในที่นี้ โดยไม่ได้พยายามทำตัวเป็น Notion ตัวแก้ไขแบบบล็อก ลำดับชั้นของหน้า และสิทธิ์ของทีม เข้ากันได้กับวิกิภายในองค์กรแบบดั้งเดิม ให้กำหนดขนาดของชั้นนี้ตามจำนวนผู้แก้ไขพร้อมกัน ไฟล์แนบ และว่า PostgreSQL กับ Redis อยู่บนโฮสต์เดียวกันหรือไม่ ส่วน AFFiNE เป็นทางเลือกสำหรับทีมที่ชอบโมเดลผืนผ้าใบและไวต์บอร์ดมากกว่าหน้าเว็บซ้อนกัน ทั้งคู่สมเหตุสมผล เลือกมาสักตัว

OpenProject รับงานติดตามงานสำหรับทีมที่ถนัดเวิร์กโฟลว์กลิ่นอาย Jira ทั้งอีพิก แพ็กเกจงาน สปรินต์ และการบันทึกเวลา ส่วน Plane เป็นทางเลือกทรง Linear ที่มีอินเทอร์เฟซซึ่งเน้นตัวงานและเร็วกว่า พร้อมภาระด้านการดูแลที่ต่างออกไป

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

ประเด็นสำคัญของส่วนนี้: Docmost รับบทเอกสารภายในองค์กร ส่วน OpenProject หรือ Plane รับงานติดตามงาน ช่องว่างด้านประสบการณ์การใช้คีย์บอร์ดเมื่อเทียบกับ Linear คือจุดเดียวที่ชั้นนี้ขอให้คุณยอมประนีประนอม

สแตกนี้มีต้นทุนเท่าไรและรันบนอะไร

จุดเริ่มต้นที่ใช้งานได้จริงสำหรับสแตกบน Forgejo แบบครบชุดในเครื่องเดียวคือราว 8 vCPU และ RAM 16 GB ให้มอง 2 vCPU กับ RAM 4 GB เป็นขนาดห้องทดลองสำหรับบริการเบา ๆ ไม่กี่ตัว และ 4 vCPU กับ RAM 8 GB เป็นไพลอตแบบลดทอนที่ตัด OpenProject, Plane และการบิลด์ในเครื่องออก ความต้องการจริงขึ้นอยู่กับผู้ใช้พร้อมกัน กิจกรรม CI การเติบโตของฐานข้อมูล ไฟล์แนบ พื้นที่เก็บอิมเมจ ล็อก และระยะเก็บข้อมูล จึงควรตรวจสอบสแตกภายใต้ภาระงานจริงและเหลือกำลังว่างไว้ 20 ถึง 30% ระดับเริ่มต้นที่ 16 GB รองรับบริการต่อไปนี้ได้สำหรับทีมนักพัฒนา 2 ถึง 3 คนที่มีภาระงานเบา ทั้งนี้ต้องผ่านการทดสอบภาระงานด้วย:

• Forgejo
• Coolify
• Vaultwarden
• Uptime Kuma
• GlitchTip
• Docmost
• OpenProject
• Dockge

เซิร์ฟเวอร์ 4 GB เหมาะกับบริการเบา ๆ ไม่กี่ตัวเท่านั้น ส่วนเครื่อง 8 GB ควรถือเป็นไพลอตแบบลดทอนที่ไม่มี OpenProject, Plane หรือการบิลด์ในเครื่อง ให้เริ่มสแตกบน Forgejo แบบครบชุดที่ 16 GB และเพิ่มกำลังเมื่อรัน GitLab การบิลด์พร้อมกันหลายงาน Plane ระยะเก็บข้อมูลยาว ๆ หรือภาระฐานข้อมูลที่หนักขึ้น ชุด SaaS ของทีมเดียวกันนี้ประกอบด้วย:

• GitHub Team
• Vercel Pro
• Sentry
• Linear
• Notion
• 1Password

โดยอิงอัตราพื้นฐานที่ประกาศไว้บนหน้าราคาของแต่ละเจ้า (รวมถึงอัตราแบบชำระรายปีในกรณีที่มี) ผลิตภัณฑ์ที่มีราคาห้าตัวรวมกันราว 158 ดอลลาร์ต่อเดือนสำหรับสามคน: GitHub Team ที่ 4 ดอลลาร์ต่อผู้ใช้ในช่วง 12 เดือนแรก, ที่นั่งนักพัฒนาสามที่ของ Vercel Pro ที่ราคาที่ละ 20 ดอลลาร์, Sentry Team เริ่มต้นที่ 26 ดอลลาร์, Linear Basic ที่ 10 ดอลลาร์ต่อผู้ใช้ และ Notion Plus ที่ 10 ดอลลาร์ต่อผู้ใช้ ส่วนค่าบริการตามการใช้งาน ภาษี ส่วนเสริม และ 1Password คิดเพิ่มต่างหาก โครงสร้างพื้นฐานยังถูกกว่าได้อย่างมีนัยสำคัญ แต่การเปรียบเทียบจะไม่มีความหมายเลยหากไม่นับเวลาของผู้ดูแล

เมื่อใดควรขยับขนาดขึ้น: เกณฑ์โหนดเดียวของ GitLab คือ 8 vCPU และ RAM 16 GB การบิลด์พร้อมกันหลายงานอาจต้องใช้กำลังเพิ่มแม้ไม่มี GitLab ส่วน Sentry แบบโฮสต์เองก็เริ่มที่ RAM 16 GB บวกสว็อป 16 GB และแนะนำ 32 GB ซึ่งเป็นเหตุผลที่คู่มือนี้แนะนำ GlitchTip สำหรับสแตกกล่องเดียว

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

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

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

ประเด็นสำคัญของส่วนนี้: ใช้ 4 GB สำหรับห้องทดลองเล็ก ๆ, 8 GB สำหรับไพลอตแบบลดทอน และราว 8 vCPU กับ RAM 16 GB เป็นจุดเริ่มต้นที่ใช้งานได้จริงของสแตกบน Forgejo แบบครบชุด แล้วค่อยเพิ่มกำลังสำหรับ GitLab การบิลด์พร้อมกันหลายงาน เครื่องมือบริหารโครงการที่หนักขึ้น และฐานข้อมูลที่โตขึ้น

จุดที่การโฮสต์สแตกนี้เองล้มเหลวจริง ๆ

รูปแบบความล้มเหลวสี่แบบ เรียกกันตรง ๆ เพราะที่ผ่านมาทั้งคู่มือนี้เป็นการโต้แย้งสนับสนุนแนวทางนี้

ความล้มเหลวแบบที่ 1: ผลกระทบเชิงเครือข่ายของ GitHub ในโครงการโอเพนซอร์สสาธารณะ git แบบโฮสต์เองเป็นคำตอบที่ถูกสำหรับโค้ดส่วนตัว แต่เป็นคำตอบที่ผิดสำหรับโครงการที่คุณค่าทั้งหมดขึ้นอยู่กับการที่ผู้ร่วมพัฒนาภายนอกจะหาคุณเจอ GitHub คือที่แรกที่นักพัฒนามองหา ทั้ง pull request การ fork ดาว สัญญาณความน่าเชื่อถือโดยนัยของการอยู่บน github.com และการเชื่อมต่อกับเครื่องมือภายนอก ทั้งหมดนั้น หากโครงการของคุณเป็นโอเพนซอร์สสาธารณะ รูปแบบที่ซื่อตรงคือทำมิเรอร์ไว้บน GitHub เพื่อการมองเห็น พร้อมคงแหล่งข้อมูลจริงไว้บน Forgejo อย่าคาดหวังว่าอินสแตนซ์ที่โฮสต์เองจะแทนที่การถูกค้นพบบน GitHub สำหรับงานสาธารณะได้ มันจะไม่เป็นเช่นนั้น

ความล้มเหลวแบบที่ 2: ทราฟฟิกจากบอทและตัวขูดข้อมูลบนอินสแตนซ์ Git สาธารณะ บริการ Forgejo และ Gitea ที่เปิดสู่สาธารณะต้องมีมาตรการกันการใช้งานในทางที่ผิด การจำกัดอัตราคำขอ การมอนิเตอร์ และกำลังที่มากพอสำหรับทราฟฟิกที่คาดเดาไม่ได้ คู่มือนี้ตั้งอยู่บนการใช้งานส่วนตัวและในทีม โดยให้ส่วนของผู้ดูแลอยู่หลัง VPN หรือรายการ IP ที่อนุญาต ส่วนฟอร์จที่เปิดสาธารณะจริง ๆ นั้นมีแบบจำลองภัยคุกคามและกำลังที่ต่างออกไป

ความล้มเหลวแบบที่ 3: ภาระการบำรุงรักษา “คุณนั่นแหละคือแผนกไอที” เป็นคำพูดซ้ำซาก และส่วนใหญ่ก็จริง การอัปเดตทำของพัง ไฟล์ Compose ค่อย ๆ เพี้ยนไป ใบรับรองหมดอายุ ข้อมูลสำรองล้มเหลวอย่างเงียบ ๆ ในแบบที่น่าอับอายที่สุด ประกาศด้านความปลอดภัยของ Coolify ในปี 2026 เป็นเครื่องเตือนใจที่ดีว่าจังหวะการแพตช์นั้นสำคัญ ถ้าคุณให้คำมั่นเรื่องช่วงเวลาบำรุงรักษาไม่ได้ตั้งแต่ต้น ชุด SaaS ก็คือคำตอบที่ถูกต้องอย่างตรงไปตรงมา

ความล้มเหลวแบบที่ 4: การสูญเสียการเชื่อมต่อกับระบบอื่น GitHub Actions จากภายนอก, การดีพลอยพรีวิวของ Vercel ที่ผูกกับ pull request บน GitHub, การเชื่อมต่อการแจ้งเตือนแบบโฮสต์ของ Sentry กับ PagerDuty และ Linear, รวมถึงแคตตาล็อกการเชื่อมต่ออันกว้างขวางของ Notion ส่วนใหญ่มีของเทียบเท่าแบบโฮสต์เอง (Forgejo Actions, การดีพลอยผ่านเว็บฮุกของ Coolify, การแจ้งเตือนของ GlitchTip, n8n สำหรับเชื่อมเวิร์กโฟลว์) แต่การทดแทนไม่ได้เป็นหนึ่งต่อหนึ่งเสมอไป ควรทำต้นแบบของเวิร์กโฟลว์ที่สำคัญที่สุดก่อนจะผูกมัดทีมให้ย้ายระบบ การเชื่อมต่อที่คุณคิดว่ามีอยู่แล้วเป็นธรรมดา คือตัวที่มีโอกาสทำให้คุณประหลาดใจมากที่สุด

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

สแตกของผู้ดูแลระบบ

สี่ชั้น สี่คำแนะนำ เรียกกันตรง ๆ โค้ด: Forgejo บิลด์และดีพลอย: Coolify ที่จำกัดระนาบผู้ดูแล หรือ Dokku หรือ Compose รัน: Vaultwarden, Uptime Kuma, GlitchTip, Portainer หรือ Dockge เอกสาร: Docmost และ OpenProject (หรือ Plane) เริ่มไพลอตแบบลดทอนที่ 8 GB และสแตกบน Forgejo แบบครบชุดที่ 16 GB แล้วเพิ่มกำลังสำหรับ GitLab การบิลด์พร้อมกันหลายงาน ฐานข้อมูลที่หนักขึ้น หรือภาระแอปพลิเคชันที่ต่อเนื่อง

หากคุณกำลังย้ายระบบ ให้เริ่มจาก Uptime Kuma และบริการภายในที่ไม่สำคัญมาก ทั้งสองอย่างเป็นวิธีเรียนรู้จังหวะการดูแลระบบ (การอัปเดต การมอนิเตอร์ การตรวจสอบข้อมูลสำรอง และการต่ออายุใบรับรอง) ด้วยความเสี่ยงที่ต่ำกว่า ก่อนจะย้ายเวิร์กโฟลว์ของทีมหรือคลังข้อมูลรับรอง อย่าให้ Vaultwarden เป็นการติดตั้งทดสอบตัวแรก ให้ย้ายมันหลังจากมีข้อมูลสำรองที่เข้ารหัสไว้นอกเครื่อง ผ่านการทดสอบกู้คืนสำเร็จ จำกัดสิทธิ์ผู้ดูแล และเปิดการยืนยันตัวตนหลายชั้นเรียบร้อยแล้วเท่านั้น เมื่อจังหวะนั้นเชื่อถือได้แล้ว จึงค่อยย้ายไป Forgejo ตามด้วย Coolify แล้วจึงที่เหลือ

สำหรับทีมที่เลือก GitLab CE โดยเฉพาะ ให้ตัดสินใจว่า CI/CD ในตัวของมันแทนที่รันเนอร์แยกได้หรือไม่ หรือภาระงานของคุณยังต้องมีกำลังบิลด์เฉพาะทางอยู่

คำถามที่พบบ่อย

ทางเลือกแบบโฮสต์เองที่ดีที่สุดแทน Gitea ในปี 2026 คืออะไร?

Forgejo คือตัวเลือกที่แนะนำสำหรับผู้เริ่มโฮสต์เองในปี 2026 การโอนเครื่องหมายการค้าและโดเมนของ Gitea ให้บริษัทแสวงหากำไรในเดือนตุลาคม 2022 โดยไม่ได้รับความเห็นชอบจากชุมชนก่อน คือสิ่งที่จุดชนวนให้เกิดการแยกสาย Forgejo ในปลายปี 2022 ตั้งแต่ v9.0 เป็นต้นไป รีลีสของ Forgejo ใช้ GPL v3+ ส่วนรีลีสแพตช์รุ่นก่อนอย่าง v8.0 และ v7.0 ยังคงอยู่ภายใต้ MIT ในการใช้งานประจำวัน ความสามารถของทั้งคู่ใกล้เคียงกันมาก

รัน Coolify บนโปรดักชันอย่างปลอดภัยได้ไหมในปี 2026?

ได้ แต่ต้องมีการบำรุงรักษาอย่างต่อเนื่องและป้องกันเป็นชั้น ๆ เท่านั้น ให้รันรีลีสเสถียรล่าสุดที่ผ่านการตรวจแล้ว ติดตามประกาศใหม่ ๆ จำกัดสิทธิ์ของทีม และกันแดชบอร์ดกับ API ไว้หลังไฟร์วอลล์ VPN หรือชั้นการเข้าถึงที่เชื่อถือได้ อย่าถือว่า beta.451, beta.474 หรือระดับแพตช์เก่า ๆ อื่นใดเป็นเส้นแบ่งความปลอดภัยถาวร

สแตกนักพัฒนาแบบโฮสต์เองครบชุดต้องใช้ RAM เท่าไรกันแน่?

สำหรับทีมนักพัฒนา 2 ถึง 3 คน ให้มอง 4 GB เป็นขนาดห้องทดลองสำหรับบริการเบา ๆ ไม่กี่ตัว และ 8 GB เป็นไพลอตแบบลดทอนที่ไม่มี OpenProject, Plane หรือการบิลด์ในเครื่อง ราว 8 vCPU และ RAM 16 GB คือจุดเริ่มต้นที่ใช้งานได้จริงของสแตกบน Forgejo แบบครบชุด เกณฑ์ 8 vCPU/16 GB ของ GitLab ใช้กับตัว GitLab เอง ขณะที่ Sentry แบบโฮสต์เองต้องการ RAM 16 GB บวกสว็อป 16 GB และแนะนำ 32 GB ควรตรวจสอบค่าคอนฟิกสุดท้ายภายใต้สภาพภาระงานจริง

ทำไมจึงเลือก GlitchTip แทน Sentry แบบโฮสต์เอง?

อยู่ที่ช่องว่างด้านทรัพยากรและการดูแลระบบ Sentry แบบโฮสต์เองต้องการ RAM อย่างน้อย 16 GB บวกสว็อป 16 GB และเป็นการติดตั้งขนาดใหญ่หลายบริการ ส่วน GlitchTip แนะนำ 512 MB สำหรับบริการแบบรวมในตัวเดียว ต้องใช้ PostgreSQL และให้ Valkey เป็นทางเลือก มันรับทราฟฟิกจาก Sentry SDK ได้ แต่ความเท่าเทียมของฟีเจอร์ยังไม่ครบ จึงควรทดสอบฟีเจอร์และการเชื่อมต่อที่คุณพึ่งพา

เทียบกับของ SaaS แล้ว สแตกนี้มีต้นทุนจริง ๆ เท่าไร?

ให้มอง 4 GB เป็นขนาดห้องทดลองสำหรับบริการเบา ๆ ไม่กี่ตัว และ 8 GB เป็นไพลอตแบบลดทอนที่ไม่มี OpenProject, Plane หรือการบิลด์ในเครื่อง ราว 8 vCPU และ RAM 16 GB คือจุดเริ่มต้นที่ใช้งานได้จริงของสแตกบน Forgejo แบบครบชุด ที่ราคาพื้นฐานซึ่งประกาศไว้ GitHub Team, Vercel Pro, Sentry Team, Linear Basic และ Notion Plus รวมกันราว 158 ดอลลาร์ต่อเดือนสำหรับสามคน โดยยังไม่รวม 1Password ค่าบริการตามการใช้งาน ภาษี และส่วนเสริม การโฮสต์เองอาจถูกกว่าอย่างมีนัยสำคัญ แต่เวลาของผู้ดูแลและโครงสร้างพื้นฐานสำหรับสำรองข้อมูลคือต้นทุนที่มีอยู่จริง