สแต็กความเป็นส่วนตัวแบบ Self-Host ห้าชั้นที่ดีที่สุด

ในเดือนมีนาคม 2025 Krebs on Security รายงาน ว่านักสืบสวนระดับสหพันธรัฐของสหรัฐฯ ได้เชื่อมโยงการขโมยคริปโตเคอร์เรนซีมูลค่า 150 ล้านดอลลาร์เข้ากับเหตุการละเมิด LastPass ในปี 2022 โดยตรง กลไกนั้นง่าย: ลูกค้าบางรายเก็บ seed phrase ไว้ใน LastPass Secure Notes ผู้โจมตีได้สำเนาสำรองของ vault ที่เข้ารหัสไว้ และการปกป้อง vault ที่อ่อนแอหรือเก่ากว่าทำให้เนื้อหาบางส่วนของ vault ถูกถอดรหัสแบบ offline ได้

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

โพสต์นี้สำหรับผู้อ่านที่ threat model คือการเปิดเผยข้อมูลเชิงพาณิชย์ หมายถึงการหาเงินจากข้อมูลของ Big Tech และเหตุการละเมิดของผู้ขาย ไม่ใช่การสอดแนมระดับรัฐ งานข่าวความเสี่ยงสูง การเคลื่อนไหว หรือการค้นหาทางกฎหมาย สถาปัตยกรรมด้านล่างคือสแต็กห้าชั้นสำหรับ threat model เฉพาะนั้น

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

สแต็กนี้มีห้าชั้น แต่ละชั้นกำจัดการพึ่งพา Big Tech ทั่วไปหนึ่งอย่าง แต่ไม่มีชั้นใดทำให้คุณล่องหนได้

• เครือข่าย: WireGuard แทน VPN เชิงพาณิชย์ และจำกัดการมองเห็นของ ISP หรือเครือข่ายในพื้นที่
• ตัวตน: Vaultwarden แทนตัวจัดการรหัสผ่านแบบ hosted และลดการเปิดเผยจากเหตุการละเมิดฝั่งผู้ขาย
• การค้นหา: SearXNG ลดการทำโปรไฟล์จากการค้นหาด้วยการ proxy การค้นหาผ่าน VPS ของคุณ และเก็บมันไว้นอกบัญชีค้นหาที่คุณล็อกอินอยู่
• ไฟล์และภาพถ่าย: Nextcloud AIO และ Immich แทน Google Drive และ Google Photos ตัดการสแกนเนื้อหาบนคลาวด์และการรวมข้อมูลข้ามผลิตภัณฑ์
• การสื่อสารในทีม: Mattermost หรือ Rocket.Chat ย้ายประวัติแชทของทีมออกจาก Slack, Discord หรือ Teams
• ข้อจำกัดหลัก: ผู้ให้บริการ VPS ของคุณยังเห็นเมตาดาต้าของโครงสร้างพื้นฐานได้ ISP ของคุณยังเห็นว่าคุณเชื่อมต่อกับเซิร์ฟเวอร์ของคุณได้ และสแต็กนี้ไม่ได้สร้างมาสำหรับศัตรูระดับรัฐ
• หมายเหตุด้านเขตอำนาจศาล: การโฮสต์ในสหภาพยุโรปเสริมความแข็งแกร่งให้กรณีอธิปไตยของข้อมูล แต่มันไม่ใช่โล่วิเศษ

การ Self-Host เปลี่ยนความไว้วางใจ ไม่ได้กำจัดมัน

มีการถกเถียงที่ดำเนินมายาวนานบน Hacker Newsและมันถูกต้องในแง่ผิวเผิน: "การ self-host บน VPS ไม่ได้แก้ปัญหาความเป็นส่วนตัว คุณแค่ไปไว้ใจผู้ขายอีกรายหนึ่ง" ใครก็ตามที่ออกแบบสถาปัตยกรรมความเป็นส่วนตัวควรเผชิญหน้ากับเรื่องนี้โดยตรงแทนที่จะหลบเลี่ยง คำตอบตรง ๆ คือการเปลี่ยนความไว้วางใจนั้นไม่สมมาตร มันไม่เท่าเทียมกัน

เริ่มจากสิ่งที่การ self-host ลดลง โมเดลธุรกิจของผู้ให้บริการ SaaS ของคุณไม่ได้เป็นการขุดข้อมูลของคุณอีกต่อไป เพราะผู้ให้บริการหายไปแล้ว การเปิดเผยจากเหตุการละเมิดฝั่งผู้ขายเปลี่ยนรูปร่าง: vault ของ Vaultwarden เข้ารหัสฝั่ง client แต่บริการที่เซิร์ฟเวอร์อ่านได้อย่าง Nextcloud, Mattermost และ Rocket.Chat ยังต้องการการ harden ที่เหมาะสม การสำรองข้อมูล และการควบคุมการเข้าถึง

