3 คะแนน โดย GN⁺ 2025-10-06 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • บทความนี้เป็นเช็กลิสต์ที่บันทึกขั้นตอน self-hosting บน VPS ด้วย Hetzner และ Coolify แบบละเอียดทีละขั้นตอน
  • แนะนำ Hetzner เพราะมี latency ต่ำในยุโรป, ความคุ้มค่าต่อราคา สูง และ โครงสร้างค่าบริการที่โปร่งใส
  • ครอบคลุมประเด็นที่พบบ่อยในการใช้งานจริง เช่น การตั้งค่าเซิร์ฟเวอร์เริ่มต้น, ความปลอดภัยของ SSH, ไฟร์วอลล์, และการตั้งค่าอัปเดตอัตโนมัติ
  • อธิบายอย่างละเอียดเกี่ยวกับ การตั้งค่าสภาพแวดล้อม production, การมอนิเตอร์, การสำรองข้อมูล, และการแก้ปัญหา เพื่อ deploy แอป Node.js อย่างปลอดภัย
  • เป็นคู่มือเชิงปฏิบัติที่ช่วยให้คุณพัฒนา ทักษะ DevOps และ ความสามารถในการดูแลจัดการได้อย่างอิสระ ผ่านการสร้างเซิร์ฟเวอร์ด้วยตนเอง

เช็กลิสต์เตรียมการตั้งค่า VPS

  • ในหัวข้อการเลือกผู้ให้บริการ VPS มีการแนะนำ Hetzner ว่าเด่นด้าน ราคา/ประสิทธิภาพ
  • ควรเลือกสเปกอย่างน้อย 1GB RAM และ 20GB storage พร้อมบันทึก IP address ของเซิร์ฟเวอร์และข้อมูลบัญชี root
  • เตรียม SSH client บนเครื่อง local และใช้ ตัวสร้างรหัสผ่านที่แข็งแรง

เหตุผลที่เลือกผู้ให้บริการ VPS นี้

  • Hetzner Cloud มีจุดเด่นเรื่องราคาถูก เร็ว และเชื่อถือได้ใน ภูมิภาคยุโรป
  • ทางเลือกอื่น: DigitalOcean (onboarding/เอกสารดี แต่ราคาสูงขึ้น), AWS Lightsail (ผูกกับ AWS และยากกว่าสำหรับผู้เริ่มต้น), Linode (เสถียรแต่แข่งขันด้านราคาได้น้อยกว่า), Render/Fly.io (สะดวกในฐานะ PaaS แต่มีต้นทุนและข้อจำกัดมาก)
  • Hetzner ถูกกว่าราว 2–3 เท่าเมื่อเทียบกับสเปกเดียวกัน ไม่มีการคิดค่าบริการแบบไม่โปร่งใส และมีความได้เปรียบด้านดาต้าเซ็นเตอร์ในยุโรป

เช็กลิสต์การตั้งค่าเซิร์ฟเวอร์เริ่มต้น

การเชื่อมต่อครั้งแรกและอัปเดตระบบ

  • อัปเดตรายการแพ็กเกจและทำ system upgrade
  • มีคำสั่งสำหรับตรวจสอบข้อมูลระบบ (เช่น uname -a, cat /etc/os-release)

การตั้งค่าความปลอดภัยของบัญชี root

  • ต้องกำหนด รหัสผ่านที่ซับซ้อน และเก็บรักษาอย่างปลอดภัย
  • สร้าง บัญชีผู้ใช้ที่ไม่ซ้ำกัน แทนการใช้ชื่อบัญชีแบบคุ้นเคยอย่าง admin, user
  • มอบ สิทธิ์ sudo ให้บัญชีใหม่ และตรวจสอบว่านำไปใช้ได้ถูกต้อง

