โฮสต์เองและอิสรภาพทางเทคโนโลยี: ความสุขของการลงมือสร้างด้วยตัวเอง

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

---

เกริ่นนำ: คุณค่าของอิสรภาพทางเทคโนโลยีและการลงมือสร้างเอง

• หลังจากดูวิดีโอที่ PewDiePie ติดตั้ง Arch Linux และสร้างผลิตภัณฑ์บนพื้นฐานโอเพนซอร์สด้วยตัวเอง ผู้เขียนจึงได้ทบทวนถึงความสำคัญของการ โฮสต์เอง และ อิสรภาพทางเทคโนโลยี ในแบบของตน
• โดเมน บล็อก และบริการต่าง ๆ ที่ตนสร้างและดูแลเองจะกลายเป็นทรัพย์สินที่สะสมมูลค่าในระยะยาว ซึ่งมีความหมายมากกว่าการย้ายแพลตฟอร์มไปมาอย่างเดียว

พลังของการเป็นเจ้าของโดเมนและการทำบล็อกด้วยตัวเอง

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

ประสบการณ์การโฮสต์เองและการเรียนรู้ของผู้เขียน

• ผู้เขียนโฮสต์บริการหลากหลายด้วยตัวเอง เช่น บล็อก, second brain, หนังสือ, รายการสมัครรับข้อมูล โดยใช้ GoHugo, Listmonk, Memberstack และอื่น ๆ
• ค่อย ๆ สะสมทักษะทางเทคนิคผ่านการสร้างสภาพแวดล้อม Homelab, SSH, การสำรองข้อมูล, การจัดการรูปภาพ, Gitea, และการทำพร็อกซี/ใบรับรอง SSL แบบอัตโนมัติ
• แม้ช่วงแรกจะรู้สึกยาก แต่ การเรียนรู้และความภูมิใจจากการทำสำเร็จ คือรางวัลที่ใหญ่ที่สุดในกระบวนการนี้

คุณค่าของโอเพนซอร์สและชุมชน

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

Linux และ Linus Torvalds

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

คำขอบคุณและเครื่องมือโอเพนซอร์ส

• มี เครื่องมือโอเพนซอร์ส บางตัวที่ผู้เขียนใช้งานบ่อยและรู้สึกขอบคุณอยู่เสมอ
  • Quartz: ทางเลือกโอเพนซอร์สแทน Obsidian Publish
  • GoatCounter: เครื่องมือวิเคราะห์ทราฟฟิกเว็บไซต์แบบไม่ระบุตัวตน
  • Listmonk: ระบบรายชื่อจดหมายข่าวแบบโอเพนซอร์ส
  • listmonk-rss: ส่งอีเมลอัตโนมัติเมื่อเขียนบล็อก
• ตัวอย่างซอฟต์แวร์โอเพนซอร์สที่แนะนำสำหรับ Homelab:
  • Paperless: แปลงเอกสารเป็นดิจิทัลและจัดการเอกสาร
  • PhotoPrism: จัดการรูปภาพแบบโฮสต์เองด้วย AI
  • Pi-hole: บล็อกโฆษณาทั้งเครือข่าย
  • Nginx Proxy Manager: จัดเส้นทางโดเมนและทำ SSL อัตโนมัติ
  • Audiobookshelf: เซิร์ฟเวอร์หนังสือเสียง/พอดแคสต์
  • Calibre: จัดการ e-book
  • Syncthing: ซิงก์ไฟล์แบบกระจายศูนย์
  • Gitea: บริการ Git แบบโฮสต์เองที่มีน้ำหนักเบา

ทดลองได้มากพอแม้ใช้อุปกรณ์ราคาย่อมเยา

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

อิสรภาพทางเทคโนโลยีและความเสี่ยงจากแพลตฟอร์ม

• การสร้างและโฮสต์ระบบด้วยตัวเองช่วยให้เป็นอิสระจากความเสี่ยงอย่างการเปลี่ยนฟีเจอร์หรือการยุติบริการของผู้ให้บริการรายใหญ่ เช่น Google และ Apple
• อิสระในการออกแบบและปรับแก้สภาพแวดล้อมกับลักษณะเฉพาะของตนเองได้โดยตรง คือข้อดีที่แท้จริงของ Tech Independence