บทเรียน LastPass ไม่ใช่ว่าการเข้ารหัส vault ไม่เคยมีอยู่ มันคือว่าสำเนาสำรอง vault ที่เข้ารหัสแต่ถูกขโมย เมตาดาต้าที่ไม่ได้เข้ารหัส การตั้งค่า KDF ที่เก่ากว่า และรหัสผ่านหลักที่อ่อนแอ สร้างเส้นทางการถอดรหัสแบบ offline การทำโปรไฟล์เชิงพฤติกรรมข้ามบริการก็หดตัวลงด้วย เพราะมีข้อมูลข้ามบริการน้อยลงให้บริษัทเดียวประกอบเข้าด้วยกัน การล็อกติดกับการสมัครสมาชิกลดลง

ทีนี้ สิ่งที่การ self-host ไม่ได้กำจัด hypervisor ของผู้ให้บริการ VPS ของคุณสามารถอ่านหน่วยความจำของ VM ของคุณได้ในหลักการ ผู้ให้บริการ VPS ของคุณเห็นเมตาดาต้าระดับโครงสร้างพื้นฐานของคุณ: คุณเชื่อมต่อกับ IP ไหน เมื่อใด และข้อมูลเคลื่อนไหวมากแค่ไหน

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

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

ในสหภาพยุโรป ผู้ให้บริการดำเนินงานภายใต้ GDPR และข้อกำหนดตามสัญญาเฉพาะ ทั้งหมดนี้ไม่ได้ทำให้ VPS ปลอดภัยกว่า Google ในทุกมิติ มันเป็น threat model ที่ต่างกันพร้อมโปรไฟล์การเปิดเผยที่ต่างกัน และสำหรับ threat model ที่โพสต์นี้พูดถึง มันเป็นการปรับปรุงที่มีนัยสำคัญ

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

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

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

สแต็กห้าชั้นโดยสังเขป

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

ประเด็นสำคัญของส่วนนี้: เริ่มด้วย WireGuard, Vaultwarden และ SearXNG ถ้าคุณต้องการสแต็กความเป็นส่วนตัวที่เบาที่สุด เพิ่ม Nextcloud, Immich และ team chat หลังจากที่คุณพร้อมสำหรับการใช้ RAM ที่สูงขึ้น การวางแผนพื้นที่จัดเก็บ การสำรองข้อมูล และงานดูแลระบบที่มากขึ้น

ชั้นที่ 1: ชั้นเครือข่าย (WireGuard)

ไฟล์ตั้งค่าของ WireGuard สำหรับการตั้งค่าผู้ใช้เดี่ยวทั่วไปมีสิบสองบรรทัด การ handshake ของมันเสร็จในการเดินทางไปกลับเพียงครั้งเดียวและใช้กรอบโปรโตคอล Noise โมดูล kernel อยู่ใน mainline Linux ตั้งแต่ 5.6 ซึ่งหมายความว่าโปรโตคอลที่คุณ deploy ในปี 2026 เป็นตัวเดียวกับที่ผ่านการตรวจสอบและเสถียรมาหลายปี นี่คือค่าเริ่มต้นที่ถูกต้อง

ชั้นนี้จัดการอะไร: ผู้สังเกตการณ์ ISP และเครือข่ายในพื้นที่ที่มิฉะนั้นจะเห็นทุกโดเมนที่คุณเชื่อมต่อ ผู้โจมตีบน Wi-Fi สาธารณะ และ IP บ้านของคุณที่ถูกเปิดเผยต่อทุกบริการที่คุณเข้า ทราฟฟิกของคุณ egress ออกจาก VPS ของคุณแทนที่จะจากอพาร์ตเมนต์ของคุณ

สิ่งที่มันไม่จัดการ: มุมมองของผู้ให้บริการ VPS ที่มีต่อ egress ทราฟฟิกของคุณ พวกเขาเห็นว่า VPN endpoint ของคุณเชื่อมต่อกับอะไร เมื่อใด และมากแค่ไหน WireGuard ซ่อนทราฟฟิกจาก ISP ของคุณ มันไม่ซ่อนทราฟฟิกจากเซิร์ฟเวอร์ที่ดำเนินการ egress

การรั่วของ DNS ก็เป็นปัญหาแยกต่างหากและไม่ได้ถูกจัดการโดยอัตโนมัติ คุณต้องชี้ VPN client ของคุณไปยัง resolver ที่คุณไว้ใจ รัน Unbound บน VPS ตัวเดียวกัน หรือใช้ upstream ที่ไว้ใจได้ผ่าน DoT หรือ DoH การบล็อกโฆษณาในระดับ DNS เต็มรูปแบบด้วย Pi-hole เป็นหัวข้อแยกต่างหากและไม่ใช่สิ่งที่ควรรวมกับ VPN egress สำหรับผู้ใช้ส่วนใหญ่ (เพิ่มเติมด้านล่าง)