การตั้งค่าการยืนยันตัวตนด้วย SSH key

  • สร้างคู่กุญแจ Ed25519 (แนะนำ) หรือ RSA บน เครื่อง local
  • เพิ่ม public key ไปยัง .ssh/authorized_keys บนเซิร์ฟเวอร์และตั้งค่าสิทธิ์ให้ถูกต้อง
  • ตรวจสอบว่าการล็อกอินด้วย SSH key ทำงานปกติหรือไม่ (เชื่อมต่อได้โดยไม่ต้องใส่รหัสผ่าน)
  • ปิดการยืนยันตัวตนด้วยรหัสผ่าน และตรวจสอบไฟล์ cloud-init แยกต่างหากหากจำเป็น
  • รีสตาร์ต SSH daemon และตรวจสอบสถานะการทำงาน
  • ปิด root login เพื่อยืนยันว่าบล็อกการเข้าถึง root จากระยะไกลแล้ว

เช็กลิสต์การตั้งค่าไฟร์วอลล์ (Firewall)

การตั้งค่าพื้นฐานของ UFW

  • ปฏิเสธ inbound ทั้งหมดเป็นค่าเริ่มต้น และอนุญาต outbound
  • อนุญาตพอร์ต SSH, HTTP(80), HTTPS(443) และตรวจสอบว่ามีการใช้ UFW แล้ว
  • ตัวเลือกเพิ่มเติม: จำกัดพอร์ต SSH ให้เข้าถึงได้จากบาง IP, เปลี่ยนหมายเลขพอร์ต (เพื่อเพิ่มความปลอดภัย) เพื่อสร้างชั้นป้องกันเพิ่มเติม

เช็กลิสต์การตั้งค่าอัปเดตอัตโนมัติ

การตั้งค่า Unattended Upgrades

  • ติดตั้งแพ็กเกจ unattended-upgrades, apt-listchanges และเลือกยอมรับการใช้งานเริ่มต้น
  • สามารถยกเลิกคอมเมนต์ส่วนของ security updates และตั้งค่าอีเมลแจ้งเตือน รวมถึงตัวเลือกรีบูตอัตโนมัติได้
  • ทดสอบการทำงานของการอัปเดตอัตโนมัติและตรวจสอบสถานะ

เช็กลิสต์การ deploy แอปพลิเคชัน production

การตั้งค่าสภาพแวดล้อม Node.js สำหรับ production

  • ติดตั้ง Node.js LTS และตรวจสอบเวอร์ชัน
  • อัปโหลดไฟล์แอปพลิเคชันขึ้นเซิร์ฟเวอร์ แล้วติดตั้ง dependencies เพื่อเตรียมพร้อมสำหรับการใช้งานจริง

การใช้ process manager (PM2)

  • ใช้ PM2 รันแอปในโหมด production พร้อมตัวเลือก clustering
  • ตั้งค่าให้ PM2 เริ่มทำงานอัตโนมัติเมื่อบูต และมีคำสั่งสำหรับ restart/monitoring

การตั้งค่า Reverse Proxy (Nginx)

  • สร้างไฟล์ตั้งค่าไซต์ของ Nginx และกำหนด proxy pass
  • เปิดใช้งานไซต์และรีสตาร์ต Nginx

เช็กลิสต์การตั้งค่าใบรับรอง SSL

Let's Encrypt และ Certbot

  • ติดตั้ง certbot, python3-certbot-nginx แล้วออก ใบรับรอง SSL แบบอัตโนมัติตามโดเมน
  • มีตัวเลือกสำหรับการต่ออายุอัตโนมัติและการทดสอบความถูกต้องของใบรับรอง

เช็กลิสต์การมอนิเตอร์และการดูแลรักษา

วิธีมอนิเตอร์พื้นฐาน

  • ติดตั้ง เครื่องมือตรวจสอบทรัพยากรระบบ เช่น htop, iotop
  • มอนิเตอร์ log แบบเรียลไทม์ของ syslog, auth.log และตั้งค่านโยบายหมุนเวียน log (logrotate)

กลยุทธ์การสำรองข้อมูล

  • เขียน สคริปต์สำรองข้อมูลแอปพลิเคชันและฐานข้อมูล โดยใช้ tar
  • ทำการสำรองข้อมูลตามรอบเวลาเป็นประจำด้วย crontab

เช็กลิสต์การแก้ปัญหา