ปิดท้ายและความสำคัญของ Markdown

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

• Markdown รับประกันความเข้ากันได้ข้ามแพลตฟอร์มหลากหลาย และกลายเป็นเครื่องมือมาตรฐานของวัฒนธรรมโอเพนซอร์สและการแบ่งปันความรู้

• บล็อก data engineering เพิ่มเติม บันทึก second brain และหนังสือที่กำลังเขียนแบบเปิดเผยต่อสาธารณะ สามารถดูได้ทั้งหมดที่ ssp.sh และ GitHub

• ผู้เขียนยินดีต้อนรับการแบ่งปันประสบการณ์และการพูดคุยแลกเปลี่ยนกับผู้อ่านเสมอ

[GN⁺]

ความคิดเห็นจาก Hacker News

• ขอโทษที่เหมือนโปรโมตตัวเองนิดหน่อย แต่อยากบอกว่าความจริงแล้วเวลา self-hosting ไม่จำเป็นต้องซื้อฮาร์ดแวร์ใหม่เองเสมอไป ผ่านไปไม่กี่ปี โน้ตบุ๊กเก่าที่ช้าจนใช้ Windows ไม่ไหว ก็ยังให้ประสิทธิภาพพอใช้เป็น Linux server ได้สบาย มีโอกาสสูงมากที่จะเจอโน้ตบุ๊กเก่า ๆ วางทิ้งอยู่ตามบ้านหรือตามเพื่อนรอบตัว และผมเองก็ยังใช้โน้ตบุ๊ก i3 รุ่นปี 2011 ร่วมกับอีกคนได้ดี และจนถึงตอนนี้ในปี 2025 ก็ดูยังไม่จำเป็นต้องอัปเกรดเลย โน้ตบุ๊กยังประหยัดไฟตอนสแตนด์บายได้ดีด้วย ดังนั้นถ้ามองระยะยาวก็อาจเป็นตัวเลือกที่สมเหตุสมผลกว่าเดสก์ท็อป สำหรับมือใหม่สาย self-hosting ผมคิดว่าโน้ตบุ๊กเป็นตัวเลือกเซิร์ฟเวอร์เครื่องแรกที่ยอดเยี่ยมมาก (อนึ่ง โน้ตบุ๊กไม่ได้มี UPS ในตัว ถ้าจะเสียบค้างไว้ 24 ชั่วโมง แนะนำอย่างยิ่งให้ถอดแบตเตอรี่ออก)
  บทความเกี่ยวกับการนำฮาร์ดแวร์เก่ากลับมาใช้ใหม่

  • ขอยอมรับว่าตอนนี้ก็พิมพ์โพสต์นี้อยู่บน Acer โน้ตบุ๊กอายุ 13 ปีที่รัน Linux Mint XFCE อยู่ ผมเสียดายเสมอเวลาเห็นอุปกรณ์เก่าถูกทิ้ง เลยหลังซื้อโน้ตบุ๊กใหม่ก็เอาเครื่องเก่าไปต่อ HDMI กับทีวีในห้องนั่งเล่น และตั้งค่าไว้กับคีย์บอร์ด/แทร็กแพดไร้สาย Logitech K400+ ราคา $25 ใช้ท่องเว็บ ดู YouTube, Netflix ได้ไม่มีปัญหา เวลาอยากทำงานก็เปิด VS Code หรือ Thunderbird ใช้ได้ แถมยังเล่นเกมอินดี้บน Steam ด้วยเกมแพดได้สบาย ถ้า Framework laptop เข้ามาขายในประเทศเราได้จริง สภาพแวดล้อมการนำกลับมาใช้แบบนี้คงเพิ่มขึ้นอีกมาก แต่น่าเสียดายที่ประเทศผมยังไม่มีบริการส่ง

  • แถวบ้านผม (อพาร์ตเมนต์คอมเพล็กซ์ 250 ครัวเรือนในสวีเดน) การที่คนเอาคอมเก่าไปทิ้งในจุดขยะอิเล็กทรอนิกส์เป็นเรื่องปกติมาก ผมเลยออกลาดตระเวนวันละหลายรอบเวลาไปพาหมาเดินเล่น เหมือนตัวละครในหนัง Mad Max เอาเครื่องหลาย ๆ ตัวมาผสมอะไหล่ลง debian แล้วรัน docker container ใช้งานสารพัดอย่าง ผมยังเคยเอา Frankenstein server ที่ประกอบแบบนี้ไปให้พ่อแม่ ลูกพี่ลูกน้อง และเพื่อนด้วย น่าตกใจมากว่าคนทิ้งเครื่องที่ยังใช้งานได้ดีแค่ไหน บ่อยครั้งยังเจอโน้ตบุ๊กที่ไม่มีรหัสผ่าน พอเข้า Windows ไปก็มีรูปครอบครัวเต็มเครื่อง บางครั้งยังเจอ iPhone รุ่นประมาณ 5 ปีก่อนที่ปลดล็อกอยู่ด้วย โลกนี้มันช่างแปลกจริง ๆ

  • ที่บ้านผมก็มี Mac-Mini รุ่นปี 2012 อยู่เครื่องหนึ่ง ได้มาเป็นของขวัญ เลยไม่เคยคิดจะย้ายไปใช้ Mac แบบจริงจัง แม้จะไม่แรงแต่ประสิทธิภาพก็ยังใช้ได้ คริสต์มาสปีที่แล้วผมลองบูตมันขึ้นมา พบว่าแม้แต่ OS เดิมก็ช้ามากแล้ว และพออัปเดต macOS ก็แทบใช้งานไม่ได้เลย เลยทำตาม YouTube เปลี่ยนเป็น SSD ติดตั้ง Debian แล้วลง CasaOS (โฮมเซิร์ฟเวอร์ OS/UI แบบเว็บ) หลังจากนั้นก็ทำระบบให้เข้าจากภายนอกผ่าน Wireguard และสตรีมเพลงผ่าน Navidrome ได้ ผมยังไม่ค่อยเข้าใจแนวคิด Docker ดี แต่กำลังเรียนรู้หลายอย่างอยู่ เช่น การแมป PATH เป็นต้น

  • ถ้าคุณไม่ได้กังวลกับการซื้อของมือสอง ช่วงนี้ผมกำลังประกอบ Proxmox node ที่มี Threadripper เจน 3 แบบ 32 คอร์/64 เธรด, RAM 256GB, 2x10G, 2x2.5G, อินเทอร์เฟซจัดการ IPMI แยก 1G และ 64 PCIe gen 4 lanes ทั้งหมดนี้ในงบต่ำกว่า 2,000 ยูโร

  • ถ้าตั้งค่าต่ำกว่า RAID6/RAIDZ2 ก็มีความเสี่ยงข้อมูลสูญหายค่อนข้างมาก โน้ตบุ๊กส่วนใหญ่มีพอร์ต SATA/M.2 ไม่พอจะทำ parity setup อยู่แล้ว ดังนั้นถ้าต้องการ fault tolerance ระดับ RAID สุดท้ายก็ต้องใช้ฮาร์ดแวร์ใหม่อยู่ดี ถ้ายึดหลักว่าข้อมูลสำรองต้องกระจายอย่างน้อย 2 ตำแหน่งทางกายภาพ การทำซ้ำสองชุดก็ยังเป็นทางเลือกที่ดีที่สุด