WireGuard เทียบกับทางเลือกอื่นโดยสังเขป OpenVPN ยังใช้ได้ การ handshake ใหญ่กว่า รอยเมตาดาต้าใหญ่กว่า และ throughput ต่ำกว่า ไม่มีเหตุผลที่จะเลือกมันสำหรับการ deploy ใหม่ เว้นแต่คุณต้องการฟีเจอร์เฉพาะที่ WireGuard ไม่มี

Tailscale เป็นเครื่องมือคนละแบบ: มันเป็น mesh แบบ zero-config ที่สร้างบน WireGuard และยอดเยี่ยมสำหรับการเย็บบริการ self-host ของคุณเองเข้าด้วยกันข้ามเครื่อง มันไม่ใช่สิ่งที่คุณต้องการในฐานะ privacy egress สู่อินเทอร์เน็ต เพราะระนาบการประสานงานถูก host โดย Tailscale

หมายเหตุ: การเปลี่ยนพอร์ตเริ่มต้น 51820/UDP สามารถลดการสแกนแบบใช้แรงน้อยได้ แต่มันไม่ทำให้ WireGuard ดูเหมือนทราฟฟิก HTTPS ทั่วไปหรือเลี่ยงการกรองที่จริงจัง ให้ถือว่าเป็นการลดการสแกน ไม่ใช่การพรางตัว

สำหรับการ deploy เรามี คู่มือการตั้งค่า WireGuard สำหรับ Ubuntu แบบทีละขั้นตอนที่เข้าคู่กับสถาปัตยกรรมนี้

ประเด็นสำคัญของส่วนนี้: WireGuard บน VPS ของคุณให้ egress เครือข่ายส่วนตัวที่ ISP ของคุณตรวจสอบไม่ได้ แต่มันไม่ซ่อนทราฟฟิกของคุณจากผู้ให้บริการ VPS ที่ดำเนินการ egress

ชั้นที่ 2: ชั้นตัวตน (Vaultwarden)

Vaultwarden รันในพื้นที่ RAM ต่ำกว่า 200 MB มันเป็นการเขียน Bitwarden API ใหม่ด้วย Rust เข้ากันได้กับ Bitwarden client อย่างเป็นทางการทุกตัว (ส่วนขยายเบราว์เซอร์ แอปเดสก์ท็อป แอปมือถือ) และไม่ต้องการ image อ้างอิงเซิร์ฟเวอร์ Bitwarden ที่หนักหน่วง สำหรับผู้ใช้เดี่ยวหรือครัวเรือน นี่คือขนาดที่เหมาะสม

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

สิ่งที่มันไม่จัดการ: OpSec ของคุณเอง รหัสผ่านหลักที่อ่อนแอ ไม่มี 2FA บน vault หรือการฟิชชิ่งที่สำเร็จต่อคุณ ทำลายชั้นนี้ลงทั้งหมด อุปกรณ์ที่ถูกเจาะพร้อมส่วนขยายเบราว์เซอร์ที่ล็อกอินอยู่ทำลายมันยิ่งกว่า Vaultwarden เป็น vault ไม่ใช่ตัวแทนของพื้นฐาน

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

XDA Developers ก็ได้ ครอบคลุมความเสี่ยงนี้โดยตรงโดยเตือนว่าตัวจัดการรหัสผ่านแบบ self-host สามารถล็อกคุณออกจากบัญชีสำคัญได้ถ้าการเข้าถึง การสำรองข้อมูล หรือการวางแผนกู้คืนล้มเหลว

คำเตือน: รันการสำรองข้อมูลแบบเข้ารหัสอัตโนมัติของไดเรกทอรีข้อมูล Vaultwarden เก็บ export แบบเข้ารหัส offline ไว้ เก็บรหัสกู้คืนแยกต่างหาก และทดสอบการกู้คืนบนอุปกรณ์สำรองหรือ container ชั่วคราว อย่าพึ่งพาการสำรองข้อมูล VPS ตัวเดียว นี่ไม่ใช่ทางเลือก นี่คือราคาของการเอา vault ออกจากโครงสร้างพื้นฐานของผู้ขาย

ถ้าคุณกำลังรวมศูนย์ single sign-on ข้ามบริการ self-host หลายตัวในภายหลัง Authentik เป็นผู้ให้บริการตัวตนแบบโอเพนซอร์สที่คนส่วนใหญ่ลงเอยด้วย นั่นเป็นชั้นขั้นสูงและอยู่นอกขอบเขตของสแต็กหลัก