ปัญหาการเชื่อมต่อ SSH

  • ตรวจสอบการตั้งค่าไฟร์วอลล์, สถานะบริการ SSH, authentication log, และเครือข่าย

ข้อผิดพลาดที่เกี่ยวกับสิทธิ์

  • ตรวจสอบสิทธิ์ไฟล์/โฟลเดอร์, กลุ่ม, และการตั้งค่า sudo

บริการไม่เริ่มทำงาน

  • ใช้ systemctl, journalctl เพื่อตรวจสอบสถานะและ log พร้อมตรวจสอบไวยากรณ์ของไฟล์ตั้งค่า

การใช้ทรัพยากรมากเกินไป

  • วิเคราะห์ process/disk/network/application log

เช็กลิสต์การตรวจสอบขั้นสุดท้าย

การตรวจสอบด้านความปลอดภัย

  • ทบทวนว่าทุกรายการทำงานครบถ้วนหรือไม่ เช่น การยืนยันตัวตนด้วย SSH key/การล็อกอินด้วยรหัสผ่าน/root login/ไฟร์วอลล์/อัปเดตอัตโนมัติ/โหมด production/SSL/การสำรองข้อมูล

การทดสอบประสิทธิภาพ

  • ใช้ Apache Bench ทำ load test พร้อมมอนิเตอร์ทรัพยากรและตรวจสอบ error log

รายการคำสั่งอ้างอิงแบบรวดเร็ว

ตรวจสอบข้อมูลระบบ

  • htop, df -h, free -h, uname -a

การจัดการ process

  • pm2 status, pm2 restart all, pm2 logs, pm2 monit

ด้านความปลอดภัย

  • sudo ufw status, sudo fail2ban-client status, sudo lynis audit system

การจัดการบริการ

  • sudo systemctl status nginx, sudo systemctl restart nginx, sudo journalctl -u nginx

