ทำไมเราถึงควรทำ Self-hosting?

 (romanzipp.com)
17 คะแนน โดย GN⁺ 2025-10-11 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • การ self-hosting บริการส่วนตัว ช่วยให้หลุดพ้นจากการสอดส่องของบิ๊กเทคและภาครัฐ พร้อมรักษาความเป็นส่วนตัวและอธิปไตยเหนือข้อมูลได้
  • ข้อมูลส่วนบุคคลที่อ่อนไหว เช่น ปฏิทิน รายชื่อผู้ติดต่อ และข้อมูลตำแหน่งที่ตั้ง เปิดเผยข้อมูลได้มากกว่าที่คิด จึงควรจัดการเองโดยไม่ต้องพึ่งบริษัทอย่าง Google หรือ Apple
  • ในสถานการณ์ที่บริษัทเทคโนโลยี ล็อกบัญชีโดยไม่มีเหตุผล หรือบังคับให้ใช้ API แบบปิดแทนโปรโตคอลมาตรฐาน การรันเซิร์ฟเวอร์ของตัวเองบนพื้นฐานของโปรโตคอลมาตรฐานจึงช่วยรับประกันอธิปไตยดิจิทัล
  • แนะนำ บริการ self-hosting ที่ใช้งานได้จริง เช่น เซิร์ฟเวอร์ CalDAV/CardDAV, เมลเซิร์ฟเวอร์, Home Assistant, RSS reader, ตัวติดตามตำแหน่ง พร้อมตัวเลือกซอฟต์แวร์ที่เป็นรูปธรรม
  • แม้การตั้งค่าเริ่มต้นจะซับซ้อน แต่ในระยะยาว การมี อำนาจควบคุมข้อมูล และความเสถียรของบริการเป็นสิ่งสำคัญต่อการคุ้มครองความเป็นส่วนตัวและการพึ่งพาตนเองทางเทคโนโลยี

ทำไมจึงควรเลือก Self-hosting

  • ไม่นานมานี้ฉันแชร์สภาพแวดล้อม Homelab ของตัวเองให้เพื่อนร่วมงานดู แล้วก็ได้รับคำถามว่า “ตกลงทำไมถึงต้องติดตั้งเซิร์ฟเวอร์เอง ตั้งค่าคอนเทนเนอร์เอง และยังต้องเสียเงินกับฮาร์ดแวร์จำนวนมากเพื่อดูแลระบบที่ยุ่งยากแบบนี้ด้วย?”
  • คำถามนี้ทำให้ฉันได้อธิบายอย่างเป็นรูปธรรมถึงแรงจูงใจหลักของการทำ self-hosting และจริง ๆ แล้วมีบริการอะไรบ้างที่เราสามารถ self-host ได้

ความเป็นส่วนตัว

  • ความเป็นส่วนตัวไม่ใช่สิทธิที่ได้มาโดยอัตโนมัติ แต่เป็น สิทธิที่ต้องต่อสู้เพื่อให้ได้มา
  • บริษัทยักษ์ใหญ่ด้านเทคโนโลยีและรัฐบาลบางแห่ง (เช่น chat control ของ EU) ยังคงพยายามสอดส่องชีวิตส่วนตัวของผู้คนอย่างต่อเนื่อง
  • หากโฮสต์บริการด้วยตัวเอง ก็สามารถลดหรือกำจัดความเสี่ยงจากการสอดส่องได้ แต่สิ่งนี้ต้องอาศัย ความรู้ทางเทคนิค
  • เรายังสามารถช่วยให้ครอบครัวหรือคนรู้จักมีอิสระด้านข้อมูลได้ด้วยการให้บริการเหล่านี้แก่พวกเขา

  • ปฏิทิน & รายชื่อผู้ติดต่อ

    • ปฏิทินเปิดเผย ข้อมูลได้มากกว่าที่คิด
      • นอกจากข้อมูลระบุตัวตนแล้ว ยังมีข้อมูลการนัดหมายเป็นประจำ ครอบครัว เพื่อนร่วมงาน และการประชุมทางธุรกิจที่เป็นความลับ
      • ข้อมูลสุขภาพจากนัดพบแพทย์ รวมถึงพฤติกรรมการนอนและการออกกำลังกาย
      • ภาระผูกพันทางกฎหมาย ข้อมูลการเงิน เช่น กำหนดชำระเงินกู้หรือค่าสมาชิก
      • ความเชื่อทางการเมืองจากกำหนดการเข้าร่วมการประท้วง
      • สามารถใช้ดูว่าเมื่อไรเราติดต่อได้ เพื่อเอาไปใช้ในการขโมยตัวตน
    • ข้อมูลรายชื่อผู้ติดต่อก็อ่อนไหวไม่แพ้กัน
      • สามารถอนุมานข้อมูลส่วนบุคคลได้จาก social graph และ metadata (ประวัติการค้นหา วันที่สร้าง)
      • ตัวอย่าง: ถ้าจู่ ๆ มีรายชื่อที่เป็นเพศเดียวกันและมีแค่ชื่อเพิ่มขึ้นมาเยอะ อาจถูกคาดเดาว่ากำลังออกเดตอยู่ หรือการสร้างรายชื่อนักบำบัดก็อาจสื่อว่ากำลังเข้าพบจิตแพทย์
    • คนส่วนใหญ่ไม่ค่อยตระหนักว่า ข้อมูล social graph ถูกเก็บไว้ที่ไหน และในความเป็นจริง Google, Apple, Samsung เป็นต้น เป็นผู้ประมวลผลข้อมูลเหล่านี้
    • แม้แต่ Advanced Data Protection ของ Apple ก็ยัง ไม่ได้เข้ารหัสแบบ end-to-end สำหรับปฏิทินและรายชื่อผู้ติดต่อ

  • ข้อมูลตำแหน่งที่ตั้ง

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

  • อื่น ๆ

    • การไล่เรียงทุกวิธีที่ข้อมูลถูกติดตามและเหตุผลที่เราควรตระหนักถึงเรื่องนี้นั้นเกินขอบเขตของบทความนี้
    • เป้าหมายคือการสร้างแรงจูงใจให้เริ่มต้นการเดินทางครั้งใหม่