สำหรับการ deploy คู่มือการ self-host Vaultwarden ของเรา เป็นเพื่อนคู่การ deploy สำหรับการดูภูมิทัศน์ตัวจัดการรหัสผ่านอย่างลึกซึ้งกว่า ดูคู่มือของเราเรื่อง ตัวจัดการรหัสผ่านแบบ self-host ที่ดีที่สุด.

ประเด็นสำคัญของส่วนนี้: Vaultwarden ย้าย vault รหัสผ่านของคุณออกจากโครงสร้างพื้นฐานของผู้ขายที่เสี่ยงต่อการละเมิด แต่มันโยนภาระการสำรองข้อมูลและการกู้คืนมาที่คุณ และภาระนั้นมีจริง

ชั้นที่ 3: ชั้นการค้นหาและการเรียกดู (SearXNG)

อินสแตนซ์ SearXNG รับ query ของคุณ กระจายมันไปยังเอนจินต้นทาง (Google, Bing, DuckDuckGo และอื่น ๆ ที่คุณเปิดใช้งาน) ตัดพารามิเตอร์ที่ระบุตัวตนบางส่วนออก และส่งหน้าผลลัพธ์รวมกลับมา

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

ชั้นนี้จัดการอะไร: การทำโปรไฟล์จาก search query การกำหนดเป้าโฆษณาเชิงพฤติกรรมที่อิงกับประวัติการค้นหาที่คุณล็อกอินอยู่ และความทรงจำอันยาวนานของบัญชีค้นหา ปัญหา "ทำไมฉันเห็นโฆษณาของสิ่งที่ค้นหาเมื่อวาน" ลดลงในระดับบัญชีค้นหา

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

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

Whoogle Search เป็นทางเลือกที่เบากว่า มันเป็น front-end ของ Google ง่ายกว่า และทำสิ่งเดียว SearXNG รวมหลายเอนจิน ซึ่งมีประโยชน์กว่าถ้าเหตุผลที่คุณออกจาก Google ไม่ใช่ Google โดยเฉพาะ เลือกตามจำนวนแหล่งที่คุณต้องการจริง ๆ

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

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

ชั้นที่ 4: ชั้นไฟล์และภาพถ่าย (Nextcloud AIO + Immich)

Nextcloud AIO คือการ deploy Nextcloud แบบ Docker ครบในตัว และเป็นเส้นทางที่ต้านทานน้อยที่สุดสู่เซิร์ฟเวอร์ file-sync ปฏิทิน รายชื่อ และการทำงานร่วมเอกสารที่ใช้งานได้

Immich เป็นคู่หูฝั่งภาพถ่าย: มุมมองไทม์ไลน์ การอัปโหลดอัตโนมัติจากมือถือทั้ง iOS และ Android การจดจำใบหน้าแบบ Google Photos ที่ประมวลผลบนเซิร์ฟเวอร์ของคุณเองหรือ ML host ที่คุณเลือก และฉันทามติชุมชนที่ซื่อตรงว่ามันเป็นตัวแทน Google Photos ที่ใช้งานได้ดีที่สุดที่กำลังออกอยู่ในปัจจุบัน

สิ่งเหล่านี้ไม่ใช่แอปพลิเคชันที่เบา Nextcloud AIO ควรถูกถือว่าเป็นพื้นฐาน 4 GB / 2 vCPU machine learning การสร้าง thumbnail และการสแกนไลบรารีครั้งแรกของ Immich จะใช้ทรัพยากรเท่าที่คุณให้

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

การแทนที่สิ่งนี้ด้วยเซิร์ฟเวอร์ที่คุณควบคุมทำลายการรวมศูนย์นั้น

สิ่งที่มันไม่จัดการ: ไบต์ยังคงอยู่บนโวลุ่มจัดเก็บที่ผู้ให้บริการ VPS ของคุณดำเนินการ การเข้ารหัสขณะพักเป็นความรับผิดชอบของคุณ ไม่ใช่ของพวกเขาเป็นค่าเริ่มต้น การถูกเจาะฝั่งอุปกรณ์เป็นปัญหาแยกต่างหาก ถ้าโทรศัพท์ของคุณถูก root Nextcloud client บนนั้นก็ถูกเปิดเผยไม่ว่าเซิร์ฟเวอร์จะอยู่ที่ไหน

ถ้าความต้องการเดียวของคุณคือ "เก็บโฟลเดอร์เหล่านี้ให้ sync กันระหว่างอุปกรณ์ของฉัน" Syncthing เป็นเครื่องมือที่ง่ายกว่า มันเป็นแบบ peer-to-peer ไม่มีเซิร์ฟเวอร์ตรงกลาง และทำงานนั้นได้ดี มันไม่ใช่ตัวแทนของฟีเจอร์ปฏิทิน รายชื่อ และการทำงานร่วมที่ Nextcloud ให้ มันเป็นตัวแทนของส่วนย่อย file-sync เท่านั้น