สรุปท้ายบท

  • เช็กลิสต์นี้ครอบคลุม ขั้นตอนการตั้งค่าและดูแล VPS แบบครบถ้วน
  • นอกจากต้นทุนที่ประหยัดแล้ว ยังช่วยให้ได้ การดูแลจัดการด้วยตนเอง การเรียนรู้ และอิสระแบบ DevOps
  • การทำ self-hosting ด้วย Hetzner และ Coolify ช่วยให้สัมผัส ความน่าเชื่อถือและอิสระจากประสบการณ์จริง
  • เป็นเนื้อหาที่ทำหน้าที่เป็น คู่มือเชิงปฏิบัติ สำหรับผู้ที่อยากเริ่มต้นกับ VPS hosting

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

 
GN⁺ 2025-10-06
ความคิดเห็นจาก Hacker News
  • คิดว่านี่เป็นสรุปที่ดีมากสำหรับมือใหม่แบบผม ตั้งใจจะบุ๊กมาร์กไว้แน่นอน
    แต่ที่น่าเสียดายคือแม้ชื่อเรื่องจะพูดถึง Coolify แต่ในเนื้อหาแทบไม่ได้พูดถึงเลย
    อีกบทความที่มีประโยชน์ในหัวข้อคล้ายกันคือ 'Setting up a Production-Ready VPS from Scratch' ผมเลยบุ๊กมาร์กลิงก์นี้ไว้ด้านล่าง
    https://dreamsofcode.io/blog/setting-up-a-production-ready-vps-from-scratch
    เวลาอยากเข้าใจหัวข้อแบบนั้นให้ลึกขึ้น ผมมักจะเอาลิงก์บทความไปใส่ใน LLM แล้ว
    "นี่คือบทความเกี่ยวกับ 'หัวข้อ/ชื่อเรื่อง': https://article.link. ช่วยทำความเข้าใจและวิเคราะห์มันให้ดี จากนั้นขยายแต่ละส่วนด้วยความรู้ของคุณ และเพิ่มส่วนที่เกี่ยวข้องเพิ่มเติมด้วย"
    แล้วใช้พรอมป์ต์แบบนี้เพื่อเรียนรู้

    • ผมมีวิดีโอสอนที่ช่วยผมมากตอนตั้งค่า Coolify ครั้งแรก เลยอยากแนะนำ
      https://www.youtube.com/watch?v=taJlPG82Ucw
      ผมใช้งานการตั้งค่านี้มาประมาณ 1 ปีแล้ว และเป็นครั้งแรกที่รู้สึกมั่นใจกับการ self-hosting
  • OVH ก็เชื่อถือได้พอๆ กับ Hetzner แต่ตอนนี้มีแพ็กเกจที่ถูกกว่ามาก
    https://us.ovhcloud.com/vps/configurator/?planCode=vps-2025-model3&brick=VPS%2BModel%2B3&pricing=upfront12&processor=%20&vcore=8__vCore&storage=200__SSD__NVMe
    ถ้าจะใช้ Coolify ผมกำลังลังเลว่าจะเลือกดิสโทรอะไรดี
    ระหว่าง Ubuntu 24.04 กับ Debian 13 อะไรเป็นตัวเลือกที่ดีกว่ากัน

    • OVH VPS - 24 vCPU (หรือ thread), RAM 96GB ราคา $53.4/เดือน
      Hetzner VPS (ตัวเลือก AMD) คือ 16vCPU, 32GB, $54.9/เดือน
      DO Droplet คือ 16vCPU, RAM 64GB ราคา $504/เดือน
      Linode กับ Upcloud ก็อยู่ที่ 24~20vCPU, RAM 96GB ราคา $576/เดือน ซึ่งแพงกว่า OVH มากเมื่อเทียบกัน
      ผมไม่รู้ว่า OVH ใช้ CPU อะไร แต่ต่อให้คิดถึงส่วนต่างราคา แม้จะเป็น Intel E-Core CPU แบบนี้ก็ยังถือว่าคุ้มมาก
      อีกอย่าง Hetzner ก็มีตัวเลือก Intel vCPU ที่ถูกกว่า แต่เป็นฮาร์ดแวร์รุ่นเก่า และจะมีสล็อตว่างก็ต่อเมื่อลูกค้าคนอื่นยกเลิก
      ดังนั้นผมเลยใช้เฉพาะตัวเลือก AMD รุ่นใหม่มาเปรียบเทียบ

    • ปัญหาเดียวของ OVH คือถ้าจะเช่า VPS (ราว $30/เดือน) คุณต้องส่งสำเนาบัตรประชาชนให้เขา
      ผมไม่อยากกระจายข้อมูลส่วนตัวแบบนั้น สุดท้ายเลยเลือกที่ที่แพงกว่า

    • จากประสบการณ์ของผม (ซึ่งก็ไม่ได้ยาวนานมาก) cloud server ของ Hetzner ให้ประสิทธิภาพดีกว่า OVH VPS มาก
      แต่ก็ใช้งานทั้งสองที่ได้อย่างน่าพอใจ

    • ผมสงสัยว่าทำไม OVH กับ Hetzner ถึงถูกกว่าผู้ให้บริการรายอื่นมากขนาดนี้
      พอเป็น VPS ก็เข้าใจได้ระดับหนึ่งว่าแชร์กันมากกว่าเจ้าอื่น แต่สองเจ้านี้แม้แต่ dedicated server ก็ยังถูกมาก
      เลยสงสัยว่ามันเป็นสินค้าแบบล่อเหยื่อหรือเปล่า และก็อยากรู้เหมือนกันว่าราคา OVH เพิ่งเปลี่ยนไม่นานนี้หรือไม่
      เพราะจำได้ว่าเมื่อหลายปีก่อนมันแพงกว่า Hetzner

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

  • ในการตั้งค่า CSS ผมปิดสองอย่างนี้แล้ว UI/UX ของบล็อกดีขึ้นมาก
    pre {
    margin: 2rem 0 !important;
    padding: 1rem !important;
    }
    padding กับ margin ของ code block ใหญ่เกินไปจนบนหน้าจอเห็นได้แค่ 3 บรรทัด
    และถ้าติดตั้ง Webmin/Virtualmin ไว้ งานอย่างการเพิ่มซับโดเมนใหม่หรือเพิ่มผู้ใช้ก็จะง่ายขึ้นมาก

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

  • ตอนนี้ผมจัดการทุก service บน VM ด้วย Docker Compose มาตลอด เลยกดเข้ามาเพราะสงสัยว่า Coolify จะเป็นทางเลือกที่ดีกว่าวิธีนี้อย่างชัดเจนหรือไม่
    แต่กลับไม่มีเนื้อหาเกี่ยวกับ Coolify จริงๆ เลย และงาน manual ที่ต้องทำเพื่อเตรียมให้ Coolify ดูซับซ้อนกว่าเดิมเสียอีก
    วิธีของผมที่ “ใช้ Docker Compose base image แล้วปรับแต่งอีกนิดหน่อย” ดูง่ายกว่ามาก
    เลยรู้สึกว่าวิธีที่ผมใช้อยู่ยังคงใช้ต่อได้สบาย
    ข้อดีคือถ้าจะย้ายข้ามโฮสต์ ส่วนใหญ่ 99% ก็แค่คัดลอกไฟล์ Docker Compose YAML ไฟล์เดียว

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

    • ถ้า Coolify หรือโปรเจกต์คล้ายกันไม่รองรับการสำรองข้อมูล DB และ streaming replication มันก็จะยังอยู่แค่ในระดับงานอดิเรก
      ผมรัน 2 VM ด้วย Docker Compose กับ bash script แล้วตั้งค่าแค่ backup รายชั่วโมงไปยัง S3, wal streaming, และ streaming replication ของ PG กับ Redis เท่านี้ผมก็มองว่าเป็น minimum requirement สำหรับ production จริงได้แล้ว

    • มันก็ขึ้นอยู่กับ use case แต่ผมเคยใช้ทั้ง Coolify และ CapRover
      สุดท้ายผมเลือก CapRover เพราะมันสามารถ auto build ผ่าน Git Hook ทุกครั้งที่มี commit ได้ ทำให้ deploy แอป NodeJS ได้เร็วกว่า
      ทั้งคู่รองรับฟีเจอร์นี้ แต่ CapRover มีแรงเสียดทานน้อยกว่า
      ส่วน Coolify มีฟีเจอร์มากกว่า

    • Coolify ทำงานอยู่บน Traefik กับ Docker และโดยพื้นฐานก็คือเอา UI มาครอบอีกที
      มันยังขาดฟีเจอร์สำคัญด้าน backup อีกมาก (แม้จะแก้ได้ด้วย restic อะไรทำนองนั้น) และ UX ก็อยู่ในระดับพอใช้

    • Coolify ยังต้องใช้สิทธิ์ root ตอนติดตั้ง
      ได้ยินมาว่ากำลังพัฒนา branch ที่ติดตั้งได้โดยไม่ต้องใช้สิทธิ์ root
      คุณน่าจะ ssh เข้าเซิร์ฟเวอร์ไปติดตั้ง Coolify ก่อน แล้วค่อยปิด root login หลังจากนั้นก็ได้
      ถ้าคุณพร้อมจะล้างเซิร์ฟเวอร์แล้วตั้งใหม่จากศูนย์เมื่อเกิดปัญหา วิธีนี้ก็ทำได้
      ช่วงหลังผมเองก็ลอง deploy Coolify ใหม่ทั้งหมดตั้งแต่ต้น แต่เจอ error เรื่อง ssh key ซ้ำๆ
      แม้จะ deploy หลายโปรเจกต์บนเซิร์ฟเวอร์อื่นได้ดี แต่แนวทางแบบ “แค่ให้ docker compose file มาก็พอ” นั้นในความเป็นจริงไม่เคยเวิร์กสำหรับผมเลยแม้แต่ครั้งเดียว

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

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

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

  • เครื่องมืออย่าง Coolify (รวมถึง Dokploy) ก็ดูน่าสนใจ แต่ผมรู้สึกเสมอว่ามันมีข้อเสียตรงที่สถานะของเซิร์ฟเวอร์ไม่ได้ถูกเก็บไว้ในโค้ด
    เพราะงั้นผมเลยชอบ NixOS หรือ Ansible มากกว่า แต่การตั้ง production จริงกลับต้องใช้ boilerplate และการคัสตอมเยอะเกินไป
    มีใครรู้จักเฟรมเวิร์ก infrastructure as code ที่ไม่ใช่ Kubernetes แต่ declarative กว่า และช่วยจัดการ production server ได้ง่ายกว่านี้ไหม

    • ผมเคยพยายามทำแบบนั้นกับ Coolify
      แทบไม่มีอะไรในฝั่งการตั้งค่า Coolify ที่ต้อง backup และการตั้งค่าแอปทั้งหมดก็อยู่ใน /data/coolify
      ผม backup ทั้ง volume ด้วย kopia
      มันไม่ใช่วิธีที่สวยงามนัก ออกจะเป็นลูกเล่นแก้ขัดมากกว่า แต่ก็ใช้เป็นแนวทางสำหรับ disaster recovery ได้
  • เป็นไกด์ที่ดี
    แต่ผมไม่เห็นด้วยกับการตั้งค่า firewall โดยเฉพาะถ้าใช้ Hetzner
    ถ้าต้องการแค่การตั้งค่าง่ายๆ firewall ที่ Hetzner ให้มาก็เพียงพออยู่แล้ว และยังมีผลแบบ “outsourcing” อีกด้วย
    ถ้าอยากปรับแต่งมากขึ้นก็สามารถตั้งค่าผ่าน API ได้
    https://docs.hetzner.cloud/reference/cloud#firewalls
    ผมสงสัยว่า firewall ของ Hetzner มีข้อเสียร้ายแรงอะไรหรือเปล่า

    • ในไกด์เขาบอกว่าที่เลือก Hetzner แทน cloud เจ้าอื่น เป็นเพราะต้องการให้ย้ายคอนฟิกไปที่ไหนก็ได้ง่าย โดยไม่ติด vendor lock-in
  • ผมคิดว่าคำแนะนำที่ว่า "อนุญาต SSH เฉพาะจาก IP ของคุณเท่านั้น (เป็นตัวเลือกแต่แนะนำ)" นั้นค่อนข้างเสี่ยง
    ถ้า IP เปลี่ยน คุณอาจถูกล็อกไม่ให้เข้าถึงทั้งหมดได้

    • คุณอาจรีเซ็ตผ่านแดชบอร์ด Hetzner ได้ แต่แทนที่จะผูกกับ IP บ้านที่เปลี่ยนตลอด การใช้ Tailscale หรือ
      มี external VPN IP แบบคงที่น่าจะดีกว่า

    • แค่ใช้การยืนยันตัวตนด้วย key สำหรับ SSH ก็แทบจะป้องกันปัญหาด้านความปลอดภัยส่วนใหญ่ได้แล้ว
      จะเพิ่มชั้นสำหรับลด log noise อีกก็ได้ และถ้ามี service ที่ไม่จำเป็นต้องเปิดออกสู่ภายนอกนอกจาก SSH
      ผมคิดว่าควรปิดไว้ด้วย VPN อะไรทำนองนั้น
      จริงๆ แล้วบนเซิร์ฟเวอร์มักมี service ที่เปราะบางกว่า SSH เสียอีก

    • มันเสี่ยงจริง
      หลายคนใช้อินเทอร์เน็ตบ้านแบบ IP แบบไดนามิก
      ผมคิดว่าแค่ตั้งค่า SSH key แล้วปิด root login ก็ปลอดภัยพอแล้ว

  • ผมคิดว่าส่วนการตั้งค่าแอป production ควรแทนที่ด้วย Docker จะดีกว่า
    ทุกวันนี้ Docker ทำซ้ำได้ง่ายกว่าและตั้งค่าก็ง่ายกว่ามาก

    • ถ้าอย่างนั้นผมก็อยากรู้ว่ามี walkthrough แบบละเอียดสำหรับวิธีนั้นอยู่ที่ไหน