• ผมเข้าใจเหตุผลของคนที่อยาก self-hosting นะ แต่ก็เข้าใจเต็มที่เหมือนกันว่าทำไมบางคนไม่อยากทำ self-hosting เป็นงานจุกจิก ต้องคอยอัปเดต docker พออะไรพังก็มีแต่เราที่ต้องแก้เอง และถึงจะทำงานได้ดี มันก็มักให้ความรู้สึกกึ่ง ๆ ไม่ค่อยเนียนนัก ตอนนี้รายการเครื่องมือ self hosted ที่ทำงานดีจนช่วยประหยัดเวลาผมมีน้อยมาก (ตัวแรกคือ firefly) และหลายครั้งก็ตั้งค่าไปแล้วพัง สุดท้ายก็ยอมแพ้ ทุกวันนี้ถ้าเป็นบริษัทที่เคารพความเป็นส่วนตัวและราคาสมเหตุสมผล ผมก็ยอมจ่ายใช้ไปเลย

  • ผมคิดว่าต้นตอปัญหาคือ Docker Docker เพิ่มชั้น abstraction ที่ไม่จำเป็นในเรื่องสตอเรจ เน็ตเวิร์ก และอื่น ๆ แถมถ้าจะอัปเดตเพื่อแก้ด้านความปลอดภัย ก็ต้อง rebuild container เองหรือหวังให้คนอื่นทำให้ ถ้าเป็นไปได้ การยึดบริการที่แจกจ่ายผ่าน upstream OS package หรือเป็น single binary (แบบที่มักเห็นในโปรเจ็กต์ Go) จะดูแลง่ายกว่าในระยะยาวมาก

  • ผมสงสัยว่าทำไมต้องอัปเดต Docker ด้วย ในกรณีของผม Docker รันมาเกิน 1 ปีแล้วโดยไม่ต้องอัปเดตอะไร ส่วนการอัปเกรด docker image ก็ใช้เวลาแค่ราว 15 นาทีต่อเดือนเท่านั้น และในความเป็นจริง บริษัทที่เคารพความเป็นส่วนตัวมีน้อยมาก และก็ยากจะเชื่อว่าพวกเขาจะรักษานโยบายแบบเดิมไปเรื่อย ๆ หลายปี

  • เอาเข้าจริง แค่จะหาบริษัทที่เคารพความเป็นส่วนตัวและราคาดีก็ยากมากแล้ว

  • อยากรู้ว่าคุณเจอปัญหากับโปรเจ็กต์ไหนบ้าง เพราะจากประสบการณ์ผม ถ้าโปรเจ็กต์ไปถึงขั้นมี Docker Compose ให้แล้ว ส่วนใหญ่แทบไม่มีปัญหาเลย และผมคิดว่าแทบทุกบริษัทสุดท้ายก็ต้องทรยศความไว้ใจไม่วันใดก็วันหนึ่ง ดังนั้นก็อย่าให้พวกเขามีโอกาสทำแบบนั้นเลย ตอนนี้ผม self-hosting Home Assistant อยู่ และสิ่งที่บริษัทนี้ไม่เหมือนใครคือเขายังวางกลไกทางกฎหมายไว้ด้วยเพื่อไม่ให้การดำเนินงานของบริษัทกลายเป็นผลเสียต่อผู้ใช้