อธิปไตย

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

  • ปัญหาการล็อกบัญชี

    • ยังคงมีรายงานกรณีที่บริษัทเทคโนโลยี ล็อกบัญชีโดยไม่มีเหตุผลชัดเจน และฉันเองก็เคยเจอกับ Google มาก่อน
    • ฉันไม่อยากต้องพึ่งความเมตตาของบิ๊กเทคที่แม้แต่จะติดต่อก็ยังไม่ได้ หรือไม่ก็ต้อง ปวดหัวกับ AI chatbot
    • น่าแปลกใจว่าทำไมหน่วยงานกำกับดูแลจึง ไม่บังคับให้บริษัทเทคโนโลยีมีช่องทางติดต่อกับมนุษย์จริง ๆ

  • โปรโตคอลและมาตรฐาน

    • ฉันชอบ โปรโตคอลและมาตรฐานไฟล์ มากกว่า
      • ใช้ SMTP และ IMAP แทน API ของ “Gmail” (แม้จะเก่า แต่ตอนนี้ยังเป็นตัวเลือกที่ดีที่สุด และยินดีต้อนรับความพยายามใหม่อย่าง JMAP)
    • บิ๊กเทคอย่าง Microsoft บังคับให้ใช้ ซอฟต์แวร์ Office 365 ที่ผนวกรวม AI-Copilot และเพิ่งปิดการเข้าถึง SMTP ของบัญชี Office 365 ไปเมื่อไม่นานนี้