สำหรับ Immich โดยเฉพาะ มีกฎการกำหนดขนาดเชิงปฏิบัติหนึ่งข้อที่สำคัญ Nextcloud AIO ควรถูกถือว่าเป็นพื้นฐาน 4 GB / 2 vCPU Immich ไม่ใช่ตัวเสริมภาพถ่ายแบบเบาเมื่อ machine learning, thumbnail และการสแกนไลบรารีครั้งแรกเข้ามาในภาพ วางแผนราว 6-8 GB RAM สำหรับการตั้งค่าที่เน้น Immich โดยเฉพาะระหว่างการย้ายข้อมูล

สำหรับการ deploy เรามี การเปรียบเทียบ Nextcloud กับ ownCloud สำหรับผู้ใช้ที่ยังเลือกระหว่างสองตัว และภาพรวมที่กว้างกว่าเรื่อง แพลตฟอร์มคลาวด์แบบ self-host ที่มี web UI ถ้าคุณกำลังสำรวจพื้นที่นี้

ประเด็นสำคัญของส่วนนี้: Nextcloud และ Immich ย้ายไฟล์และภาพถ่ายออกจากบัญชีคลาวด์แบบ Google ได้ แต่พวกมันเป็นชั้นแรกในสแต็กนี้ที่ต้องการ RAM พื้นที่จัดเก็บ การวางแผนสำรองข้อมูล และความอดทนในการย้ายข้อมูลอย่างจริงจัง

ชั้นที่ 5: ชั้นการสื่อสาร (Mattermost หรือ Rocket.Chat)

Slack workspace ค้นหาได้โดย Slack Discord สแกนเนื้อหาเพื่อหาการละเมิด ToS Microsoft Teams เก็บบันทึกแชทไว้ภายใต้นโยบายของ tenant ของคุณ ซึ่งเป็นนโยบายที่องค์กร IT ของคุณมองเห็นได้

สำหรับแชทในทีมหรือครอบครัวที่ไม่ควรอยู่ในที่เหล่านั้น Mattermost หรือ Rocket.Chat แบบ self-host คือคำตอบมาตรฐาน ชั้นนี้เกี่ยวกับการเก็บคลังข้อมูลของทีมไว้นอก SaaS ไม่ใช่เรื่องแชทแบบ end-to-end ส่วนตัว

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

สิ่งที่มันไม่จัดการ และเรื่องนี้สำคัญ: การเข้ารหัสแบบ end-to-end Mattermost และ Rocket.Chat ไม่ใช่ E2EE เป็นค่าเริ่มต้น ผู้ดูแลเซิร์ฟเวอร์อ่านข้อความได้ ผู้ดูแลเซิร์ฟเวอร์ตอนนี้คือคุณ ซึ่งดีกว่าการเป็นพนักงานของผู้ขาย SaaS แต่หลักการนี้ยังสำคัญสำหรับ threat model ของทีมคุณ

สำหรับการส่งข้อความแบบปลอดภัยตัวต่อตัว Signal คือคำตอบที่ถูกต้อง ไม่ใช่เซิร์ฟเวอร์แบบ self-host ถ้าชั้นการสื่อสารต้องเป็น E2EE เป็นค่าเริ่มต้น ให้ดู Matrix/Element หรือใช้ Signal สำหรับแชทส่วนตัวแทน การ self-host แก้ปัญหาการส่งข้อความในทีมโดยไม่มีผู้ขาย มันไม่ได้แทนที่ Signal สำหรับ threat model ส่วนตัว

Mattermost เทียบกับ Rocket.Chat ทั้งคู่ใช้ได้ Mattermost แน่นกว่า มีรูปร่างเหมาะกับองค์กรมากกว่า และมีฟีเจอร์เสริมที่เปิดเป็นค่าเริ่มต้นน้อยกว่า Rocket.Chat กว้างกว่า เชื่อมต่อช่องทางได้หลากหลายกว่า และมีระบบนิเวศปลั๊กอินที่ใหญ่กว่า ทั้งคู่ใช้ได้ดีสำหรับกรณีใช้งานทั่วไปของสแต็กความเป็นส่วนตัวอย่างทีมเล็กหรือแชทครอบครัว

ข้อควรระวังปี 2026: ตรวจสอบ edition ฟรีที่แน่นอนก่อน deploy Mattermost Mattermost Entry มีเพดานประวัติ 10,000 ข้อความ ขณะที่ Team Edition เลี่ยงเพดานนั้นแต่มีข้อจำกัดของตัวเอง สำหรับ Rocket.Chat ตั้งงบให้มากกว่า VPS 1 GB จิ๋ว ๆ เพราะ MongoDB การอัปโหลด และการเชื่อมต่อเพิ่มภาระ