• ผม self-hosting แทบทุกอย่างที่ต้องใช้ แต่ไม่นานมานี้เพิ่งเจอวิกฤตจริงตอนอินเทอร์เน็ตหลุด ๆ ติด ๆ ทำให้เริ่มถามตัวเองว่า

  • ถ้าไม่มีอินเทอร์เน็ต ฉันยังรักษาระดับ productivity ได้แค่ไหน
  • มีอะไรที่ฉันกำลังขาดหายไปบ้าง
    สุดท้ายก็พบว่าต้องทำ document archiving ให้มากขึ้น และ NixOS ก็แทบใช้งานออฟไลน์ไม่ได้เลยถ้าไม่มี cache server ของตัวเอง ซึ่งน่าหงุดหงิดมาก แต่ผลจากการทดสอบนี้ก็คือ ผมค้นพบว่าการ self-hosting สิ่งที่ต้องใช้ส่วนใหญ่ไว้เอง และใช้งานในสภาพแวดล้อมนั้น กลับทำให้ productivity สูงขึ้นมากแม้ไม่มีอินเทอร์เน็ต

  • ลองโฮสต์ devdocs เองและใช้ zeal สำหรับ Linux (ตัวดูเอกสารออฟไลน์) แล้วช่วยแก้ปัญหาเรื่องเอกสารออฟไลน์ไปได้เยอะ
    devdocs github
    หน้าเว็บทางการของ zealdocs

  • ทุกครั้งที่มี downtime ผมจะใช้มันเป็นโอกาสใหม่ในการค้นหาจุดอ่อนของระบบตัวเอง ถ้าเป็นปัญหาจาก upstream ที่เลี่ยงไม่ได้ก็คงช่วยไม่ได้ แต่ถ้าเป็นสถานการณ์ที่มีทางรับมือได้ ผมชอบวางสถานการณ์โดยหาสมดุลระหว่างต้นทุนกับความน่าจะเป็น และตัวงานแบบนี้ก็สนุกสำหรับผมด้วย

  • ผมเป็นคนหนึ่งที่เคยผลักแนวคิดออฟไลน์สุดทางมาแล้ว ช่วงที่อินเทอร์เน็ตถูกตัดขาดโดยสมบูรณ์กลับเป็นช่วงที่ productivity ในงานของผมสูงที่สุด ผมมี bash alias สำหรับเซฟทั้งเว็บไซต์แบบ recursive ด้วย wget, ใช้ yt-dlp เก็บวิดีโอที่อยากได้, มีสำเนา Wikipedia แบบออฟไลน์ทั้งชุดผ่าน Kiwix, อีเมลก็เก็บไว้ในเครื่องและรองรับการเขียนแบบออฟไลน์พร้อม queue ส่งเมล, ส่วนส่วนขยาย SingleFile ก็มีประสิทธิภาพมากในการเก็บหน้าเว็บรายหน้า และ Zeal ก็เป็นเครื่องมือที่แนะนำได้ในฐานะตัวดูเอกสารโอเพนซอร์ส

  • ผมเห็นด้วยกับปัญหา “NixOS ใช้ออฟไลน์ไม่ได้ถ้าไม่มี cache ของตัวเอง” สำหรับซอฟต์แวร์ที่ใช้ package manager การมี cache หรือ backup ของ repository เป็นสิ่งจำเป็นมาก จุดที่น่ากังวลที่สุดของแนวทางพัฒนาซอฟต์แวร์สมัยนี้คือ ระบบทั้งหมดจะทำงานได้สมบูรณ์ก็ต่อเมื่อทุกคนที่อยู่ปลายทางของ dependency tree ยังทำหน้าที่ของตัวเองต่อไปอยู่ สำหรับซอฟต์แวร์ฝั่ง end user ผมมองว่าแพ็กเกจเดี่ยวที่รวม dependency ทั้งหมดไว้ด้วยดีกว่ามาก เพราะสุดท้ายของที่ถูกเก็บลงดิสก์จริง ๆ ก็คือรูปแบบแบบนั้นอยู่แล้ว

  • Kiwix (โซลูชันออฟไลน์สำหรับ Wikipedia) และการตั้งค่า jellyfin หลากหลายรูปแบบเป็นทรัพยากรออฟไลน์ที่ทรงพลังมาก แต่ดิสโทรอย่าง NixOS, Gentoo และอื่น ๆ มักต้องพึ่งการเชื่อมต่ออินเทอร์เน็ตอย่างต่อเนื่อง การ mirror แพ็กเกจทั้งหมดแทบเป็นไปไม่ได้ในทางปฏิบัติ