จะ Self-host อะไรดี

  • ฮาร์ดแวร์

    • ฉันทำงานที่บริษัทชื่อ enum.co ซึ่งเป็นสภาพแวดล้อมที่ให้ความสำคัญกับอธิปไตยดิจิทัล
    • ตอนนี้ฉันรัน Kubernetes cluster แบบ high availability ที่ประกอบด้วยมินิเซิร์ฟเวอร์ 3 เครื่อง (ตั้งค่าด้วยความช่วยเหลือจากหัวหน้า)

  • ปฏิทิน & รายชื่อผู้ติดต่อ

    • เพราะเป็นข้อมูลที่อ่อนไหว ฉันจึงโฮสต์ เซิร์ฟเวอร์ CalDAV/CardDAV ของตัวเอง
    • ตัวเลือกเซิร์ฟเวอร์:
      • Radicale: พัฒนาด้วย Python, มีเว็บ UI พื้นฐาน, รองรับผู้ใช้คนเดียว, ใช้กับอุปกรณ์ Apple ไม่ได้
      • ⭐ แนะนำ Baïkal: พัฒนาด้วย PHP, มีการพัฒนาอย่างต่อเนื่อง, เว็บ UI ขั้นสูง, รองรับหลายผู้ใช้
      • DAViCal: พัฒนาด้วย PHP, ยังไม่เคยลอง
      • Xandikos: พัฒนาด้วย Python, ไม่มีระบบยืนยันตัวตนในตัว, ไม่มีเว็บ UI
      • Nextcloud: พัฒนาด้วย PHP, ถ้าใช้อยู่แล้วก็โอเค แต่หนักเกินไป
    • การใส่ใจข้อมูลปฏิทินและรายชื่อผู้ติดต่อยังรวมถึงการตรวจสอบด้วยว่า แอปไหนมีสิทธิ์เข้าถึงข้อมูลเหล่านี้

  • เมล

    • เมลเซิร์ฟเวอร์แบบ self-hosted มักถูกมองว่าเป็นของต้องห้าม แต่จริง ๆ แล้วไม่ได้ยากขนาดนั้น
    • โซลูชันใหม่อย่าง Stalwart หรือ Mailcow ทำให้ การโฮสต์กล่องเมลส่วนตัวเป็นเรื่องง่ายขึ้น (ไม่ใช่เมลการตลาด)
    • ไม่แนะนำให้โฮสต์ที่บ้าน (ต้องมี IP คงที่ และต้องเข้าถึงได้จากทั้งอินเทอร์เน็ต)
    • ขั้นตอนการตั้งค่า:
      • เลือกผู้ให้บริการโฮสติ้งที่เชื่อถือได้
      • ตรวจสอบให้ได้ IP address ที่สะอาด (เช็ก blacklist ของอีเมลแล้วทำซ้ำจนกว่าจะได้)
      • ตั้งค่าเซิร์ฟเวอร์แล้วตรวจสอบว่าสามารถรับอีเมลได้ และทุกโปรโตคอลถูกตั้งค่าอย่างถูกต้อง
      • ตรวจสอบด้วยเครื่องมือทดสอบออนไลน์ internet.nl
      • ส่งอีเมลไปยังที่อยู่ของ Google, Microsoft, Yahoo เพื่อดูว่าถูกจัดเป็นสแปมหรือไม่
      • ตรวจสอบ DNS, DMARC, SPF, TLS ฯลฯ ซ้ำไปซ้ำมา
    • วางแผนจะเขียนบล็อกโพสต์แบบละเอียดในอนาคต

  • สมาร์ตโฮม

    • เมื่อหลายปีก่อน ฉันเริ่มโฮสต์ Home Assistant instance โดยตอนนั้น Apple Homekit ก็เพียงพออยู่แล้ว แต่เริ่มจากการทดลอง
    • หลังจากนั้นบริษัทสมาร์ตโฮมจำนวนมากก็ล้มละลาย ปิดบริการคลาวด์ ขึ้นราคา หรือเปลี่ยนบริการฟรีให้กลายเป็นแบบเสียเงิน
    • ไม่กี่สัปดาห์ก่อน ฉันได้ยินข่าวว่า Philips Hue บังคับให้ผู้ใช้สร้างบัญชี ซึ่งยิ่งทำให้ Home Assistant โดดเด่นขึ้นมา
      • หากต้องการใช้ฟังก์ชันทั้งหมดของหลอดไฟที่จ่ายเงินซื้อไปแล้ว ก็จำเป็นต้องมีบัญชี
      • ฉันตั้งกฎ firewall เพื่อบล็อกทราฟฟิกออกสู่นอกเครือข่ายของอุปกรณ์สมาร์ตโฮมมาโดยตลอด
      • ดูเหมือนว่าแม้อยู่ในเครือข่ายภายใน ก็ยังใช้ฟังก์ชันเฉพาะของแอป Philips Hue ไม่ได้ (เช่นแอนิเมชันจำลองแสงเทียน)
      • หวังว่าจะมี community plugin ที่จำลองฟังก์ชันนี้ได้
    • ฉันจะ ไม่มีวันสร้างบัญชีออนไลน์สำหรับอุปกรณ์ที่ใช้งานเฉพาะในเครือข่ายภายใน
    • ตอนนี้ฉันกำลังอินกับ การติดตามการใช้พลังงาน และมีแผนจะพัฒนาอุปกรณ์ Raspberry Pi + กล้อง เพื่อวัดการใช้ก๊าซจากมิเตอร์ด้วย machine vision

  • RSS aggregator

    • ฉันติดตามเว็บไซต์ข่าวและบล็อกจำนวนมากผ่าน RSS และตัว RSS เองก็ กระจายศูนย์และมีอธิปไตยอยู่แล้ว
    • ดังนั้นการ self-host RSS aggregator จึงเป็นทางเลือก และเป็นขั้นตอนท้าย ๆ
    • ตอนนี้ใช้ NetNewsWire บน iPhone และ Mac
      • เป็น RSS reader ที่ดีที่สุด เป็นโอเพนซอร์ส และได้รับการสนับสนุนจากผู้คนที่ยอดเยี่ยม
      • มีการผสานรวมกับ FreshRSS แบบ native
    • FreshRSS เป็น feed aggregator ที่มีฟีเจอร์มากกว่า เช่น การกรอง
      • สามารถสมัครรับแหล่งข้อมูลที่ไม่ได้มี RSS feed มาให้โดยตรงได้ด้วย

  • ตัวติดตามตำแหน่งที่ตั้ง

    • ฉันได้ deploy dawarich instance (ในภาษาเยอรมันหมายถึง “ฉันเคยอยู่ที่นั่น”)
      • เป็นเซิร์ฟเวอร์สำหรับเก็บและดูข้อมูลพิกัดภูมิศาสตร์
      • มีแอปมือถือหลายตัวให้เลือกใช้เพื่อส่งตำแหน่งปัจจุบันไปยังเซิร์ฟเวอร์
    • แอปที่ใช้ได้:
      • แอปทางการของ dawarich: บน iOS จะแสดงไอคอนนำทางบน notch ตลอดเวลา
      • Overland: กินแบตเตอรี่มาก
      • ⭐ Owntracks: ทำงานบน iOS ได้ดีที่สุด แต่การตั้งค่าแอปสับสนมาก
      • PhoneTrack

ไอเดีย & แนวโน้ม

  • เมื่อไม่นานมานี้ฉันปรับโครงสร้าง homelab ใหม่ โดย เปลี่ยนจากเซิร์ฟเวอร์ใหญ่เครื่องเดียวเป็น Kubernetes cluster แบบ 3 โหนด
    • ทำให้มีความยืดหยุ่นมากขึ้นอย่างมากในประเภทของแอปพลิเคชันที่สามารถโฮสต์ได้
  • รายชื่อแอปและเครื่องมือที่อยากลองดู:
    • EteSync: CalDAV & CardDAV แบบเข้ารหัส end-to-end
    • AnyType: โฮสต์ AnyType server instance ของตัวเอง
    • Immich หรือ ente: ย้ายจากรูปภาพใน iCloud ไปสู่ self-hosting
    • Passbolt: ตัวจัดการรหัสผ่าน (ไม่ชอบ Bitwarden)
    • BirdNET: เฝ้าติดตามชนิดนกภายนอกอาคารด้วยไมโครโฟน
    • penpot: คล้าย Figma แต่ฟรี & โอเพนซอร์ส
    • Habitica: ตัวจัดการนิสัย
    • vert: ตัวแปลงไฟล์
    • InvoiceShelf: ตัวจัดการใบแจ้งหนี้
  • selfh.st เป็นแหล่งข้อมูลที่ยอดเยี่ยมสำหรับการค้นหาแอปพลิเคชันที่สามารถ self-host ได้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-10-11