ประเด็นสำคัญของส่วนนี้: Mattermost หรือ Rocket.Chat แบบ self-host ย้ายคลังแชทของทีมคุณออกจากผู้ขาย SaaS แต่ถ้าคุณต้องการการเข้ารหัสแบบ end-to-end จริง ๆ ระหว่างคนสองคน Signal ยังเป็นเครื่องมือที่ถูกต้อง

สิ่งที่ไม่ควร Self-Host (และเหตุผล)

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

อีเมล อย่า self-host อีเมลถ้าคุณยังไม่ใช่ผู้ดูแล Linux ที่มีประสบการณ์และต้องการทำมันโดยเฉพาะ PrivacyGuides มีจุดยืนที่ชัดเจนและเป็นที่รู้จักเรื่องนี้ และมันถูกต้อง: เฉพาะผู้ใช้ขั้นสูงเท่านั้นที่ควรรันเมลเซิร์ฟเวอร์ของตัวเอง เหตุผลไม่ใช่ความอยากรู้ทางเทคนิค SPF, DKIM และ DMARC ต้องถูกตั้งค่าและรักษาให้ถูกต้อง

ชื่อเสียงของ IP ต้องสร้างและรักษาไว้ การกรองสแปมเป็นสภาวะถาวร การต่อสู้เรื่องการส่งถึงกับ Gmail ไม่ใช่ขั้นตอนการตั้งค่า มันเป็นสภาวะที่ดำเนินอยู่ตลอด สำหรับคนอื่น ๆ ผู้ให้บริการที่เคารพความเป็นส่วนตัวแบบบริหารจัดการคือคำตอบที่ถูกต้องจริง ๆ สำหรับชั้นนี้

Proton Mail, Tuta (เดิมชื่อ Tutanota) และ Mailbox.org ล้วนเป็นตัวเลือกที่ดี นี่คือกฎเหล็กของโพสต์นี้: อย่า self-host อีเมลเพื่อความเป็นส่วนตัวของผู้ชมทั่วไป

Pi-hole เป็น DNS resolver หลักของเครือข่ายบ้านคุณ บน VPS Pi-hole นั้นเยี่ยม การวางมันบน VPS เป็น recursive resolver สำหรับอินเทอร์เน็ตของทั้งครัวเรือนเป็นจุดล้มเหลวจุดเดียวที่ทำให้อินเทอร์เน็ตพังสำหรับทุกคนในบ้านเมื่อ VPS สะดุด Pi-hole เหมาะกับ Raspberry Pi ที่บ้าน มันไม่ใช่ส่วนหนึ่งของสแต็กนี้

โซเชียลมีเดียแบบ federated Mastodon, Pleroma และตัวอื่น ๆ น่าสนใจและอยู่ใกล้เคียง การยอมรับใช้งานเป็นข้อจำกัดหลัก ไม่ใช่ความเป็นส่วนตัว พวกมันเป็นคำตอบที่ถูกต้องสำหรับบางคน แต่ไม่ใช่แกนหลักของสแต็กความเป็นส่วนตัวที่มุ่งเอาข้อมูลของคุณเองออกจากเซิร์ฟเวอร์ของ Big Tech

เครื่องมือความนิรนาม Tor, I2P, mixnet threat model ต่างกัน โพสต์ต่างกัน ถ้าคุณต้องการมัน คุณก็รู้อยู่แล้ว

สรุป: Proton Mail หรือตัวเทียบเคียงเป็นทางเลือกแบบบริหารจัดการสำหรับชั้นหนึ่งชั้นโดยเฉพาะ และการยอมรับสิ่งนั้นเป็นส่วนหนึ่งของสแต็กที่ควรค่าแก่การใช้ การ self-host ช่วยตรงที่ผู้ให้บริการเหล่านั้นไม่ครอบคลุม workflow เต็ม: ภาพถ่าย การค้นหา การวิเคราะห์แบบกำหนดเอง และแชทในทีม สำหรับความเป็นส่วนตัวของผู้ชมทั่วไป อีเมลคือชั้นเดียวที่สแต็กนี้ควรจ้างภายนอก

ประเด็นสำคัญของส่วนนี้: ผู้ใช้ส่วนใหญ่ไม่ควร self-host อีเมล ผู้ให้บริการแบบบริหารจัดการที่เคารพความเป็นส่วนตัวอย่าง Proton Mail คือคำตอบที่ดีกว่าจริง ๆ สำหรับชั้นเดียวนั้น และการยอมรับมันเป็นส่วนหนึ่งของการสร้างสแต็กที่น่าไว้วางใจ

รันมันที่ไหน: การกำหนดขนาด VPS และเขตอำนาจศาล