• สำหรับคำแนะนำที่ว่า “ให้ซื้อโดเมนก่อน” จริง ๆ แล้วโดเมนเป็นของที่เช่า ไม่ใช่ของที่ซื้อได้จริง ถ้าชำระเงินพลาดแค่ครั้งเดียวก็โดนยึดคืนทันที มันน่ากลัวพอสมควร และชวนให้เศร้ากับความไม่จีรังของตัวตนบนโลกออนไลน์แบบนี้

  • ในส่วนที่ว่า “โดเมนเป็นแค่ของเช่า” ถ้าคุณใช้เฉพาะ root zone/registry ที่ ICANN รับรองก็ใช่ แต่ผมทดลองสร้าง registry ของตัวเองและรัน custom root zone ที่ไม่แชร์กับคนอื่นมาหลายปีแล้ว ผมยังทดลองใช้ custom TLD เพื่อทำหน้าที่บรรจุระบบการจำแนกประเภทสินค้า/บริการทั้งโลกไว้ในชื่อโดเมน และได้สัมผัสด้วยตัวเองถึงความกำกวมและความไม่เหมาะสมของ TLD แบบ ICANN

  • นี่เป็นข้อจำกัดทางเทคนิคอย่างหนึ่ง ถ้าตั้งค่าให้อุปกรณ์ทั้งหมดของผม (ซึ่งเป็นผู้ใช้ชื่อโดเมน) ยอมรับว่าทุกสิ่งที่เซ็นด้วย public key เฉพาะเป็น “XorNot.com” ระบบนี้ก็แทนที่ของเดิมได้ ในเชิงเทคนิค ถ้ามีการรองรับมากกว่านี้ ผมคิดว่าเราสามารถแทนที่โครงสร้างทั้งหมดในตอนนี้ด้วย “รายชื่อชื่อ-กุญแจที่เชื่อถือได้” ได้เลย

