25 แอปพลิเคชันน่ารันบน Self-hosted VPS ปี 2026

สิ่งที่คุณกำลังสร้าง

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

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

ข้อกำหนดเบื้องต้นและความเป็นจริงที่ต้องทราบ

แอปพลิเคชันทั้งหมดในที่นี้ทำงานบน Ubuntu 24.04 KVM VPS ที่ติดตั้งใหม่โดยใช้สิทธิ์ root หรือ sudo รายการเดียวกันนี้สามารถทำงานบนเครื่องเซิร์ฟเวอร์ในบ้านของคุณได้เช่นกัน และหากคุณกำลังเปรียบเทียบค่าเช่ารายเดือนกับการซื้อ RAM ครั้งเดียว Proxmox ที่บ้านเทียบกับ VPS แบบเช่า จะช่วยคำนวณความคุ้มค่าของฮาร์ดแวร์และพลังงานให้คุณ แอปเกือบทั้งหมดมาในรูปแบบ Docker container ดังนั้นให้ติดตั้ง Docker เพียงครั้งเดียว คุณก็พร้อมสำหรับรายการเกือบทั้งหมดแล้ว (มีข้อยกเว้น 2 รายการคือ Cloudron และ CasaOS ซึ่งติดตั้งลงบนโฮสต์โดยตรงด้วยสคริปต์ของตนเอง โปรดดูส่วนแผงควบคุม):

curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker "$USER"
newgrp docker
docker run --rm hello-world

หากคำสั่ง docker ล้มเหลวด้วย permission denied while trying to connect to the Docker daemon socket แสดงว่าคุณข้ามขั้นตอนการเพิ่มกลุ่มผู้ใช้หรือยังไม่ได้เปิด shell ใหม่ ให้ทำการ log out และ log in ใหม่อีกครั้ง หาก docker compose ส่งค่ากลับมาเป็น docker: 'compose' is not a docker command แสดงว่าคุณกำลังใช้ binary แบบ standalone รุ่นเก่า สคริปต์ด้านบนจะติดตั้ง Compose plugin รุ่นใหม่ ซึ่งคุณต้องเรียกใช้งานด้วย docker compose (ใช้เว้นวรรค ไม่ใช่เครื่องหมายขีดกลาง)

ความเป็นจริง 3 ประการที่กำหนดรูปแบบของเนื้อหาทั้งหมดด้านล่างนี้ ประการแรก RAM คือข้อจำกัด ไม่ใช่ disk หรือ CPU VPS ขนาด 1 GB สามารถรันแอปขนาดเล็กได้เพียงแอปเดียวเท่านั้น ขนาด 4 GB คือจุดที่เหมาะสมที่สุดสำหรับเซิร์ฟเวอร์ที่ต้องการ "self-host หลายบริการ" ส่วนขนาด 2 GB เป็นจุดกึ่งกลางที่น่าอึดอัด ซึ่งผู้เริ่มต้นมักจะพยายามติดตั้งบริการที่สามเข้าไป จนทำให้เกิดภาวะ Out-Of-Memory แบบเงียบๆ และไม่เคยทราบสาเหตุว่าทำไม container ถึงหายไป โดย sudo dmesg จะแสดงบรรทัด Out of memory: Killed process ที่ daemon กลืนหายไป ประการที่สอง บริการใดก็ตามที่เปิดสู่สาธารณะจำเป็นต้องมีชื่อโดเมนและใบรับรอง การใช้ IP เปล่าๆ ทำได้เพียงการทดสอบเท่านั้น และจะใช้งานไม่ได้ทันทีที่คุณต้องการให้แอปบนมือถือหรือเบราว์เซอร์เชื่อถือบริการนั้น ประการที่สาม พอร์ต 2 พอร์ตเป็นตัวกำหนดทางเลือกของคุณ: พอร์ต 80 ขาเข้าต้องเข้าถึงเซิร์ฟเวอร์ได้เพื่อรองรับการตรวจสอบ HTTP-01 certificate challenge (การใช้ DNS-01 challenge จะข้ามขั้นตอนนี้ไปโดยใช้การพิสูจน์สิทธิ์ผ่าน DNS record แทน ซึ่งสะดวกเมื่อพอร์ต 80 ถูกปิด) และพอร์ต 25 ขาออกมักถูกผู้ให้บริการส่วนใหญ่บล็อก ซึ่งเป็นเหตุผลว่าทำไมอีเมลจึงอยู่ในรายการ "สิ่งที่ควรหลีกเลี่ยง" ในตอนท้าย

ไฟล์และรูปภาพ