คำถามเรื่องขนาดไม่ใช่นามธรรม สแต็กนี้มีสามรูปแบบเชิงปฏิบัติ: แกนความเป็นส่วนตัวแบบเบา ชั้นไฟล์ และเวอร์ชันที่เน้นภาพถ่ายซึ่งนำ machine learning ของ Immich เข้ามาผสม การกระโดดจากตัวหนึ่งไปอีกตัวไม่ใช่เรื่องผิวเผิน ไฟล์ thumbnail การจดจำใบหน้า และการย้ายไลบรารีครั้งแรกคือสิ่งที่เปลี่ยน VPS เล็ก ๆ ให้เป็นงบเซิร์ฟเวอร์ที่จริงจัง

อ่านตารางนี้แบบนี้:

• สแต็กขั้นต่ำ ครอบคลุมสามชั้นที่ให้ผลตอบแทนสูงสุด: เครือข่าย ตัวตน และการค้นหา
• Nextcloud พื้นฐาน ต้องการพื้นที่หายใจมากขึ้นเพราะ PHP งานฐานข้อมูล การทำดัชนีไฟล์ งาน sync และ web UI ทั้งหมดรันพร้อมกัน
• สแต็กไฟล์และภาพถ่าย ต้องการงบที่ใหญ่กว่าเพราะ machine learning ของ Immich, thumbnail, การจดจำใบหน้า และการสแกนไลบรารีภาพถ่ายครั้งแรกสามารถกระทบเซิร์ฟเวอร์อย่างหนักระหว่างการย้ายข้อมูล
• พื้นที่จัดเก็บ สำคัญเพราะการประมวลผลเป็นเพียงครึ่งหนึ่งของแผน ไฟล์และภาพถ่ายต้องการพื้นที่ให้เติบโต การสำรองข้อมูลที่อยู่ห่างจาก VPS และเส้นทางกู้คืนที่ยังใช้ได้ถ้าเซิร์ฟเวอร์หายไป

แล้วก็มีเรื่องเขตอำนาจศาล ในเดือนมิถุนายน 2025 Microsoft ให้การต่อรัฐสภาฝรั่งเศส ว่าไม่สามารถรับประกันได้ว่าข้อมูลที่โฮสต์ในสหภาพยุโรปจะได้รับการปกป้องจากการเข้าถึงทางกฎหมายของสหรัฐฯ คำให้การนั้นย้ายข้อโต้แย้งเรื่องอธิปไตยของข้อมูลออกจากทฤษฎีเข้าสู่การสนทนาเชิงนโยบายกระแสหลัก

สำหรับผู้ใช้ที่ให้ความสำคัญกับอธิปไตยของข้อมูล เขตอำนาจศาลของบริษัท ที่ตั้ง datacenter สัญญา โมเดลการเข้ารหัส และที่ตั้งการสำรองข้อมูล ล้วนสำคัญ

If CLOUD Act การเปิดเผยเป็นส่วนหนึ่งของความกังวล อย่าถือว่า datacenter ในสหภาพยุโรปเพียงอย่างเดียวเป็นคำตอบทั้งหมด ผู้ให้บริการที่ไม่ได้มีสำนักงานใหญ่ในสหรัฐฯ พร้อมภูมิภาคในยุโรปเหมาะสมกว่าภูมิภาคในสหภาพยุโรปของ hyperscaler ที่มีสำนักงานใหญ่ในสหรัฐฯ แต่นั่นก็ยังไม่ทำให้ข้อมูลแตะต้องไม่ได้ทางกฎหมาย

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

สำหรับ threat model ของผู้อ่านส่วนใหญ่ แรงเสียดทานที่เพิ่มเข้ามามีประโยชน์ มันไม่ใช่โล่วิเศษ

ประเด็นสำคัญของส่วนนี้: สแต็กแบบเบารันบน VPS ขนาดเล็กได้ แต่ไฟล์และภาพถ่ายเปลี่ยนงบประมาณ ใช้ 4 GB / 2 vCPU เป็นพื้นฐานสำหรับ Nextcloud เท่านั้น และวางแผนใกล้ ๆ 8 GB / 4 vCPU สำหรับการตั้งค่า Immich ที่เน้นภาพถ่าย Cloudzy Marketplace ลดความพยายามในการตั้งค่าสำหรับแอปหลัก ขณะที่เขตอำนาจศาลเพิ่มแรงเสียดทานทางกฎหมาย ไม่ใช่การล่องหน

วิธี Deploy สแต็กโดยไม่เปลี่ยนการตั้งค่าให้กลายเป็นทั้งโปรเจกต์

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

