แนะนำ 25 แอป Self-host ที่น่าใช้ในปี 2026

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

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

ผมบริหารจัดการ VPS host มา 15 ปี และผมรันแอปส่วนใหญ่เหล่านี้บนเครื่องของผมเอง ดังนั้นตัวเลขทรัพยากรด้านล่างคือสิ่งที่แอปใช้งานจริงภายใต้ workload ขนาดเล็ก ไม่ใช่ค่า "minimum" จากหน้าการตลาด โปรดอ่านค่าเหล่านี้เพื่อใช้เป็นงบประมาณ แล้วเผื่อ headroom ไว้ด้วย

สิ่งที่ต้องเตรียมและโลกความเป็นจริง

ทุกแอปในที่นี้รันบน Ubuntu 24.04 KVM VPS ที่ติดตั้งใหม่โดยมีสิทธิ์ root หรือ sudo เกือบทั้งหมดมาในรูปแบบ Docker container ดังนั้นติดตั้ง Docker เพียงครั้งเดียวคุณก็พร้อมสำหรับทั้งรายการแล้ว:

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 แสดงว่าคุณกำลังใช้ standalone binary รุ่นเก่า; สคริปต์ด้านบนจะติดตั้ง Compose plugin รุ่นใหม่ ซึ่งคุณต้องเรียกใช้งานด้วยคำสั่ง docker compose (ใช้ช่องว่าง ไม่ใช้เครื่องหมาย hyphen)

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

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

• Nextcloud แทนที่ Google Drive, Dropbox และ Google Calendar ในชุดเดียว งบประมาณ RAM 1–2 GB บวกกับขนาดไฟล์ของคุณ ข้อควรระวัง: SQLite เหมาะสำหรับ demo แต่เป็นกับดักในระบบ production — ให้ติดตั้งบน PostgreSQL ตั้งแต่การบูตครั้งแรก เพราะการย้ายฐานข้อมูลหลังจากมีข้อมูลอยู่แล้วเป็นวิธีที่ทำให้ Nextcloud พังบ่อยที่สุด คู่มือ Nextcloud on a VPS with Docker, TLS and backups ฉบับเต็มจะช่วยติดตั้งอย่างถูกต้องตั้งแต่ครั้งแรก
• Immich แทนที่ Google Photos รวมถึงแอปมือถือที่อัปโหลดรูปจาก camera roll อัตโนมัติ และการค้นหาใบหน้าหรือวัตถุ งบประมาณ RAM 6 GB — เอกสารของ Immich ระบุว่าเป็นค่า minimum, 8 GB คือระดับที่ใช้งานได้สบาย และ container machine-learning คือส่วนที่กินทรัพยากรมากที่สุด — รวมถึง disk ที่ต้องมีขนาดเท่ากับ library ของคุณบวกเพิ่มอีกประมาณ 20% สำหรับ thumbnails ข้อควรระวัง: Immich ยังมีการเปลี่ยนแปลงที่ทำให้ระบบพัง (breaking changes) ระหว่างเวอร์ชัน ดังนั้นอย่าสั่ง latest โดยไม่ตรวจสอบ; ให้ระบุเวอร์ชันที่แน่นอน (pin version) และอ่าน release notes ก่อนอัปเกรดทุกครั้ง คู่มือ self-hosted Immich photo library จะครอบคลุมเส้นทางการอัปเกรดที่ปลอดภัย
• Seafile แทนที่ Dropbox ด้วย engine การซิงค์ที่เร็วที่สุดในสามตัวเลือก งบประมาณ RAM ประมาณ 1 GB ข้อควรระวัง: Seafile เก็บไฟล์ของคุณในรูปแบบ content-addressed blocks ไม่ใช่ไฟล์ธรรมดาบน disk ดังนั้นคุณไม่สามารถเรียกดูข้อมูลด้วย ls ได้ และคุณต้องสำรองข้อมูลผ่านเครื่องมือของ Seafile เอง ไม่ใช่การคัดลอกโฟลเดอร์

รหัสผ่าน

• Vaultwarden แทนที่ Bitwarden แบบเสียเงิน, LastPass และ 1Password ด้วย Rust server ขนาดเล็กที่รองรับโปรโตคอลของ Bitwarden ดังนั้นแอป Bitwarden และ browser extension อย่างเป็นทางการทุกตัวจะใช้งานได้ทันที งบประมาณ RAM 100–200 MB และแทบไม่ใช้ disk เลย ข้อควรระวัง: เครื่องนี้เก็บรหัสผ่านทั้งหมดของคุณ ดังนั้น TLS และการสำรองข้อมูลจึงไม่ใช่ทางเลือกแต่เป็นสิ่งจำเป็น — และให้ตั้งค่า ADMIN_TOKEN เป็น Argon2 hash เพราะการใช้ plaintext token ใน compose file เปรียบเสมือนการวางกุญแจหลักไว้ในรูปแบบที่อ่านออกได้ทันที คู่มือ Vaultwarden password manager เป็นการเริ่มต้น self-host ที่ดีที่สุดเท่าที่เป็นไปได้