• Nextcloud ใช้แทน Google Drive, Dropbox และ Google Calendar ได้ในชุดเดียว ควรจัดสรร RAM ไว้ 1–2 GB บวกกับพื้นที่สำหรับไฟล์ของคุณ ข้อควรระวังคือ SQLite เหมาะสำหรับการทดสอบเท่านั้น แต่เป็นกับดักหากใช้ในระดับ production ควรติดตั้งบน PostgreSQL ตั้งแต่การบูตครั้งแรก เพราะการย้ายฐานข้อมูลหลังจากที่มีข้อมูลอยู่แล้วเป็นสาเหตุที่พบบ่อยที่สุดที่ทำให้ Nextcloud เสียหาย คู่มือฉบับเต็ม Nextcloud บน VPS ด้วย Docker, TLS และการสำรองข้อมูล จะช่วยให้คุณตั้งค่าได้อย่างถูกต้องตั้งแต่เริ่มต้น
• Immich ใช้แทน Google Photos ได้อย่างสมบูรณ์ รวมถึงแอปบนโทรศัพท์ที่อัปโหลดรูปภาพจากกล้องอัตโนมัติ และฟีเจอร์ค้นหาใบหน้าและวัตถุ ควรจัดสรร RAM ไว้ 6 GB ซึ่งเอกสารของ Immich ระบุว่าเป็นค่าขั้นต่ำ โดย 8 GB จะทำงานได้ราบรื่นกว่า เนื่องจากคอนเทนเนอร์สำหรับ machine-learning ใช้ทรัพยากรสูง ส่วนพื้นที่ดิสก์ควรเท่ากับขนาดคลังรูปภาพของคุณบวกเพิ่มอีกประมาณยี่สิบเปอร์เซ็นต์สำหรับไฟล์ภาพย่อ (thumbnails) ข้อควรระวังคือ Immich ใช้ระบบ semantic versioning ตั้งแต่รุ่นเสถียรแรกคือ v2.0.0 ในเดือนตุลาคม 2025 ซึ่งจะเก็บการเปลี่ยนแปลงที่อาจทำให้ระบบพังไว้ในเวอร์ชันหลัก (major version) และปัจจุบันได้ก้าวไปสู่ v3 แล้ว ดังนั้นอย่าใช้คำสั่ง pull latest โดยไม่ระบุเวอร์ชัน เพราะอาจทำให้คุณข้ามไปสู่เวอร์ชันหลักถัดไปโดยไม่ตั้งใจ ควรล็อกเวอร์ชันไว้และอ่านบันทึกการเปลี่ยนแปลง (release notes) ก่อนการอัปเกรดทุกครั้ง คู่มือ การโฮสต์คลังรูปภาพ Immich ด้วยตนเอง จะครอบคลุมแนวทางการอัปเกรดที่ปลอดภัย หาก RAM 6 GB เกินกว่าที่เซิร์ฟเวอร์ของคุณมี การเปรียบเทียบ PhotoPrism และ Immich จะช่วยเปรียบเทียบการใช้งานหน่วยความจำจริง แอปบนโทรศัพท์ และคำสั่งสำรองข้อมูลที่จำเป็นสำหรับแต่ละตัวก่อนที่คุณจะตัดสินใจเลือกใช้งาน
• Seafile ใช้แทน Dropbox โดยมีกลไกการซิงค์ที่เร็วที่สุดในบรรดาสามตัวนี้ ควรจัดสรร RAM ไว้ประมาณ 1 GB ข้อควรระวังคือ Seafile จัดเก็บไฟล์ของคุณในรูปแบบ content-addressed blocks ไม่ใช่ไฟล์ปกติบนดิสก์ ดังนั้นคุณจึงไม่สามารถเรียกดูข้อมูลด้วยคำสั่ง ls ได้ และคุณต้องสำรองข้อมูลผ่านเครื่องมือของ Seafile เองเท่านั้น ไม่ใช่การคัดลอกโฟลเดอร์โดยตรง

รหัสผ่าน

• Vaultwarden เป็นเซิร์ฟเวอร์ที่เขียนด้วย Rust ซึ่งมีขนาดเล็กและรองรับโปรโตคอลของ Bitwarden ทำให้สามารถใช้งานแทน Bitwarden เวอร์ชันเสียเงิน, LastPass และ 1Password ได้ โดยแอปและส่วนขยายเบราว์เซอร์อย่างเป็นทางการของ Bitwarden ทั้งหมดสามารถใช้งานร่วมกันได้ทันที ควรจัดสรร RAM ไว้ที่ 100–200 MB และแทบไม่ต้องใช้พื้นที่ดิสก์ ข้อควรระวังคือเซิร์ฟเวอร์นี้เก็บรหัสผ่านทั้งหมดของคุณไว้ ดังนั้นการทำ TLS และการสำรองข้อมูลจึงไม่ใช่ทางเลือก แต่เป็นหัวใจสำคัญ และคุณต้องตั้งค่า ADMIN_TOKEN ให้เป็น Argon2 hash เพราะหากใช้โทเค็นแบบข้อความธรรมดาในไฟล์ compose ของคุณ นั่นหมายถึงรหัสผ่านสำหรับเข้าสู่แผงควบคุมผู้ดูแลระบบของเซิร์ฟเวอร์ ซึ่งสามารถเข้าถึงรายชื่อผู้ใช้ทั้งหมดและเปลี่ยนแปลงการตั้งค่าเซิร์ฟเวอร์ได้ หากไฟล์ดังกล่าวถูกอ่านโดยผู้อื่น ข้อมูลทั้งหมดจะถูกเปิดเผย คู่มือ โปรแกรมจัดการรหัสผ่าน Vaultwarden เป็นจุดเริ่มต้นที่ดีที่สุดสำหรับการทำ self-host

สื่อบันเทิง