• ตอนนี้เป็นยุคที่ ecosystem ของเครื่องมือสำหรับ self-hosting พัฒนาไปไกลมาก เริ่มจากคอมโพเนนต์แบบ hosted ก่อน แล้วค่อย ๆ เปลี่ยนแต่ละส่วนมา self-host ทีละตัวก็ได้ บล็อกของผมเองก็ self-host อยู่บนเซิร์ฟเวอร์ที่บ้าน
  ด้านหน้าผมใช้ Cloudflare Tunnel แต่ก่อนหน้านี้ก็เคยใช้ nginx+letsencrypt+public_ip และส่วนจัดเก็บข้อมูลก็สลับได้หลากหลายทั้ง Cloudflare R2, S3 หรือ NAS ภายในบ้าน (ถ้าใช้ผ่าน FUSE วิธีเข้าถึงก็ยังเหมือนเดิม)
  ในทางกลับกัน ทรัพยากรที่จำเป็นต้องเช่าจริง ๆ มีแค่โดเมน (ต่อให้ดูเหมือนซื้อก็เป็นแค่เช่า) กับการเชื่อมต่ออินเทอร์เน็ตเท่านั้น ส่วนองค์ประกอบอื่นตอนนี้แทบทั้งหมดเป็นตัวเลือก จะใช้หรือไม่ใช้ก็ได้ แน่นอนว่าถ้าปิดบริการบางตัวก็อาจไม่สะดวก แต่การทำงานพื้นฐานยังอยู่
  เดี๋ยวนี้มันง่ายขึ้นมากจริง ๆ เมื่อเทียบกับสมัยก่อน เครื่องมือในยุค 90s ถึงต้น 2000s นั้นแทบจินตนาการไม่ถึงเลย
  ข้อเสียอย่างเดียวคือเงื่อนไขป้องกันสแปมอีเมลเข้มงวดขึ้นมาก เมื่อ 8 ปีก่อนผมยังรันเมลเองอยู่ แต่ตอนนี้ใช้ G Suite แทน

• ผมคิดว่าประเด็นสำคัญไม่ใช่ “จะ self-host หรือไม่” แต่คือ “มีความสามารถที่จะ self-host ได้หรือไม่” มุมมองที่ยอมรับได้กว่าคือ ถึงคุณจะขาดทักษะหรืออยากจ่ายเงิน ก็ยังเลือกฝากให้คนอื่นดูแลได้ คนที่คิดแค่ว่า “จ่ายเงินก็จบ” ต่างหากที่ระยะยาวมีความเสี่ยงที่สุด ทุกวันนี้ธุรกิจจำนวนมากออกแบบมาเพื่อจับลูกค้าไว้ด้วยการเอาการพึ่งพาทางเทคนิคระยะยาวมาเป็นตัวประกัน ถึงจะไม่ได้สนใจ FOSS ก็เถอะ แต่ความสามารถในการย้ายออกจากผู้ให้บริการยังเป็นเรื่องสำคัญมาก ถ้าถูก lock-in เมื่อไร คุณก็อาจถูกปฏิบัติอย่างไม่เป็นธรรมได้ทุกเมื่อ และมีหลายบริษัทที่คิดทุกอย่างบนโครงสร้างแบบนี้จริง ๆ

  • แนวคิด “credible exit” ที่พูดถึงใน Bluesky ก็ค่อนข้างคล้ายกับเรื่องนี้อยู่บ้าง
    ผมชื่นชม Zulip มากในฐานะบริการที่รองรับทั้งโอเพนซอร์ส, self-hosting, cloud service และการย้ายข้ามกันไปมา

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