สื่อ (Media)

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

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

• n8n แทนที่ Zapier และ Make ด้วย visual workflow builder ที่คุณเป็นเจ้าของเองและไม่มีการคิดเงินตามจำนวน task งบประมาณ RAM 400 MB–1 GB ข้อควรระวัง: n8n เข้ารหัส credentials ที่เก็บไว้ด้วย key ที่สร้างขึ้นในการรันครั้งแรก หากคุณทำ key นั้นหาย — หรือลืมตั้งค่า N8N_ENCRYPTION_KEY จนทำให้มันสร้างใหม่ — credentials ที่บันทึกไว้ทั้งหมดจะอ่านไม่ได้และคุณต้องกรอกใหม่ทั้งหมด คู่มือ self-hosted n8n with HTTPS จะช่วยล็อก key และติดตั้ง certificate จริงไว้หน้า webhook URLs
• Ollama แทนที่การสมัครสมาชิก ChatGPT เพื่อรัน LLM แบบ local และเป็นส่วนตัว งบประมาณขึ้นอยู่กับ model: model ขนาด 7–8B ต้องการ RAM ประมาณ 8 GB และแต่ละ model ใช้พื้นที่ disk 4–8 GB ข้อควรระวัง: บน VPS ที่มีเฉพาะ CPU การประมวลผลจะช้า — ให้คิดเป็นจำนวนคำต่อวินาที ไม่ใช่การตอบโต้ทันทีเหมือน API ที่โฮสต์ไว้ — ดังนั้นควรตั้งความคาดหวังไว้ หรือเช่าเครื่องที่มี GPU คู่มือ run Ollama to self-host an LLM มีตัวเลขการใช้งานที่สมจริง

การสื่อสาร

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

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

• WireGuard แทนที่ VPN เชิงพาณิชย์ โดยให้ tunnel ส่วนตัวไปยัง IP ของคุณและบริการอื่นๆ งบประมาณแทบไม่มี — ต่ำกว่า 50 MB และการเข้ารหัสทำงานในระดับ kernel ข้อควรระวัง: บน virtualization แบบ container (OpenVZ, LXC บางประเภท) module จะล้มเหลวด้วยข้อผิดพลาด RTNETLINK answers: Operation not supported; คุณควรใช้ KVM คู่มือ self-hosted WireGuard VPN คือข้อมูลอ้างอิง และการใช้คู่กับบริการที่ผูกไว้กับ tunnel คือวิธีรักษาความปลอดภัยไม่ให้ข้อมูลออกสู่ public internet โดยสิ้นเชิง
• Traefik แทนที่การเขียน nginx virtual hosts และการต่ออายุ certificate ด้วยตนเอง — มันจะค้นหา container ของคุณผ่าน Docker labels และดึงใบรับรอง Let's Encrypt มาให้โดยอัตโนมัติ งบประมาณ RAM ประมาณ 100 MB ข้อควรระวัง: โมเดลการตั้งค่าแบบ label อาจทำให้สับสนในตอนแรก และ label ที่ผิดเพียงอันเดียวจะทำให้แอปไม่ถูกส่งเส้นทาง (unrouted) โดยไม่มี error ที่ชัดเจน คู่มือ Traefik reverse proxy for multiple Docker apps ถูกสร้างมาเพื่อรันแอปหลายตัวในหน้านี้ผ่านจุดเข้าใช้งาน (entry point) เดียวกัน
• AdGuard Home แทนที่ Pi-hole และบริการ DNS filtering แบบเสียเงิน โดยบล็อกโฆษณาและ tracker สำหรับทุกอุปกรณ์ในเครือข่ายของคุณที่ระดับ 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 ด้วย dashboard ที่สะอาดตาและแจ้งเตือนผ่านช่องทางต่างๆ งบประมาณ RAM 150–300 MB ข้อควรระวังที่คนมักพลาด: ให้ตรวจสอบเครื่อง production จากเครื่อง อื่น — Uptime Kuma ที่รันบนเซิร์ฟเวอร์เดียวกับที่มันเฝ้าอยู่ ไม่สามารถบอกคุณได้เมื่อเซิร์ฟเวอร์นั้นตาย คู่มือ Uptime Kuma status monitoring ครอบคลุมการติดตั้งแบบภายนอก
• Zabbix แทนที่ Datadog และชุดเครื่องมือ monitoring ระดับองค์กร ด้วยการวัดผลเชิงลึกผ่าน agent, triggers และประวัติการทำงาน งบประมาณ RAM 2 GB ขึ้นไป และต้องมีฐานข้อมูลของตัวเอง ข้อควรระวัง: Zabbix ทรงพลังแต่ติดตั้งยาก — มันเกินความจำเป็นสำหรับการเฝ้าดูแค่ 3 containers แต่เป็นเครื่องมือที่เหมาะสมสำหรับระบบขนาดใหญ่ เริ่มต้นด้วย Uptime Kuma; แล้วค่อยขยับไปใช้ Zabbix monitoring server เมื่อคุณมีโครงสร้างพื้นฐานที่ต้องดูแลจริงๆ