• Jellyfin ใช้แทน Plex และ Netflix สำหรับคลังสื่อส่วนตัวของคุณ เป็นซอฟต์แวร์โอเพนซอร์สเต็มรูปแบบ ไม่ต้องมีบัญชี และไม่มีการจำกัดการสตรีมระยะไกลด้วยระบบจ่ายเงิน ใช้ RAM ประมาณ 1–2 GB ในสถานะ idle แต่ CPU จะทำงานหนักมากเมื่อมีการ transcode ข้อควรระวังคือการทำ software transcoding สำหรับสตรีม 4K จะทำให้ VPS ขนาดเล็กทำงานไม่ไหว คุณควรจัดเตรียม hardware acceleration ให้กับเซิร์ฟเวอร์ หรือเก็บไฟล์ในรูปแบบที่ไคลเอนต์เล่นได้โดยตรง (Direct Play) เพื่อให้เซิร์ฟเวอร์ทำหน้าที่เพียงแค่ส่งข้อมูลเท่านั้น คู่มือ การติดตั้ง Jellyfin media server บน VPS จะอธิบายความแตกต่างของทั้งสองวิธี เมื่อติดตั้งเสร็จแล้ว Halcyon จะเปลี่ยนคลังสื่อนั้นให้กลายเป็นร้านเช่าวิดีโอยุค 90 ที่เดินเลือกได้ บนเบราว์เซอร์ ซึ่งเป็นวิธีที่แปลกใหม่และได้ผลที่สุดในการทำให้คนในบ้านหันมาเลือกดูสื่อจากชั้นวางแทนการเลื่อนผ่านทุกอย่างไปเรื่อยๆ
• Navidrome ใช้แทน Spotify สำหรับคลังเพลงส่วนตัวของคุณ โดยสตรีมไปยังแอปใดก็ได้ที่รองรับโปรโตคอล Subsonic ใช้ RAM ประมาณ 150–300 MB เนื่องจากเขียนด้วยภาษา Go จึงกินทรัพยากรน้อยมาก ข้อควรระวังคือการสแกนคลังเพลงครั้งแรกจะอ่านแท็กจากทุกไฟล์ ซึ่งอาจใช้เวลาเป็นชั่วโมงหากมีคลังเพลงขนาดใหญ่ และหากแท็ก ID3 ไม่ถูกต้อง ประสบการณ์การใช้งานก็จะแย่ตามไปด้วย
• Audiobookshelf ใช้แทน Audible และแอปพอดแคสต์ของคุณ โดยสามารถซิงค์ตำแหน่งการเล่นข้ามอุปกรณ์ได้ ใช้ RAM ประมาณ 200–500 MB ข้อควรระวังคือระบบต้องการโครงสร้างโฟลเดอร์แบบหนึ่งโฟลเดอร์ต่อหนึ่งหนังสือ หากนำเข้าไฟล์จากโฟลเดอร์ที่จัดระเบียบไม่ดี จะทำให้คลังสื่อแสดงผลผิดพลาดและตรวจพบไฟล์ไม่ครบ ซึ่งแก้ไขได้ยากในภายหลัง

ระบบอัตโนมัติและ AI

• n8n ใช้แทน Zapier และ Make ด้วยเครื่องมือสร้างเวิร์กโฟลว์แบบ visual ที่คุณเป็นเจ้าของเอง และไม่มีการคิดค่าบริการราย task โดยใช้ RAM ประมาณ 400 MB–1 GB ข้อควรระวังคือ n8n จะเข้ารหัสข้อมูลรับรอง (credentials) ที่บันทึกไว้ด้วยคีย์ที่สร้างขึ้นในการรันครั้งแรก หากคุณทำคีย์นั้นหายหรือลืมตั้งค่า N8N_ENCRYPTION_KEY แล้วปล่อยให้ระบบสร้างคีย์ใหม่ ข้อมูลรับรองที่บันทึกไว้ทั้งหมดจะอ่านไม่ได้และคุณจะต้องกรอกข้อมูลใหม่ทั้งหมด คู่มือ การติดตั้ง n8n บนเซิร์ฟเวอร์ตนเองพร้อม HTTPS จะแนะนำการตรึงคีย์และติดตั้งใบรับรองจริงไว้หน้า URL ของ webhook
• Ollama ใช้แทนการสมัครสมาชิก ChatGPT สำหรับการรัน LLM แบบส่วนตัวภายในเครื่อง การจัดสรร RAM ขึ้นอยู่กับโมเดล: โมเดลขนาด 7–8B ต้องการ RAM ประมาณ 8 GB ส่วนขนาดไฟล์บนดิสก์ขึ้นอยู่กับระดับ quantization โดยทั่วไปจะอยู่ที่ประมาณ 4 ถึง 5 GB สำหรับการดาวน์โหลดแบบ 4-bit และ 13 GB ขึ้นไปสำหรับรุ่น fp16 ที่มีความละเอียดเต็ม ข้อควรระวังคือบน VPS ที่ใช้เฉพาะ CPU การประมวลผลจะทำงานได้จริงแต่ช้า โดยจะเป็นระดับคำต่อวินาที ไม่ใช่การตอบโต้ทันทีเหมือนการใช้ API ที่โฮสต์ไว้ ดังนั้นควรตั้งความคาดหวังให้เหมาะสมหรือเช่าเซิร์ฟเวอร์ที่มี GPU คู่มือ การรัน Ollama เพื่อโฮสต์ LLM ด้วยตนเอง มีตัวเลขการใช้งานที่สมจริงให้ดูเป็นแนวทาง