• แค่เรียนพื้นฐาน Linux ก็มักทำให้หลายคนรู้สึกถึงเสน่ห์ของ self-hosting ต่อให้ไม่ได้จำเป็นจริง ๆ ก็ยังมีความสุขจากการได้ “รันบริการของตัวเอง” และความรู้สึกสำเร็จ
  ผลลัพธ์ที่สำคัญกว่าคือ การลดความเสี่ยงในโลกจริงที่เราจะถูกเตะออกจากแพลตฟอร์มที่พึ่งพาอยู่ทั้งหมดโดยไม่มีเหตุผล ถ้าแม้แต่บัญชี Gmail ก็หายไป คนทั่วไปอาจเดือดร้อนหนัก เพราะทั้งตัวตนออนไลน์ การรีเซ็ตรหัสผ่าน หรือแม้แต่การล็อกอินแอปต่าง ๆ ก็อาจถูกปิดกั้นไปหมด ผมเชื่อว่าใน Hacker News เองก็น่าจะมีคนที่ถ้าบัญชี Gmail หาย ชีวิตจะลำบากมาก ดังนั้นอย่างน้อยอัตลักษณ์ด้านอีเมลควรเป็นของเราเอง และหลักการนี้ก็ควรถูกนำไปใช้ซ้ำกับเว็บโฮสติ้ง, AWS, Spotify, Netflix และบริการออนไลน์ทุกอย่างด้วย การบอกว่า “ก็ย้ายไปโฮสต์คลาวด์รายใหม่สิ” ไม่ได้แก้ปัญหานี้จริง

  • ข้อมูลเรื่องการติดตั้งอีเมลเซิร์ฟเวอร์มีเยอะและทำได้ไม่ยาก แต่สิ่งที่ผมเสียดายคือแทบไม่มีข้อมูลเรื่องการปฏิบัติการจริงเวลาเรารันเองเลย โดยเฉพาะเรื่องความเข้ากันได้หรือการรับมือเหตุขัดข้อง เช่น ถ้า Google ขึ้นแบล็กลิสต์เซิร์ฟเวอร์ของผม ผมควรติดต่อใคร หรือมีขั้นตอนรับมือข้อความ error แบบไหนบ้าง ในภาคปฏิบัติกลับแทบไม่มีที่ให้ขอความช่วยเหลือ สิ่งที่ต้องการคือคู่มือว่ารับมือกับปัจจัยภายนอกที่ไม่สมเหตุสมผลอย่าง global IP block อย่างไร ไม่ใช่แค่ปัญหาโปรโตคอลอย่าง DKIM หรือ DNS แต่เป็นแนวทางปฏิบัติในการรับมือผู้ให้บริการรายอื่นในโลกจริง

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

  • ความเสี่ยงนั้นมีจริงและชัดเจน แต่ผมก็ไม่แน่ใจว่ามันเป็นความเสี่ยงที่เกิดกับคนจำนวนมากจริงหรือไม่ เหตุผลที่ผู้ใช้ Gmail ยุคแรกจำนวนมากหันไปใช้ก็เพราะคุณภาพของทางเลือกเดิมแย่มาก ไม่ว่าจะเป็นเมลจาก ISP หรือเมลมหาวิทยาลัย/ที่ทำงาน ต่างก็เป็นระบบที่บัญชีหายได้ทุกเมื่อถ้าไม่ต้องการคุณแล้ว self-hosting อาจช่วยแก้ปัญหาได้ “บางส่วน” แต่ถ้าคุณไม่มีความสามารถในการรักษาความปลอดภัย ต่อให้เมลเซิร์ฟเวอร์นั้นคุณดูแลเอง ก็ไม่ได้แปลว่าคุณมีอำนาจควบคุมสมบูรณ์ ยังมีเรื่องอย่างการต่ออายุโดเมนที่ต้องดูแล และถ้าละเลย สุดท้ายบัญชีก็หายได้อยู่ดี ผมเข้าใจว่าทำไมผู้ให้บริการรายใหญ่ไม่กี่เจ้าถึงยังได้รับความนิยม สำหรับคนส่วนใหญ่แล้ว ในระยะสั้นถึงกลาง นี่ก็ยังเป็นทางเลือกที่ดีกว่าอยู่ดี

  • เวลา self-hosting ที่บ้าน ผมมักถามตัวเองว่าระหว่างความเสี่ยงที่ HDD จะพัง กับความเสี่ยงที่จะเสียบัญชี Gmail อะไรมีโอกาสมากกว่ากัน เพราะพอเริ่มโฮสต์เองจริง ๆ ก็มีเรื่องให้ดูแลเพิ่มขึ้นอย่างรวดเร็ว ทั้งพื้นที่วางอุปกรณ์ การวางแผนแบ็กอัป และการจัดการอัปเดต แถมถ้าคิดเผื่อตอนอัปเดตหรือแบ็กอัปแล้วไฟดับ สุดท้ายก็ต้องมี UPS อีก แต่กรณีของผม UPS กลับเสียจนพาให้ฮาร์ดไดรฟ์ใน NAS พังไปด้วย สุดท้ายงานดูแลมันเยอะเกินไปจนเหลือเวลาโฟกัสกับชีวิตประจำวันน้อยลง

  • ผมมองว่า self-hosting อาจกลับสร้างความเสี่ยงที่สำคัญเสียเอง ถ้าทำ private key ในเครื่องหรือโดเมนอีเมลหลักหายไป ก็แทบกู้คืนไม่ได้ ขณะที่ 2FA และ account recovery กลับสะดวกกว่ามากเมื่อใช้บริการจากภายนอก ไม่ได้คัดค้าน self-hosting โดยตัวมันเองนะ แต่ผมคิดว่าสำหรับคนส่วนใหญ่ การมีทางกู้คืนบัญชีได้ยังเป็นทางเลือกที่ปลอดภัยกว่าเยอะ