เส้นทางที่มีแรงเสียดทานน้อยกว่าคือเริ่มจาก image VPS ที่ใช้งานได้และ harden จากตรงนั้น Cloudzy Marketplace มี image VPS แบบติดตั้งคลิกเดียวสำหรับ WireGuard, Vaultwarden, SearXNG, Nextcloud AIO และเครื่องมือ self-host อื่น ๆ ดังนั้นการ deploy พื้นฐานจึงไม่ใช่ส่วนที่กินวันหยุดสุดสัปดาห์

งานที่ยังสำคัญคืองานที่ไม่มี marketplace ใดทำให้คุณได้: DNS กฎไฟร์วอลล์ การสำรองข้อมูล การควบคุมการเข้าถึง การอัปเดต และการทดสอบกู้คืน

เซิร์ฟเวอร์ที่อยู่ข้างใต้ก็ยังสำคัญด้วย สแต็กนี้คือพื้นที่จัดเก็บ เครือข่าย การเลือกภูมิภาค และพื้นที่หายใจ ไม่ใช่แค่ชื่อแอปในตาราง Cloudzy ให้โครงสร้างพื้นฐาน VPS ที่หนุนด้วย NVMe การเข้าถึง root เต็มรูปแบบ 13 ภูมิภาค เครือข่าย 40 Gbps อัปไทม์ 99.95% และช่วงคืนเงิน 14 วัน

เริ่มเล็กสำหรับ WireGuard, Vaultwarden และ SearXNG ขยับขึ้นสำหรับ Nextcloud วางแผนอย่างจริงจังกว่าสำหรับ Immich เมื่อ machine learning, thumbnail และการย้ายภาพถ่ายเข้ามาในภาพ

วิธีเริ่มต้น

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

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

การตั้งค่าชั้นใดชั้นหนึ่งใช้เวลามากที่สุดหนึ่งวันหยุดสุดสัปดาห์ ไฟล์ตั้งค่าสั้น ไม่มีเหตุผลที่มันจะซับซ้อนกว่านี้

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

การ Self-Host บน VPS ปกป้องความเป็นส่วนตัวของผมจริงไหม หรือผมแค่ไปไว้ใจผู้ขายอีกราย?

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

สแต็กความเป็นส่วนตัวแบบ Self-Host ขั้นต่ำที่ผมควรเริ่มคืออะไร?

เริ่มด้วย WireGuard, Vaultwarden และ SearXNG สามตัวนั้นครอบคลุมการมองเห็นเครือข่าย ความเสี่ยงจากการละเมิดของผู้ขายรหัสผ่าน และการทำโปรไฟล์การค้นหาที่คุณล็อกอินอยู่ บน VPS RAM 2 GB เพิ่ม Nextcloud ในภายหลัง เพิ่ม Immich หลังจากที่คุณมี RAM พื้นที่จัดเก็บ และวินัยการสำรองข้อมูลมากขึ้นเท่านั้น

การโฮสต์ในแฟรงก์เฟิร์ตหรืออัมสเตอร์ดัมดีต่อความเป็นส่วนตัวกว่าในสหรัฐฯ จริงไหม?

ภูมิภาคในยุโรปสามารถลดการเปิดเผยโดยตรงบางส่วนต่อผู้ให้บริการที่มีสำนักงานใหญ่ในสหรัฐฯ แต่พวกมันไม่ทำให้ข้อมูลแตะต้องไม่ได้ทางกฎหมาย เขตอำนาจศาลของบริษัท ที่ตั้ง datacenter สัญญา การเข้ารหัส และที่ตั้งการสำรองข้อมูล ล้วนสำคัญ คำขอทางกฎหมายของเยอรมัน เนเธอร์แลนด์ หรือสวิส ยังสามารถมีผลได้

ผมควร Self-Host อีเมลเพื่อความเป็นส่วนตัวไหม?

สำหรับเกือบทุกคน ไม่ การ self-host อีเมลต้องการ SPF, DKIM, DMARC, ชื่อเสียงของ IP, การกรองสแปม และงานเรื่องการส่งถึงอย่างต่อเนื่อง ใช้ผู้ให้บริการความเป็นส่วนตัวแบบบริหารจัดการอย่าง Proton Mail, Tuta หรือ Mailbox.org PrivacyGuides แนะนำการ self-host อีเมลเฉพาะสำหรับผู้ใช้ขั้นสูงเท่านั้น

WireGuard ปกป้องผมจากอะไรกันแน่?

WireGuard กำหนดเส้นทางทราฟฟิกผ่าน VPS ของคุณ จำกัดสิ่งที่ ISP และเครือข่ายในพื้นที่ของคุณเห็นได้ มันไม่ซ่อน egress ทราฟฟิกจากผู้ให้บริการ VPS พวกเขายังเห็นเมตาดาต้าการเชื่อมต่อ IP ปลายทาง จังหวะเวลา และปริมาณได้ มันคือความเป็นส่วนตัวจาก ISP ของคุณ ไม่ใช่การล่องหน