การสื่อสาร

• Rocket.Chat ใช้แทน Slack สำหรับทีม โดยรองรับการสนทนาแบบเธรด, การโทร และการเชื่อมต่อกับบริการอื่น ควรจัดสรร RAM ไว้ที่ 2 GB ขึ้นไป เนื่องจากทำงานบน MongoDB ซึ่งเป็นส่วนที่ใช้ทรัพยากรสูง ข้อควรระวังคือ Rocket.Chat แต่ละเวอร์ชันหลักรองรับ MongoDB เพียงบางเวอร์ชันเท่านั้น (เช่น 8.x ต้องการ MongoDB 8.0 หรือใหม่กว่า ส่วน 7.x ทำงานบน 6.0 หรือ 7.0) และแนวทางการอัปเกรดของ Rocket.Chat ระบุให้ดำเนินการตามลำดับเวอร์ชันหลัก ดังนั้นการข้ามเวอร์ชันจะทำให้ฐานข้อมูลของคุณมีปัญหา จึงควรทยอยอัปเกรดทีละขั้น คู่มือ Rocket.Chat ด้วย Docker Compose จะอธิบายขั้นตอนการไล่ระดับเวอร์ชันไว้
• Matrix (Synapse) ใช้แทน Slack และ Discord โดยเป็นเครือข่ายแบบกระจายศูนย์ (federated) ที่มีการเข้ารหัสแบบ end-to-end ซึ่งคุณเป็นเจ้าของ homeserver เอง ควรจัดสรร RAM ไว้ที่ 1–2 GB และจะเพิ่มขึ้นเมื่อคุณเข้าร่วมห้องสาธารณะขนาดใหญ่ ข้อควรระวังคือการใช้หน่วยความจำของ Synapse จะพุ่งสูงขึ้นในห้องที่มีการเชื่อมต่อแบบ federated ขนาดใหญ่ และจำเป็นต้องรันบน PostgreSQL เท่านั้น ส่วน SQLite ที่เป็นค่าเริ่มต้นจะใช้ได้เฉพาะการทดสอบสำหรับผู้ใช้คนเดียวและจะล่มทันทีเมื่อมีการเชื่อมต่อแบบ federated หาก Synapse กินทรัพยากรมากเกินไป คุณสามารถใช้เซิร์ฟเวอร์อย่าง Conduit หรือ Dendrite ซึ่งเบากว่าและใช้โปรโตคอลเดียวกันได้

การเชื่อมต่อเครือข่ายและการเข้าถึง

• WireGuard ใช้แทน VPN เชิงพาณิชย์ โดยสร้างอุโมงค์ส่วนตัวไปยัง IP ของคุณและบริการอื่นๆ ของคุณ ใช้ทรัพยากรน้อยมาก ไม่ถึง 50 MB และการเข้ารหัสทำงานในระดับ kernel ข้อควรระวัง: บนระบบ virtualization แบบ container (OpenVZ, LXC บางตัว) โมดูลจะทำงานล้มเหลวด้วย RTNETLINK answers: Operation not supported ดังนั้นคุณควรใช้ KVM คู่มือ การทำ self-hosted WireGuard VPN คือแหล่งอ้างอิงหลัก และการจับคู่กับบริการที่ผูกไว้กับอุโมงค์นี้คือวิธีที่คุณจะแยกบริการต่างๆ ออกจากอินเทอร์เน็ตสาธารณะโดยสิ้นเชิง หากคุณไม่ต้องการแก้ไขไฟล์ config ของ peer สำหรับอุปกรณ์ใหม่ทุกครั้ง การรัน Tailscale subnet router บน VPS จะช่วยประกาศช่วง IP ส่วนตัวทั้งหมดไปยังเครื่องอื่นๆ ของคุณแทน เมื่อคุณอนุมัติเส้นทางและตั้งค่าให้ IP forwarding ทำงานได้หลังการรีบูต
• Traefik ใช้แทนการเขียน virtual host ของ nginx ด้วยตนเองและการต่ออายุใบรับรองแบบ manual โดยจะค้นหา container ของคุณผ่าน Docker labels และดึงใบรับรองจาก Let's Encrypt โดยอัตโนมัติ ใช้ RAM ประมาณ 100 MB ข้อควรระวัง: รูปแบบการตั้งค่าผ่าน label อาจสร้างความสับสนในช่วงแรก และหากใส่ label ผิดเพียงจุดเดียว แอปจะไม่ถูกกำหนดเส้นทางโดยไม่มีข้อความแจ้งเตือนที่ชัดเจน คู่มือ Traefik reverse proxy สำหรับแอป Docker หลายตัว ถูกสร้างขึ้นมาเพื่อการรันแอปหลายตัวในหน้านี้ไว้หลังจุดเชื่อมต่อเดียวโดยเฉพาะ
• AdGuard Home ใช้แทน Pi-hole และบริการกรอง DNS แบบเสียเงิน โดยบล็อกโฆษณาและตัวติดตามสำหรับทุกอุปกรณ์ในเครือข่ายของคุณที่ระดับ DNS ใช้ RAM ประมาณ 100–150 MB ข้อควรระวัง: โปรแกรมต้องการใช้งานพอร์ต 53 ซึ่งจะชนกับ systemd-resolved บน Ubuntu ทำให้เริ่มทำงานไม่ได้ด้วย listen udp 0.0.0.0:53: bind: address already in use จนกว่าคุณจะปลดล็อกพอร์ตนั้นก่อน