ความคิดเห็นจาก Hacker News

  • อยากบอกว่าไม่ใช่แค่การ self-host บริการส่วนตัวด้วยตัวเองเท่านั้น แต่แม้แต่ธุรกิจซอฟต์แวร์หรือ SaaS ขนาดเล็กก็ควรลองพิจารณาวิธีโฮสต์แบบตรงไปตรงมามากขึ้นด้วย
    ผู้ให้บริการคลาวด์มักบอกว่าพวกเขาจำเป็นเพราะเรื่องความซับซ้อนและสเกล แต่ในความเป็นจริง โปรเจกต์ซอฟต์แวร์หรือธุรกิจส่วนใหญ่ไม่ได้ต้องการขนาดนั้นเลย
    ตัวอย่างเช่น สำหรับการ deploy NextJS ก็ไม่จำเป็นต้องพึ่ง Vercel หรือ Netlify เสมอไป แค่รัน Nginx หรือ Caddy (ซึ่งฉันชอบ) บน VPS ที่ติดตั้ง Ubuntu ก็พอ
    เกือบ 90% ขึ้นไปของโปรเจกต์สามารถโฮสต์เองได้สบายด้วยวิธีแบบนี้

    • ใช้ VPS ที่ปลอดภัยและตั้งค่าควบคุมความปลอดภัยที่จำเป็น (ปิด root login, ใช้ SSH key-based login เป็นต้น)

    • ตั้งค่า reverse proxy อย่าง Caddy/Nginx เพื่อเสิร์ฟไฟล์สแตติกหรือเว็บไซต์ ถ้าไม่ได้มีคำขอวันละหลายล้านครั้งก็แทบไม่ต้องใช้ CDN

    • รัน backend/API ด้วย Supervisor หรือ systemd

    • reverse proxy ตัวเดียวกันก็ใช้ proxy ไปยัง backend และบริการอื่น ๆ ได้

    • รันฐานข้อมูล mysql/postgres เองและตั้งค่าความปลอดภัยให้เหมาะสม

    • ทำ backup ได้ทั้งหมดด้วยสคริปต์/cron และควรทดสอบเป็นประจำ

    • ถ้าต้องการป้องกัน DOS/DDOS ก็เพิ่มเลเยอร์ Cloudflare ได้
      สุดท้ายสถาปัตยกรรมก็จะเป็น Cloudflare/DNS→Reverse Proxy(Caddy/Nginx)→แอป
      การ deploy ส่วนใหญ่แค่ git pull ก็พอ และถ้าจำเป็นก็ค่อย build เพิ่มได้
      Docker หรือคอนเทนเนอร์ก็ไม่ใช่สิ่งจำเป็น สำหรับโปรเจกต์ขนาดเล็กถึงกลางจะไม่ใช้ก็ได้
      มันอาจดูยาก แต่จริง ๆ ไม่ได้ยากอย่างที่คิด โปรเจกต์ส่วนใหญ่ไม่ได้ต้องการเว็บสเกลระดับใหญ่โต

    • สิ่งที่ทำให้ฉันกังวลที่สุดคือความเสี่ยงด้านความปลอดภัยที่เกิดจากการต้องดูแลทั้ง OS (รวมถึง kernel และ userland) เอง
      กลัวว่าไฟร์วอลล์จะตั้งถูกหรือยัง และจะตามแพตช์ CVE ล่าสุดได้เร็วพอไหม
      เพราะงั้นเลยรู้สึกว่าการทำ workflow ด้วย GitHub Actions → build container image แล้ว push ไป private registry → deploy image นั้นด้วยค่า k8s ไปยัง service จะเสถียรกว่า
      มันง่ายพอ ๆ กับการขึ้น VM เองโดยตรง และแบบนี้ฉันต้องรับผิดชอบแค่แอปกับอินเทอร์เฟซของตัวเองเท่านั้น

    • เหตุผลที่ฉันสร้าง canine.sh ก็เพราะอยากทำให้กระบวนการตั้งค่าทั้งหมดที่พูดถึงข้างต้นกลายเป็น one-click
      ตอนเคยร่วมก่อตั้ง SaaS เล็ก ๆ เมื่อก่อน ค่าใช้คลาวด์ของเราสูงเกิน 500,000 ดอลลาร์ต่อปี
      เร็วมากที่ตระหนักว่า sentry เป็นของจำเป็นสำหรับการรันโปรดักชัน และแทนที่จะไปคุ้ย server log เองทีละอัน ก็ใช้ cloud sentry เดือนละประมาณ 40 ดอลลาร์
      ต้องมี datadog เพื่อ monitoring ข้อมูลด้วย เดือนละ 300 ดอลลาร์
      BI tools อย่าง Looker/Tableau/Omni สำหรับ dashboard เอาไว้พรีเซนต์ลูกค้า ปีละ 20,000 ดอลลาร์
      data warehouse และ replication ปีละ 150,000 ดอลลาร์
      ค่าใช้จ่ายของบริการภายนอกพวกนี้สะสมขึ้นเรื่อย ๆ และท้ายที่สุดก็ได้ข้อสรุปว่าการดูแลและรันบริการภายนอกทั้งหมดบนอินฟราของตัวเองดีที่สุด
      ตัวอย่างเช่น Cloud Sentry→Self Hosted Sentry, Datadog→Prometheus/Grafana, Looker→Metabase, Snowflake→Clickhouse, ETL→Airbyte เป็นต้น
      นี่คือเหตุผลที่บริษัทส่วนใหญ่ลงเอยด้วยการเลือก Kubernetes
      คนทำ indie hacking อาจไม่ค่อยเข้าใจว่าทำไมต้องรับความซับซ้อนของ Kubernetes แต่เหตุผลที่เอาทุกอย่างไปวางไว้บน VPS เดียวไม่ได้ก็คือสิ่งนี้เอง

    • เห็นด้วยกับประโยคที่ว่า "โปรเจกต์ส่วนใหญ่ไม่ได้ต้องการเว็บสเกล"
      การตลาดของแพลตฟอร์มคลาวด์หลักทุกวันนี้ให้ความรู้สึกเหมือน YAGNI (You Ain't Gonna Need It) ถูกเอามาใช้กับฝั่งอินฟราด้วย
      ฉันทำงานเป็น sysadmin มาตั้งแต่ต้นยุค 2000 แล้ว เวลามองกระแสที่ทุกคนกลับมาพูดถึงการโฮสต์บริการเองเหมือนเป็นนวัตกรรมอะไรใหม่ ๆ ก็น่าสนใจดี
      ก่อน Docker จะมีมาตั้งนาน เราก็แยกโค้ดด้วย LXC, BSD Jails และของทำนองนั้นอยู่แล้ว มันเป็นประเพณีเก่าแก่ตั้งแต่ก่อนคำว่า DevOps อีก
      การได้ดูนักพัฒนายุคนี้ค้นพบเรื่องพวกนี้ใหม่อีกครั้งก็น่าสนุกดี
      สุดท้ายแล้ว ถ้ามีโอกาสร่วมงานหรือไปนั่งคุยกาแฟกับ sysadmin รุ่นเก๋า ๆ ก็ควรทำ
      ยังมีคนจำนวนมากที่ยินดีดูแลอินฟราแบบดั้งเดิม และมีเคล็ดลับใช้งานจริงอีกเยอะมาก

    • ข้อดีอีกอย่างของการ self-host คือ ต่างจากบริการคลาวด์ ทักษะและความรู้ด้านระบบที่ได้มานั้นพกพาไปใช้ที่อื่นได้มาก
      ถ้าเรียนรู้วิธีใช้ systemd, ufw, ssh เอาไว้ ก็เอาไปใช้กับระบบอื่นได้ทันที
      ฉันกลับรู้สึกว่าเวลาหรือค่าใช้จ่ายที่ต้องใช้เพื่อเรียนรู้ Docker, การ build image แบบหลายเลเยอร์ และเทคนิคต่าง ๆ นั้น มากกว่าการดูแลเว็บเซิร์ฟเวอร์ Debian ทั่วไปเสียอีก

    • โดยรวมเห็นด้วย และขอบคุณที่แชร์ความเห็น
      มีจุดเดียวที่คิดต่างคือเรื่อง "CDN จำเป็นก็ต่อเมื่อมีขนาดใหญ่"
      ฉันคิดว่า CDN ไม่ได้มีไว้แค่กระจาย origin request แต่มีเป้าหมายสำคัญในการลด latency ของประสบการณ์ผู้ใช้ด้วย
      ความเร็วที่ผู้ใช้รับรู้นี่แหละคือฟีเจอร์ที่สำคัญที่สุดอย่างหนึ่ง และแม้ควรระวังการ optimize ล่วงหน้าเกินจำเป็น อย่างน้อยการเสิร์ฟ static asset จาก edge ที่อยู่ใกล้ผู้ใช้ก็เป็นสเปกพื้นฐานมานานกว่า 10 ปีแล้ว

  • เป็นหัวข้อที่ยอดเยี่ยมมาก และฉันพอจะแชร์มุมมองจากประสบการณ์ตัวเองได้
    การทำ homelab เอง ข้อดีที่ใหญ่ที่สุดไม่ใช่การประหยัดเงินหรือความเป็นส่วนตัวของข้อมูลโดยตรง แต่คือการได้ความรู้เชิงปฏิบัติที่ลึกจริง
    การเรียนรู้เรื่อง Docker, networking, Linux administration จากบทความ กับการที่คุณรันบริการที่ครอบครัวใช้อยู่จริงแล้ว DNS ดันดับหรือ Docker container reboot ไม่ขึ้นจนต้องแก้เองนั้น เป็นการเรียนรู้คนละระดับกันเลย
    แต่ก็มีความจริงอีกด้านหนึ่งเหมือนกัน
    ตอนแรกมันเป็นโปรเจกต์สนุก ๆ แต่พอเริ่ม self-host บริการสำคัญอย่าง password manager หรือ file sync คุณก็กลายเป็นคน on-call 24/7 ไปโดยปริยาย
    backup, security patch, uptime ทั้งหมดกลายเป็นความรับผิดชอบของคุณ และจากจุดนั้นมันก็ไม่ได้เป็นแค่งานอดิเรกอีกต่อไป แต่กลายเป็น "งาน"
    สุดท้ายแล้ว self-hosting เป็นทางเลือกที่ให้ทั้งอำนาจควบคุมข้อมูลและความรู้สึกสำเร็จอย่างมาก แต่ก็เป็น trade-off ที่เอาค่าใช้จ่ายของ SaaS มาแทนที่ด้วยเวลาและภาระทางใจของตัวคุณเองในบทบาทฝ่าย IT
    แต่ถ้าเป็นผู้ใช้ HN ฉันคิดว่ามันคุ้มค่าพอให้ลองแน่นอน

  • มีคนเขียนว่าตัวเองโชคดีที่ได้ทำงานในบริษัท (enum.co) ที่ให้ความสำคัญกับ digital sovereignty แต่พอลองเช็ก mail server ผ่าน info.addr.tools กลับเจอว่า MX เป็น smtp.google.com และ TXT record ก็มีทรัพย์สินของ Google อยู่หลายอย่าง
    นี่ไม่ใช่แค่ "คำขวัญ" แต่เป็นความจริงที่เห็นได้ใน DNS
    การบอกว่าให้ความสำคัญกับอธิปไตยดิจิทัลแต่ยังพึ่งบริการอีเมลของ Google อยู่นั้นขัดแย้งกัน
    https://info.addr.tools/enum.co

    • ถ้าจะพูดปกป้อง enum หน่อย บริการที่พวกเขาให้คือ k8, S3-compatible storage และฝั่ง DevOps
      ถ้าพวกเขาขายเรื่อง self-hosting/sovereignty ของอีเมลแต่ดันใช้ gmail เอง มันก็จะเป็นอีกเรื่องหนึ่ง
      มันอาจยังไม่อิสระ 100% แต่จริง ๆ OP ก็พูดไว้แล้วว่า "แม้ mail server แบบ self-host จะถูกมองว่าเป็นของต้องห้าม แต่ก็ไม่ได้น่ากลัวอย่างที่คิด"
      ทุกคนรู้ว่าปัญหานี้มีอยู่ และยังมีจุดที่ต้องปรับปรุงอีก

    • สวัสดีครับ ผมคือผู้ก่อตั้ง enum
      ข้อสังเกตนั้นยุติธรรมและเป็นประเด็นที่ดีมาก
      พูดกันตรง ๆ การใช้ Google Workspace สำหรับอีเมลภายในของเราเป็นการตัดสินใจเชิงปฏิบัติในช่วงแรก เพื่อให้โฟกัสกับการพัฒนาผลิตภัณฑ์หลัก
      มันเป็นตัวเลือกที่พบได้บ่อยมากในสตาร์ตอัป และเรามีกำหนดย้ายออกภายในไม่กี่สัปดาห์ข้างหน้า
      อย่างไรก็ตาม แพลตฟอร์มสำหรับลูกค้าและข้อมูลทั้งหมดของเรานั้นรักษา sovereignty ไว้ 100% มาโดยตลอด
      อินฟราของเราเป็นอิสระจาก Big Tech อย่างสมบูรณ์
      ขอบคุณที่ชี้ให้เห็นประเด็นนี้

    • สำหรับฉัน อีเมลเป็นข้อยกเว้นของการ self-host
      ฉัน self-host ทุกบริการ แต่ยกอีเมลให้ third party ดูแล

    • ประทับใจที่คุณจับประเด็นเรื่องมี Google record อยู่ใน DNS ได้อย่างหนักแน่น
      สุดยอดจริง ๆ

    • ส่วน TXT google-site-verification=... ไม่ได้ "ชั่วร้าย" อะไรนัก มันเป็นการประนีประนอมเพื่อให้ Google ไม่มองอีเมลที่ส่งออกไปว่าเป็นสแปม

  • ถ้าจะ self-host อีเมล ในกรณีที่ digital sovereignty สำคัญกว่าความเป็นส่วนตัว
    ฉันใช้ gmail กับ custom domain แล้ว self-host email server ของตัวเองเพื่อดึงเมลจาก gmail ลงมาตลอดด้วย mbsync
    การเก็บและอ่านทำบนเซิร์ฟเวอร์ของฉันเอง แต่การส่งยังใช้ gmail เหมือนเดิม
    ต่อให้ Google ตัดการเข้าถึงบัญชี ฉันก็ยังมีอีเมลของตัวเองอยู่ และเวลาเปลี่ยนผู้ให้บริการก็แค่เปลี่ยน DNS
    แถมไม่มีปัญหาเรื่องการส่งอีเมลไปถึงปลายทางด้วย

    • ฉันเริ่ม self-host เมลเมื่อ 6 ปีก่อน โดยตั้งค่า DNS อย่าง SPF, DMARC เป็นต้น
      ปัญหาเกิดขึ้นแค่ครั้งหรือสองครั้ง และส่วนใหญ่สิ่งที่น่าปวดหัวกว่าก็ไม่ใช่ mail server แต่เป็นบริการอื่นหรือเหตุขัดข้องสุ่ม ๆ การเปลี่ยน IP การทำ backup อัตโนมัติ ฯลฯ
      กลายเป็นว่า mail server ทำงานของมันได้ดีอยู่เฉย ๆ

    • ถามหน่อยว่าทำไมถึงไม่ self-host แม้แต่ฝั่งส่งอีเมล
      น่าจะเป็นเพราะปัญหาเรื่อง deliverability ใช่ไหม?

    • sovereignty ของอีเมลอย่างแท้จริงขึ้นอยู่กับ custom domain
      ถ้าคุมสิ่งนี้ไว้ได้อย่างปลอดภัย ก็เลือกผู้ให้บริการหลายเจ้าได้ทุกเมื่อและย้ายงานได้อย่างอิสระ

  • self-hosting เจ๋งมาก
    ตั้งแต่เมื่อปีที่แล้วที่เปลี่ยนจาก software engineer มาทำ SaaS startup ฉันก็ใช้ Coolify กับเซิร์ฟเวอร์ Hetzner ราคา 20 ดอลลาร์เพื่อโฮสต์ Postgres, Minio เวอร์ชันเก่า, Nuxt, NextJs, Umami analytics, Open WebUI, static site และอื่น ๆ เอง
    ตอนแรกต้องใช้เวลาศึกษาอยู่บ้าง แต่พอตั้งค่าเสร็จแล้ว การเปิดบริการใหม่ก็ง่ายเหมือน plug-and-play
    ตอนนี้ยังใช้ทรัพยากรเซิร์ฟเวอร์ไม่ถึง 1/4 เลย (เพราะผู้ใช้น้อย ฮ่า ๆ)
    https://coolify.io/docs/

  • ผมทำงานเป็นผู้เชี่ยวชาญ IT แต่ก็ผัดวันประกันพรุ่งเรื่อง self-hosting หรือการทำ NAS ที่บ้านมาตลอด สุดท้ายเลยซื้อ Ugreen NAS รุ่น 4-bay แล้วติดตั้ง TrueNAS CE ทันที
    ผมให้บริบทกับ ChatGPT ไปถึงขั้นไฟล์ docker-compose ของผมเองแล้วค่อย ๆ เซ็ตระบบ
    แม้ก่อนหน้านั้นจะมีความรู้เรื่อง Docker, networking ฯลฯ แค่เล็กน้อยสมัยยังเป็นนักศึกษา
    ตอนนี้ผมรันระบบแบบนี้อยู่

    • รันหลายแอปแบบ Dockerized
    • แยก network อิสระตามแต่ละ app stack
    • ใช้ Traefik+Docker labels จัดการการเปิดเผย web UI
    • เปิดออกภายนอกเฉพาะพอร์ต 443 ของ Traefik และค่อย port forward เมื่อจำเป็น
    • ใช้ Cloudflare tunnel แบบเลือกเฉพาะกรณี
    • ให้ Traefik ทำ TLS termination อัตโนมัติสำหรับโดเมน (ทั้ง LAN/WAN)
    • ใช้ Split-DNS สำหรับ LAN/WAN
    • ใช้ CrowdSec กับทุกคอนเทนเนอร์ที่เปิดเผยออกภายนอก
    • ใช้ Cloudflare บังคับ MFA กับบริการที่เปิดเผย
    • ใช้ Technitium สำหรับ DHCP/DNS ภายใน
    • ทำ ZFS snapshot/remote backup อัตโนมัติ
    • แยก DB, log และข้อมูลชั่วคราวไปไว้บน SSD ส่วนไฟล์ขนาดใหญ่ไว้บน HDD
      เป็นแบบนี้อยู่

  • self-hosting ดีอยู่หรอก แต่ปัญหาคือเรื่อง backup กับ upgrade
    ฉัน self-host ทรัพยากรหลายอย่าง แต่จะไม่ self-host ข้อมูลสำคัญหรือสิ่งที่คนอื่นต้องพึ่งพา
    ถ้ากู้แอปกลับมาหรืออัปเกรดได้ไม่ง่าย ฉันจะไม่ยอมพึ่งมัน
    ในทางปฏิบัติ แอป self-host ส่วนใหญ่ไม่ได้มี backup/restore ที่จบในหนึ่งหรือสองบรรทัด
    อีกอย่าง Tailscale กับ Pangolin นี่เหมือนของขวัญจากสวรรค์สำหรับการ self-host ที่บ้านแบบปลอดภัย

    • อยากรู้ว่าคุณคาดหวัง backup solution แบบไหน
      แอป self-host ทั้งหมดรันใน Docker อยู่แล้ว ดังนั้นแค่ backup โฟลเดอร์ volume ของคอนเทนเนอร์กับ docker-compose.yml ก็พอ
      ตอน restore ก็แค่เอาโฟลเดอร์กลับมาแล้ว docker compose up จบ
      ผมไม่คิดว่าแอปแต่ละตัวจำเป็นต้องทำระบบ backup ของตัวเอง นั่นเป็นการเสียเวลาของนักพัฒนา

    • ขอแนะนำอย่างมากให้ self-host netbird แทน Tailscale
      โปรเจกต์นี้พัฒนาอย่างคึกคักมาก และ UI ก็ดีเยี่ยม
      https://github.com/netbirdio/netbird

    • อยากรู้ว่า Pangolin คืออะไร
      พอค้นดูเจอแต่สัตว์

  • สแตก self-host ของฉัน

    1. immich
    2. jellyfin
    3. ghost
    4. wallabag
    5. freshrss
    6. vaultwarden
    7. nextcloud
    8. overleaf/sharelatex
    9. matrix server
    10. pds สำหรับ atproto
    • อยากรู้ว่าคุณอัปเกรดอย่างไร ใช้ security patch ยังไง ทำ backup แบบไหน และมีการทดสอบเป็นประจำจริงหรือไม่
      บางทีคำแนะนำเรื่องอัปเกรดเวอร์ชันล่าสุดหรือ security patch ก็แย่มาก หรือบางครั้งก็ต้องไล่อัปเกรดทีละเวอร์ชันแบบข้ามไม่ได้

  • ถ้าจำกัดความคำว่า "self-hosting" แค่ว่าเป็นเซิร์ฟเวอร์ในบ้านอย่างเดียว มันก็คงเป็นกระแสรองตลอดไป
    เราควรสนับสนุนทุกแนวทางที่ไม่ใช่ SaaS ไม่ว่าจะเป็นแอปโอเพนซอร์สที่ไม่ต้องสมัครสมาชิก แอปพลิเคชัน Windows แบบดั้งเดิม หรือคลาวด์แอปที่ย้ายออกได้ง่าย
    ไม่ว่าจะด้วยวิธีไหน การหลีกเลี่ยง lock-in และทำให้ผู้ใช้มีอำนาจควบคุมต่างหากคือเป้าหมายที่แท้จริงของ self-hosting

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

    • ซอฟต์แวร์แบบติดตั้งบน Windows ก็อาจนับเป็น self-hosting ได้เหมือนกัน
      ในทางปฏิบัติ หลายคนก็เริ่มจากไฟล์ executable บน Windows หรือ Docker แล้วค่อยพัฒนาไปทีละขั้น

    • อย่างน้อยที่สุด ฉันคิดว่าการรันเซิร์ฟเวอร์ในดาต้าเซ็นเตอร์ของคนอื่น (เช่น colocation) โดยที่คุณยังมีสิทธิ์ root เอง ก็นับเป็น self-hosting

  • เมื่อ 20 ปีก่อน แม้แต่คุณปู่ยังเข้า limewire.com ดาวน์โหลด setup.exe แล้วกด next -> next -> next ก็ได้ file server กับ client ที่สมบูรณ์แบบแล้ว
    ในปี 2007 คอมพิวเตอร์หนึ่งในสามของโลกใช้ limewire
    แต่ทุกวันนี้ แม้แต่ซอฟต์แวร์ self-hosting พื้นฐานมาก ๆ ก็แทบมีแต่วิศวกรมืออาชีพเท่านั้นที่ติดตั้งได้
    ต้องใช้ SSH, Docker, Tailscale, TLS certificate และการดูแลซับซ้อนอีกมาก รวมถึง backup กับ automation จิปาถะนับไม่ถ้วน...
    เลยอดสงสัยไม่ได้ว่าทำไมซอฟต์แวร์ "self-hosting" แบบ apt-get install แล้วจบถึงหายากนัก
    และนี่แหละคือเหตุผลที่ไม่มีใครโฮสต์เอง
    https://en.wikipedia.org/wiki/LimeWire

    • ซอฟต์แวร์บางตัวก็ติดตั้งจบด้วย apt-get install ได้จริง แต่ถ้าจะเปิดบริการออกสู่อินเทอร์เน็ต คุณก็ต้องเริ่มจากการตั้งค่า domain name กับ HTTPS อยู่ดี
      client อย่าง Limewire หรือ BitTorrent ใช้งานได้โดยไม่ต้องมีโดเมนก็เพราะมี central server (เช่น tracker) ช่วยอยู่เบื้องหลัง

    • คนส่วนใหญ่คงไม่คิดว่า installer อย่าง limewire เป็น self-hosting
      มันก็แค่ติดตั้งโปรแกรมบนเครื่อง локัล

    • Ubuntu เคยพยายามทำให้ติดตั้งแอปฝั่งเซิร์ฟเวอร์ได้ง่ายผ่าน snap แต่ชุมชนต่อต้านหนักจนไม่สำเร็จ
      snap เองก็มีข้อเสีย แต่ format นี้ถูกสร้างมาเพื่อทำให้การแจกจ่าย server app ง่ายขึ้น
      ยกตัวอย่างเช่น ทุกวันนี้ก็ยังติดตั้ง nextcloud ผ่าน snap ได้
      สุดท้ายก็เหมือนปฏิเสธแม้แต่ความ "ดีพอใช้ได้" เพราะมันไม่สมบูรณ์แบบ

    • Limewire เป็นแค่ client ไม่ใช่ server
      ถ้าจะให้อัปโหลดได้จริงก็ยังต้องตั้ง firewall/port forwarding และอาจต้องเปิด UPnP (ซึ่งไม่แนะนำ)
      เซิร์ฟเวอร์สำหรับ self-hosting เป็นอีกโลกหนึ่งไปเลย
      ในโลกที่เมื่อก่อนมือใหม่ก็น่าจะทำอะไรอัตโนมัติได้ ตอนนี้เพราะพวกแฮกเกอร์ตัวร้าย ความยากในการตั้งค่าและดูแลจึงสูงขึ้นมาก
      ต่อให้เป็นผู้เชี่ยวชาญเองก็ยังไร้ทางสู้กับ penetration tester มืออาชีพหรือแฮกเกอร์ระดับรัฐชาติ

    • ฉันคิดว่าการพัฒนาซอฟต์แวร์ทุกวันนี้ซับซ้อนเกินไปมาก
      มันคล้ายระบบราชการที่ค่อย ๆ สร้างปัญหาไร้สาระขึ้นมาเพื่อรักษาอาชีพของตัวเอง
      คนส่วนใหญ่ไม่ได้ต้องการ self-hosting ถึงขั้นนั้น แค่ให้มันรันบนคอมพิวเตอร์ตัวเองและเข้าจากเครือข่ายท้องถิ่นได้เป็นบางครั้งก็น่าจะพอ
      แต่กลับไม่มีโมเดลรายได้รองรับ และนักพัฒนาก็หมกมุ่นกับเลเยอร์เฉพาะทางหรือสถาปัตยกรรมที่ซับซ้อนเกินจำเป็น
      ผลลัพธ์คือได้ซอฟต์แวร์ฝั่งเซิร์ฟเวอร์, เว็บวิว, ความแยกขาดระหว่างข้อมูลกับสภาพแวดล้อมโลคัล และมีแต่อุปกรณ์ให้ต้องดูแลเพิ่มขึ้น
      คอมพิวเตอร์ส่วนใหญ่แทบไม่ได้ใช้งาน แต่เลเยอร์สำหรับผู้ดูแลกลับพอกขึ้นเรื่อย ๆ
      ฉันคิดว่ากระแสโน้ตบุ๊กก็เป็นส่วนหนึ่งของความสับสนนี้เหมือนกัน
      แอปโลคัลดี ๆ บน Mac หายไปเรื่อย ๆ และถูกแทนที่ด้วยบริการคลาวด์แบบ subscription
      แม้แต่โอเพนซอร์สเองก็มักลงเอยเป็น Docker image, การตั้งค่าซับซ้อน และ gotcha อีกเป็นภูเขา
      ถ้ามันติดตั้งและดูแลง่ายกว่านี้ ต่อให้ต้องจ่ายเงินก็น่าใช้
      แต่ตอนนี้ไม่มีใครรู้เลยว่าจะต้องเสียเวลาแค่ไหน สุดท้ายทุกคนก็เลยยอมยกให้ Big Tech จัดการแทน
      แม้เทคโนโลยีเว็บจะยอดเยี่ยมสำหรับเอกสารแบบโต้ตอบได้ แต่สำหรับการใช้งานนอกเหนือจากนั้น มันก็ยังมีปัญหาใหญ่ด้าน usability อยู่ดี