• หลังจาก Arch Linux มีตัวติดตั้งอย่างเป็นทางการแล้ว ผมคิดว่าคงพูดว่ายังยากมากเหมือนเดิมไม่ได้แล้ว ถึงจะยังเริ่มผ่าน command line อยู่ แต่เมื่อเทียบกับสมัยก่อนที่ต้องปวดหัวกับการคำนวณบล็อกพาร์ทิชันอย่างซับซ้อน ทุกวันนี้ง่ายขึ้นมากจริง ๆ

• ที่บ้านผมจัดการทั้งคลัสเตอร์ Kubernetes 4 โหนดบน pi และ mini PC Intel N150 ผ่าน Portainer
  เครื่องมือโอเพนซอร์สด้านปฏิบัติการต่อไปนี้ทำให้ productivity ในการทำงานของผมเปลี่ยนไปมาก (ทั้งหมดรันในสภาพแวดล้อมคอนเทนเนอร์)

  • kubetail: ตัวดู log ของ K8S ทั้งคลัสเตอร์ ติดตั้งผ่าน Helm chart แนะนำมาก
  • Dozzle: ตัวดู docker log สำหรับ mini PC N150 (ที่นี่ใช้แค่ Docker ไม่ได้ใช้ Kubernetes) ติดตั้งด้วยมือผ่าน Portainer
  • UptimeKuma: สำหรับมอนิเตอร์และแจ้งเตือนเซิร์ฟเวอร์, http/https endpoint, PostgreSQL และอื่น ๆ ติดตั้งด้วยมือผ่าน Portainer
  • Beszel: มอนิเตอร์ CPU, หน่วยความจำ, ดิสก์, เครือข่ายของเซิร์ฟเวอร์ รวมถึง docker container ติดตั้งได้ทั้งผ่าน Helm chart/K8S หรือด้วยมือผ่าน Portainer
  • Semaphore UI: สำหรับตั้งเวลาและมี UI ให้ ansible playbook ติดตั้งด้วยมือผ่าน Portainer