การตรวจสอบระบบ (Monitoring)

• Uptime Kuma ใช้แทน Pingdom, UptimeRobot และ StatusPage ได้ โดยมีแดชบอร์ดที่สะอาดตาและระบบแจ้งเตือนไปยังช่องทางต่างๆ เกือบทุกรูปแบบ ใช้ RAM ประมาณ 150–300 MB ข้อควรระวังที่คนมักมองข้ามคือ คุณควรตรวจสอบเซิร์ฟเวอร์ production จากเซิร์ฟเวอร์ คนละเครื่องกัน เพราะหาก Uptime Kuma ทำงานอยู่บนเซิร์ฟเวอร์เดียวกับที่มันคอยตรวจสอบ มันจะไม่สามารถแจ้งเตือนคุณได้เมื่อเซิร์ฟเวอร์นั้นล่ม คู่มือ การตรวจสอบสถานะด้วย Uptime Kuma ได้อธิบายถึงการติดตั้งไว้บนเครื่องภายนอก
• Zabbix ใช้แทน Datadog และชุดซอฟต์แวร์ตรวจสอบระดับองค์กร โดยให้ข้อมูลเชิงลึกผ่าน agent, ระบบทริกเกอร์ และประวัติการทำงาน ใช้ RAM ตั้งแต่ 2 GB ขึ้นไปและต้องมีฐานข้อมูลของตัวเอง ข้อควรระวังคือ Zabbix มีประสิทธิภาพสูงและติดตั้งค่อนข้างซับซ้อน จึงถือว่าเกินความจำเป็นหากคุณมีเพียงแค่ 3 คอนเทนเนอร์ แต่จะเป็นเครื่องมือที่เหมาะสมเมื่อคุณมีโครงสร้างพื้นฐานขนาดใหญ่ ให้เริ่มจาก Uptime Kuma ก่อน แล้วค่อยขยับขยายไปใช้ เซิร์ฟเวอร์ตรวจสอบ Zabbix เมื่อคุณมีโครงสร้างพื้นฐานที่ต้องดูแลจริงจัง

Prometheus และ Grafana ถูกตัดออกจากรายการนี้โดยตั้งใจ เนื่องจากแม้จะเป็นเครื่องมือระดับกลุ่มเซิร์ฟเวอร์ที่ยอดเยี่ยม แต่การติดตั้งและปรับแต่งนั้นกินทรัพยากรเกินความจำเป็นสำหรับระบบส่วนตัวที่มีเพียง 2 หรือ 3 เครื่อง ในขณะที่ Uptime Kuma และ Zabbix สามารถตอบโจทย์เดียวกันได้ในสเกลนี้โดยมีภาระในการดูแลรักษาน้อยกว่า

แดชบอร์ดและแผงควบคุม

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