Prometheus และ Grafana ไม่ได้ถูกรวมอยู่ในรายการนี้โดยตั้งใจ: พวกมันเป็นเครื่องมือระดับ fleet ที่ยอดเยี่ยม แต่การรันและปรับแต่งนั้นหนักกว่าการใช้ stack ส่วนตัวที่มีเพียง 2 หรือ 3 เครื่อง และ Uptime Kuma ร่วมกับ Zabbix สามารถตอบโจทย์เดียวกันได้ในสเกลนี้โดยมีภาระการดูแลน้อยกว่า

Dashboard และ Control Panels

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

• Cloudron แทนที่ความต้องการ "อยากให้เป็นแบบคลิกเดียว" ด้วย app store ที่สมบูรณ์แบบ, automatic TLS และการสำรองข้อมูลในตัว งบประมาณ RAM ขั้นต่ำ 2 GB, 4 GB ใช้งานได้สบาย ข้อควรระวัง: มันมีการกำหนดรูปแบบเฉพาะและต้องการควบคุมทั้งเครื่อง และใช้งานฟรีได้สูงสุดเพียงสองแอป — นอกเหนือจากนั้นจะเป็นผลิตภัณฑ์แบบเสียเงิน
• CasaOS แทนที่ dashboard homelab ที่ยุ่งเหยิงด้วย grid แอปที่ใช้งานง่าย ฟรี และน้ำหนักเบา งบประมาณประมาณ 150 ถึง 300 MB สำหรับตัว CasaOS เอง ข้อควรระวัง: มันถูกออกแบบมาสำหรับเครือข่ายในบ้านที่เชื่อถือได้และไม่ได้ถูกทำให้แข็งแกร่ง (hardened) สำหรับ public internet — อย่าเปิดเผยมันสู่สาธารณะโดยตรง; ให้เข้าถึงผ่าน WireGuard
• Coolify แทนที่ Heroku, Vercel และ Netlify — รองรับการ deploy ผ่าน git-push, ฐานข้อมูล และการทำ preview บนเซิร์ฟเวอร์ของคุณเอง งบประมาณ RAM ขั้นต่ำ 2 GB ข้อควรระวัง: เป็นโปรเจกต์ใหม่ที่พัฒนาเร็วมาก ดังนั้นควรระบุเวอร์ชันและอ่าน release notes ก่อนอัปเกรด คู่มือ Cloudron vs CasaOS vs Coolify comparison จะเปรียบเทียบว่าทั้งสามตัวไหนเหมาะกับใคร

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

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

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

เพื่อให้เห็นภาพชัดเจน นี่คือรูปแบบทั้งหมดของการทำ self-host: compose file, ใบรับรองจริง และการสำรองข้อมูล นี่คือตัวอย่างของ 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: — แอปจะฟัง (listen) เฉพาะที่ localhost และ reverse proxy เช่น Traefik หรือ nginx จะทำหน้าที่จัดการ TLS ให้ด้านหน้า การผูกพอร์ตตรงกับ 0.0.0.0:3001 คือวิธีที่ทำให้คนเผลอเผยแพร่แผงควบคุมผู้ดูแลระบบที่ไม่มีการเข้ารหัสสู่สาธารณะโดยไม่ตั้งใจ

สิ่งที่ "ไม่ควร" self-host (ในตอนนี้)

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

วิธีเลือกแอปแรก และสองสิ่งที่ขาดไม่ได้

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

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

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

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

ตัวเลือกมีตั้งแต่ระดับใช้งานจริงไปจนถึงระดับที่ดูเกินจริง ตั้งแต่ Minecraft server on a VPS สำหรับครอบครัว ไปจนถึง the world's least efficient datacenter หากคุณต้องการฟังเรื่องราวเตือนใจ

FAQ

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

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

ฉันต้องใช้ VPS ขนาดเท่าไหร่กันแน่?

สำหรับแอปขนาดเล็ก 1 GB RAM ก็เพียงพอแล้ว สำหรับเครื่องที่ใช้งานได้สบายๆ แบบ "รันหลายๆ อย่าง" ให้ตั้งเป้าที่ 4 GB — ช่วง 2 GB คือจุดที่คนมักเจออาการ Out-of-Memory kill แบบเงียบๆ และหาสาเหตุไม่ได้ RAM มักจะเป็นข้อจำกัดเสมอ; ให้เพิ่ม disk ตามปริมาณข้อมูลที่คุณวางแผนจะเก็บ และเตรียมใจไว้ว่า Immich, Ollama และแอปที่มีฐานข้อมูลขนาดใหญ่จะต้องการทรัพยากรทั้งสองอย่างมากที่สุด

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

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

ฉันจำเป็นต้องใช้ Docker สำหรับทั้งหมดนี้ไหม?

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

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

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