• Cloudron เปลี่ยนความต้องการ "อยากให้ติดตั้งได้ในคลิกเดียว" ให้เป็นจริงด้วย App Store ที่ขัดเกลามาอย่างดี พร้อมระบบ TLS อัตโนมัติและการสำรองข้อมูลในตัว ควรเตรียม RAM อย่างน้อย 2 GB และจะทำงานได้ราบรื่นที่ 4 GB ข้อควรระวังคือซอฟต์แวร์นี้มีความเฉพาะตัวสูงและต้องการควบคุมเซิร์ฟเวอร์ทั้งหมด โดยติดตั้งลงบน Ubuntu ที่ติดตั้งใหม่ผ่านสคริปต์ cloudron-setup ของตนเองแทนที่จะเป็นคอนเทนเนอร์ เอกสารระบุชัดเจนว่าไม่รองรับ ARM, LXC, Docker และ OpenVZ นอกจากนี้ยังใช้งานฟรีได้สูงสุดเพียง 2 แอปพลิเคชัน หากเกินกว่านั้นจะเป็นผลิตภัณฑ์แบบเสียค่าใช้จ่าย
• CasaOS เปลี่ยนแดชบอร์ด homelab ที่ยุ่งเหยิงให้เป็นตารางแอปพลิเคชันที่ใช้งานง่าย ฟรี และมีน้ำหนักเบา ติดตั้งลงบนโฮสต์ด้วยสคริปต์ของตนเอง (curl -fsSL https://get.casaos.io | sudo bash) ไม่ใช่ในรูปแบบคอนเทนเนอร์ จากนั้นจึงรันแอปพลิเคชันของคุณผ่าน Docker ควรเตรียม RAM ประมาณ 150 ถึง 300 MB สำหรับตัว CasaOS เอง ข้อควรระวังคือซอฟต์แวร์นี้ออกแบบมาสำหรับเครือข่ายภายในบ้านที่เชื่อถือได้และไม่ได้ปรับแต่งความปลอดภัยสำหรับการใช้งานบนอินเทอร์เน็ตสาธารณะ ห้ามเปิดเผยพอร์ตสู่สาธารณะโดยตรง ควรเข้าถึงผ่าน WireGuard เท่านั้น
• Coolify ทำหน้าที่แทน Heroku, Vercel และ Netlify โดยรองรับการ deploy ผ่าน git-push, การจัดการฐานข้อมูล และการดูตัวอย่างแอปบนเซิร์ฟเวอร์ของคุณเอง ควรเตรียม RAM อย่างน้อย 2 GB ข้อควรระวังคือเป็นโปรเจกต์ที่ยังใหม่และมีการพัฒนาอย่างรวดเร็ว ดังนั้นควรล็อกเวอร์ชันและอ่านบันทึกการอัปเดต (release notes) ก่อนทำการอัปเกรด การเปรียบเทียบ Cloudron กับ CasaOS และ Coolify จะช่วยสรุปว่าเครื่องมือใดในสามตัวนี้ที่เหมาะสมกับความต้องการของคุณมากที่สุด

เครื่องมือสำหรับนักพัฒนาและเพิ่มประสิทธิภาพการทำงาน

• Gitea (หรือ Forgejo) ใช้แทน GitHub สำหรับ private repository, issues และ CI โดยจัดสรร RAM ไว้ที่ 200–500 MB ข้อควรระวัง: Forgejo เป็น fork ของ Gitea ที่บริหารจัดการโดยชุมชนและเป็นตัวเลือกที่หลายคนแนะนำในปัจจุบัน ทั้งสองตัวเป็นซอฟต์แวร์ที่ดีเยี่ยม ให้เลือกใช้ตัวใดตัวหนึ่งและสำรองข้อมูลทั้ง repository และ ฐานข้อมูลไปพร้อมกัน การสำรองข้อมูลเฉพาะ repo โดยไม่มีฐานข้อมูลจะทำให้ข้อมูล issues และ pull request ทั้งหมดสูญหาย
• Paperless-ngx ใช้แทนตู้เก็บเอกสารและเครื่องสแกนเอกสารแบบเสียค่าใช้จ่าย โดยทำ OCR เอกสารทุกฉบับเพื่อให้ค้นหาได้ จัดสรร RAM ไว้ประมาณ 1 GB และอาจมีการใช้ CPU สูงในช่วงที่ทำ OCR ข้อควรระวัง: ผลลัพธ์ของ OCR ขึ้นอยู่กับคุณภาพการสแกนของคุณ และการประมวลผลเอกสารจำนวนมากย้อนหลังจะใช้เวลานาน ควรปรับแต่งค่าให้เหมาะสมก่อนนำเข้าเอกสารย้อนหลังสิบปีในคราวเดียว
• Actual Budget ใช้แทน YNAB และ Mint ที่ปิดตัวไปแล้ว โดยเป็นระบบจัดการงบประมาณแบบซองที่รวดเร็ว ทำงานในเครื่อง และมีความเป็นส่วนตัว จัดสรร RAM ไว้ประมาณ 150 MB ข้อควรระวัง: ระบบซิงค์ธนาคารอัตโนมัติมีมาให้ในตัวแต่เป็นทางเลือกเสริม โดยจะทำงานได้ก็ต่อเมื่อคุณสมัครใช้บริการกับผู้ให้บริการในภูมิภาค เช่น SimpleFIN Bridge หรือ Enable Banking และเพิ่ม API credentials ของคุณเอง ดังนั้นหากใช้งานทันทีหลังติดตั้ง คุณจะต้องนำเข้าข้อมูลธุรกรรมด้วยตนเอง
• FreshRSS ใช้แทน Feedly และ Google Reader ที่เลิกให้บริการไปแล้ว เป็นโปรแกรมอ่านฟีดที่รวดเร็ว เป็นส่วนตัว และมีแอปบนมือถือ จัดสรร RAM ไว้ประมาณ 150 MB ข้อควรระวัง: ต้องตั้งค่าการรีเฟรชฟีดผ่าน cron มิฉะนั้นฟีดจะอัปเดตเฉพาะตอนที่คุณเปิดหน้าเว็บเท่านั้น
• BookStack ใช้แทน Notion และ Confluence สำหรับทำเอกสาร โดยจัดระเบียบเป็นชั้นวาง หนังสือ และหน้ากระดาษ จัดสรร RAM ไว้ประมาณ 500 MB บน PHP และ MySQL ข้อควรระวัง: โปรแกรมมีโครงสร้างเนื้อหาในแบบของตัวเอง ไม่ใช่การจดบันทึกแบบอิสระ ซึ่งบางคนอาจชอบแต่บางคนอาจรู้สึกว่าแข็งตัวเกินไป ควรทดลองใช้งานก่อนตัดสินใจย้ายข้อมูล wiki ทั้งหมดของคุณไปไว้ที่นั่น
• Home Assistant ใช้แทน SmartThings และแอปจากผู้ผลิตหลายราย โดยรวมศูนย์ระบบบ้านอัจฉริยะของคุณไว้ภายในเครือข่าย จัดสรร RAM ไว้ประมาณ 1 GB ข้อควรระวัง: ความสามารถส่วนใหญ่ต้องการการเข้าถึงอุปกรณ์ของคุณผ่านเครือข่ายภายใน ดังนั้นจึงเหมาะกับการรันบนฮาร์ดแวร์ที่บ้านมากกว่าบน VPS ระยะไกล หากจำเป็นต้องใช้งาน dashboard จากภายนอก ให้ใช้วิธีเชื่อมต่อกลับเข้ามาแทน

การติดตั้งตัวอย่าง

เพื่อให้เห็นภาพชัดเจน นี่คือโครงสร้างทั้งหมดของการทำ self-host ซึ่งประกอบด้วยไฟล์ compose, ใบรับรองจริง และการสำรองข้อมูล ตัวอย่างนี้ใช้ Uptime Kuma แต่แอปพลิเคชันทุกตัวในรายการล้วนใช้รูปแบบเดียวกัน

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    volumes:
      - ./data:/app/data
    ports:
      - "127.0.0.1:3001:3001"
    restart: unless-stopped

docker compose up -d
docker compose logs -f

โปรดสังเกต 127.0.0.1: แอปพลิเคชันจะฟังเฉพาะที่ localhost เท่านั้น และมี reverse proxy เช่น Traefik หรือ nginx ทำหน้าที่จัดการ TLS termination อยู่ด้านหน้า การผูกพอร์ตโดยตรงกับ 0.0.0.0:3001 เป็นสาเหตุที่ทำให้ผู้ใช้งานเผลอเปิดเผยแผงควบคุมผู้ดูแลระบบที่ไม่มีการเข้ารหัสออกสู่สาธารณะบนอินเทอร์เน็ตโดยไม่ตั้งใจ

สิ่งที่ยังไม่ควรทำ self-host

• อีเมล นี่คือเรื่องจริงที่ต้องบอกกันตรงๆ พอร์ตขาออก 25 มักถูกบล็อกโดยผู้ให้บริการ VPS ส่วนใหญ่ คุณจะพบกับ Connection timed out จาก telnet aspmx.l.google.com 25 ซึ่งไม่มีอะไรให้คุณแก้ไขได้ที่ฝั่งของคุณ เพราะเป็นนโยบายของผู้ให้บริการ ผู้ให้บริการบางรายอาจปลดล็อกให้หากคุณร้องขอ (เช่น AWS ที่อนุญาตให้คุณส่งคำขอเพื่อยกเลิกข้อจำกัดนี้) แต่นั่นเป็นเพียงการส่งคำขอ ไม่ใช่การกดสวิตช์เปิดใช้งานทันที แม้ว่าจะเปิดพอร์ต 25 ได้แล้ว แต่ IP ใหม่ที่ไม่มีชื่อเสียง รวมถึงการตั้งค่า PTR record, SPF, DKIM และ DMARC ที่ไม่สมบูรณ์ จะทำให้อีเมลของคุณไปอยู่ในถังขยะหรือถูกปฏิเสธทันที นี่เป็นงานที่ต้องทำอย่างต่อเนื่องและจริงจัง ไม่ใช่แค่โปรเจกต์ทำเล่นในช่วงสุดสัปดาห์ หากคุณตั้งใจจะทำจริงๆ ให้เตรียมตัวให้พร้อมโดยใช้คู่มือ การทำ self-hosted email ด้วย Mailcow และเตรียมใจที่จะต้องคอยดูแลเรื่องการส่งอีเมลไปอีกหลายเดือน
• สิ่งที่คุณไม่สามารถสำรองข้อมูลและกู้คืนได้อย่างน่าเชื่อถือ หากคุณไม่เคยทดสอบการกู้คืนข้อมูล คุณไม่ได้มีข้อมูลสำรอง คุณมีเพียงแค่ความหวังเท่านั้น อย่าเก็บข้อมูลที่ไม่สามารถหาทดแทนได้ เช่น สำเนาภาพถ่ายชุดเดียวของคุณ หรือบัญชีผู้ใช้ ไว้ในบริการใดๆ จนกว่าจะพิสูจน์ได้ว่าการกู้คืนข้อมูลนั้นทำได้จริง
• สำเนาชุดเดียวของบริการที่เป็นหัวใจสำคัญ การทำ self-hosted DNS server ที่เมื่อเกิดการล่มแล้วทำให้เครือข่ายทั้งระบบของคุณใช้งานอินเทอร์เน็ตไม่ได้ ไม่ใช่โปรเจกต์เริ่มต้นที่ดี ควรมี upstream สำรองไว้เสมอ
• ระบบความปลอดภัยแบบเรียลไทม์ สัญญาณเตือนภัยในบ้าน ระบบแจ้งเตือนทางการแพทย์ หรือสิ่งใดก็ตามที่การหยุดทำงานเพียง 5 นาทีถือเป็นปัญหาใหญ่ ไม่ควรนำมาไว้บนเซิร์ฟเวอร์งานอดิเรกที่คุณคอยอัปเกรดในคืนวันอาทิตย์

วิธีการเลือกแอปแรกของคุณ และสองสิ่งที่ห้ามต่อรอง

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

มีสองสิ่งที่ห้ามต่อรองสำหรับทุกแอปที่กล่าวมาข้างต้น โดยไม่มีข้อยกเว้น:

1. ต้องใช้ TLS สำหรับทุกบริการที่เปิดสู่สาธารณะ บริการที่เข้าถึงผ่าน IP โดยตรงและเป็น plaintext ถือเป็นเพียงตัวอย่างทดลอง ไม่ใช่การใช้งานจริง ให้ติดตั้ง certificate จริงไว้หน้าบริการนั้นด้วย Certbot และ Let's Encrypt บน nginx หรือปล่อยให้ Traefik จัดการโดยอัตโนมัติ จากนั้นเพิ่มความปลอดภัยที่ด่านหน้าด้วย Fail2ban สำหรับ SSH บน Ubuntu 24.04
2. การสำรองข้อมูลที่คุณเคยทดสอบกู้คืนจริง ให้ทำระบบสำรองข้อมูลอัตโนมัติทุกคืน โดยรวมทั้งฐานข้อมูลและ volume ข้อมูลเข้าด้วยกัน ส่งข้อมูลออกไป นอกเซิร์ฟเวอร์ และทดสอบกู้คืนลงใน VPS ชั่วคราวเดือนละครั้งเพื่อพิสูจน์ว่าใช้งานได้จริง วันที่ดิสก์ของคุณพังไม่ใช่เวลาที่ควรจะมาพบว่าไฟล์สำรองข้อมูลนั้นว่างเปล่า

หากคุณทำสองสิ่งนี้ได้ถูกต้อง การทำ self-hosting จะเป็นเรื่องที่น่าพึงพอใจ แต่หากละเลยไป มันก็เป็นเพียงการนับถอยหลังสู่ความล้มเหลวเท่านั้น

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

FAQ

ควรเริ่ม self-host อะไรเป็นอย่างแรก?

Vaultwarden โปรแกรมจัดการรหัสผ่านให้ประโยชน์กับคุณได้ทุกวัน ทดแทนการสมัครสมาชิก และบังคับให้คุณเรียนรู้กระบวนการทำงานทั้งหมด ทั้ง Docker, reverse proxy, TLS และการสำรองข้อมูล โดยเป็นแอปที่มีขนาดเล็กพอที่จะสร้างใหม่ได้ในสิบนาทีหากเกิดข้อผิดพลาด Uptime Kuma เป็นตัวเลือกที่สองที่ดี เพื่อให้คุณทราบถึงปัญหาของระบบก่อนที่ผู้ใช้งานของคุณจะพบ

จริงๆ แล้วต้องใช้ VPS ขนาดเท่าใด?

สำหรับแอปขนาดเล็กหนึ่งตัว RAM 1 GB ก็เพียงพอ สำหรับเซิร์ฟเวอร์ที่รันหลายบริการได้อย่างสบายๆ ให้ตั้งเป้าไว้ที่ 4 GB ส่วนขนาด 2 GB เป็นช่วงที่ผู้ใช้มักเจอปัญหา container ถูกสั่งปิดโดยระบบเนื่องจากหน่วยความจำไม่พอ (Out-Of-Memory) โดยไม่ทราบสาเหตุ RAM มักเป็นข้อจำกัดหลักเกือบทุกครั้ง ให้เพิ่มพื้นที่ดิสก์ตามปริมาณข้อมูลที่คุณวางแผนจะจัดเก็บ และคาดการณ์ไว้ว่า Immich, Ollama และแอปใดก็ตามที่มีฐานข้อมูลขนาดใหญ่จะต้องการทรัพยากรทั้งสองส่วนนี้มากที่สุด

อะไรที่ไม่ควร self-host?

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

จำเป็นต้องใช้ Docker สำหรับทุกอย่างนี้หรือไม่?

ไม่จำเป็น แต่คุณควรใช้ แอปทุกตัวในรายการนี้ยกเว้น Cloudron และ CasaOS มี Docker image ให้ใช้งาน ส่วนสองตัวนั้นจะติดตั้งลงบนโฮสต์โดยตรงด้วยสคริปต์ของตัวเองแล้วจึงรันแอปใน container ให้คุณ สำหรับตัวอื่นๆ Docker ช่วยให้คุณติดตั้งได้สะอาด ลบออกได้ง่าย กำหนดเวอร์ชันได้แม่นยำ และย้ายไปยังโฮสต์ใหม่ได้สะดวก แอปบางตัว (WireGuard, Zabbix) สามารถติดตั้งแบบ native ผ่าน apt ได้หากคุณต้องการ เมื่อคุณเข้าใจไฟล์ compose หนึ่งไฟล์ คุณก็จะเข้าใจไฟล์อื่นๆ ทั้งหมด ซึ่งเป็นเหตุผลที่ทำให้รายการทั้งหมดนี้เข้าถึงได้ง่าย

จะรักษาความปลอดภัยทั้งหมดนี้ได้อย่างไร?

สี่นิสัยครอบคลุมเกือบทั้งหมด: ใช้ TLS หน้าทุกบริการ, ล็อก SSH ให้เข้าถึงได้เฉพาะการใช้ key เท่านั้นและ Fail2ban เพื่อแบนความพยายามสุ่มรหัสผ่าน, เปิดพอร์ตเฉพาะที่จำเป็นต่อสาธารณะจริงๆ และเข้าถึงส่วนที่เหลือผ่าน WireGuard VPN, และอัปเดตอย่างสม่ำเสมอพร้อมอ่านบันทึกการเปลี่ยนแปลง (release notes) เพื่อไม่ให้การอัปเกรดสร้างความประหลาดใจ การสำรองข้อมูลคือนิสัยที่ห้า ซึ่งเป็นสิ่งที่คุณใช้กู้คืนเมื่อเกิดความผิดพลาดที่หลุดรอดจากสี่ข้อแรกไปได้