วิธีติดตั้ง Cloudron บน VPS ฉบับสมบูรณ์ พร้อมตั้งค่า DNS

การติดตั้ง Cloudron บน VPS: ฉบับย่อ

การติดตั้ง Cloudron บน VPS จำเป็นต้องใช้เซิร์ฟเวอร์ Ubuntu ที่ติดตั้งใหม่, RAM อย่างน้อย 2 GB และโดเมนที่คุณสามารถแก้ไขระเบียน DNS ได้ ขั้นตอนการติดตั้งมีเพียง 3 คำสั่งและการรีบูต 1 ครั้ง ปัญหาเกือบทั้งหมดที่เกิดขึ้นมักเกิดก่อนขั้นตอนนี้ (เช่น ใช้ base image ไม่ถูกต้อง หรือประเภทการทำ virtualisation ไม่เหมาะสม) หรือหลังจากนั้น (เช่น ปัญหา DNS, อีเมล หรือการสำรองข้อมูล)

wget https://cloudron.io/cloudron-setup
chmod +x cloudron-setup
sudo ./cloudron-setup

Cloudron ทำหน้าที่ติดตั้ง, อัปเดต, สำรองข้อมูล และออกใบรับรอง TLS (transport layer security) สำหรับแอปที่โฮสต์ด้วยตนเอง แอปทุกตัวจะทำงานใน Docker โดยมี nginx ทำหน้าที่เป็นหน้าด่านให้กับทุกแอป และแต่ละแอปจะได้รับ subdomain ของโดเมนคุณ รายละเอียดในส่วนหลังนี้คือเหตุผลที่ต้องดำเนินการเรื่อง DNS ก่อนเป็นอันดับแรก

เหตุผลที่ Cloudron เข้มงวดกับระบบปฏิบัติการพื้นฐาน

สคริปต์ติดตั้งจะตรวจสอบเซิร์ฟเวอร์ก่อนเริ่มการติดตั้งใดๆ หากไม่ผ่านการตรวจสอบ คุณจะต้องสั่งซื้อเซิร์ฟเวอร์ใหม่ โปรดอ่านข้อกำหนดเหล่านี้ก่อนเลือกอิมเมจ

• รองรับเฉพาะ Ubuntu และจำกัดเพียง 3 รุ่นเท่านั้น หากเป็นรุ่นอื่นสคริปต์จะหยุดทำงานด้วย Cloudron requires Ubuntu 20.04, 22.04, 24.04 ไม่รองรับ Debian, Rocky และ Alpine สำหรับ Ubuntu 24.04 จำเป็นต้องใช้ Cloudron 8 ขึ้นไป ซึ่งสคริปต์จะตรวจสอบให้คุณโดยอัตโนมัติ
• รองรับเฉพาะสถาปัตยกรรม 64-bit Intel หรือ AMD เท่านั้น: Error: Cloudron only supports amd64/x86_64 ไม่สามารถรันบน ARM VPS ได้
• ต้องเป็น Full hardware virtualisation เท่านั้น หากเป็น VPS แบบ container สคริปต์จะหยุดทำงานด้วย Error: Cloudron does not support lxc, only runs on bare metal or with full hardware virtualization เนื่องจากตรวจพบ container ผ่าน systemd-detect-virt --container โดย KVM สามารถใช้งานได้ แต่ OpenVZ และ LXC ไม่รองรับ
• ระบบไฟล์ root ต้องเป็น ext4 หรือ xfs หากเป็นรูปแบบอื่นจะได้รับข้อผิดพลาด Error: Cloudron requires '/' to be ext4 or xfs ซึ่งเป็นสาเหตุที่ทำให้อิมเมจ btrfs และ zfs ไม่ผ่านการตรวจสอบ
• ต้องมี RAM อย่างน้อย 941 MB และพื้นที่ว่าง 20 GB บน / ซึ่งวัดผลด้วย free -m และขนาดของระบบไฟล์ root
• ต้องเป็นเซิร์ฟเวอร์ที่ติดตั้งใหม่จริงๆ หากมีการติดตั้ง nginx, docker หรือ node อยู่ก่อนแล้ว สคริปต์จะปฏิเสธการทำงานด้วย Error: Some packages like nginx/docker/nodejs are already installed.

การตรวจสอบข้อสุดท้ายนี้เป็นสิ่งที่ผู้ใช้มักโต้แย้ง นี่คือเหตุผลเบื้องหลัง Cloudron จะติดตั้ง Docker, nginx, Node.js และ MySQL เวอร์ชันที่กำหนดไว้โดยเฉพาะ เขียนการตั้งค่า nginx สำหรับทุกแอปที่โฮสต์ และจัดการกฎ iptables firewall ด้วยตนเอง Docker ที่คุณติดตั้งไว้ก่อนหน้าจะเป็นเวอร์ชันที่ไม่ถูกต้อง และไฟล์เว็บไซต์ nginx เดิมของคุณจะถูกเขียนทับ Cloudron ต้องการสิทธิ์ควบคุมเครื่องทั้งหมด ดังนั้นควรจัดเตรียม VPS แยกเฉพาะให้มัน

มีการตรวจสอบอีกหนึ่งจุดที่มักถูกมองข้าม บน CPU รุ่นเก่าที่ไม่มี AVX (advanced vector extensions) สคริปต์จะแสดงข้อความ CPU has no AVX support. MongoDB will be disabled และแอปทุกตัวที่ต้องใช้ MongoDB จะไม่สามารถติดตั้งได้ ให้ตรวจสอบ CPU ก่อนเริ่มใช้งานด้วย grep -m1 -o avx /proc/cpuinfo ซึ่งจะแสดงผล avx บนโฮสต์ที่รองรับ และไม่แสดงผลใดๆ บนโฮสต์รุ่นเก่า

Cloudron ต้องการ RAM เท่าใด

สคริปต์จะปฏิเสธการทำงานหากมี RAM ต่ำกว่า 941 MB โดยจะแสดง Error: Cloudron requires atleast 1GB physical memory และในเอกสารประกอบระบุว่าต้องการ RAM 2 GB และพื้นที่ดิสก์ 20 GB ตัวเลขทั้งสองนี้เป็นค่าขั้นต่ำสำหรับตัวแพลตฟอร์มเอง ไม่ใช่สำหรับแพลตฟอร์มรวมกับแอปพลิเคชันของคุณ ก่อนที่คุณจะติดตั้งแอปแม้แต่ตัวเดียว Cloudron ได้รัน Docker, nginx, บริการ box ของตัวมันเอง, คอนเทนเนอร์ฐานข้อมูลที่จัดเตรียมไว้ให้แอป (MySQL, PostgreSQL, MongoDB), Redis และ stack สำหรับอีเมลอยู่แล้ว ให้ลองรัน docker ps บนการติดตั้งใหม่แล้วนับจำนวนดู

ขีดจำกัดหน่วยความจำของแอปจะถูกบวกเพิ่มจากฐานนี้ แพ็กเกจแอปแต่ละตัวจะกำหนดค่าเริ่มต้นไว้ต่ำ ซึ่งคุณสามารถเพิ่มได้โดยใช้แถบเลื่อนในมุมมอง Resources ของแอปนั้นๆ เมื่อแอปใช้หน่วยความจำเกินขีดจำกัด แอปจะรีสตาร์ทและส่งการแจ้งเตือน OOM (out of memory) ให้คุณ ดังนั้นหากเซิร์ฟเวอร์มีการรีสตาร์ทแอปตัวเดิมซ้ำๆ มักจะเป็นปัญหาเรื่องการตั้งค่าขีดจำกัดมากกว่าจะเป็นบั๊ก

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

[
  {
    "label": "2 apps (free tier)",
    "vcpu": 2,
    "ram_gb": 4,
    "disk_gb": 60
  },
  {
    "label": "5 apps",
    "vcpu": 4,
    "ram_gb": 8,
    "disk_gb": 120
  },
  {
    "label": "10 apps",
    "vcpu": 6,
    "ram_gb": 16,
    "disk_gb": 240
  }
]

แอปจำนวน 2 ตัวสามารถทำงานได้อย่างราบรื่นบน RAM 4 GB และดิสก์ 60 GB สำหรับแอปประมาณ 10 ตัว ควรใช้ RAM 16 GB และดิสก์ 240 GB เนื่องจากฐานของแพลตฟอร์มไม่เคยลดขนาดลง และแอปแต่ละตัวจะเพิ่ม Docker image, ฐานข้อมูล และข้อมูลของตัวมันเอง พื้นที่ดิสก์จะเต็มเร็วกว่าที่คาดไว้ เนื่องจาก image, ข้อมูลแอป และการสำรองข้อมูลในเครื่องจะใช้โวลุ่มเดียวกันจนกว่าคุณจะย้ายการสำรองข้อมูลออกไปภายนอก

Cloudron ให้สิทธิ์แอปทุกตัวใช้ swap ได้ไม่จำกัด ดังนั้นขีดจำกัดหน่วยความจำที่คุณตั้งค่าไว้จะมีผลกับ RAM เท่านั้น บน VPS ที่ไม่มีไฟล์ swap คำสั่ง swapon --show จะไม่แสดงผลใดๆ เลย และเมื่อเกิดภาวะหน่วยความจำไม่เพียงพอ แอปจะรีสตาร์ทด้วยข้อผิดพลาด OOM ทันทีแทนที่จะทำงานช้าลง การเพิ่ม swap ขนาด 2 GB เป็นการป้องกันที่คุ้มค่า แม้ว่าจะไม่สามารถทดแทนหน่วยความจำจริงได้ก็ตาม ส่วนต่างราคาของแผน VPS นั้นน้อยมากเมื่อเทียบกับเวลาที่คุณต้องเสียไปกับการปรับแต่งขีดจำกัด ดังนั้นให้ดู ราคาจริงของ VPS แล้วเลือกซื้อขนาดที่ใหญ่กว่าหนึ่งระดับจะดีกว่า

DNS: ระเบียน wildcard ที่ทำให้ subdomain ของแอปทำงานได้

Cloudron วาง dashboard ไว้ที่ my.example.com และแอปแต่ละตัวจะมี subdomain ของตัวเอง ดังนั้น DNS จึงเป็นสิ่งที่ต้องเตรียมไว้ก่อน ไม่ใช่ขั้นตอนที่ทำภายหลัง ให้ชี้ระเบียนเหล่านี้ไปยัง IP address สาธารณะของเซิร์ฟเวอร์ก่อนที่คุณจะเปิด dashboard เป็นครั้งแรก:

• my.example.com เป็นระเบียนชนิด A นี่คือส่วนของ dashboard
• *.example.com เป็นระเบียนชนิด A นี่คือส่วนที่ทำให้ subdomain ของแอปทำงานได้ ดังนั้น wiki.example.com และ git.example.com จะ resolve ได้ทันทีที่คุณติดตั้งแอปเหล่านั้น
• example.com เป็นระเบียนชนิด A ให้ใช้เฉพาะในกรณีที่คุณต้องการให้แอปทำงานบน bare domain

ระเบียน wildcard มีลำดับความสำคัญต่ำกว่าระเบียนที่ระบุเจาะจง ดังนั้น www.example.com ที่มีอยู่เดิมและชี้ไปยังที่อื่นจะยังคงทำงานได้ตามปกติ

ระหว่างการตั้งค่า คุณจะต้องเลือกวิธีที่ Cloudron จัดการ DNS หลังจากนั้น:

• ผู้ให้บริการผ่าน API: Cloudron จะจัดเก็บ token สำหรับ Cloudflare, DigitalOcean, Route53, Hetzner, Porkbun, Linode, deSEC, Gandi, Namecheap และผู้ให้บริการอื่นอีกประมาณ 20 ราย จากนั้น Cloudron จะเขียนระเบียนทุกอย่างด้วยตัวเอง รวมถึงระเบียนสำหรับอีเมล
• Wildcard: คุณต้องเพิ่มระเบียน * ด้วยตนเอง และ Cloudron จะไม่เขียนข้อมูลใดๆ ลงไป
• Manual: Cloudron จะแสดงระเบียนแต่ละรายการให้คุณเห็นและรอให้คุณเพิ่มระเบียนเหล่านั้นด้วยตนเองก่อนการติดตั้งแอปแต่ละครั้ง

ระเบียน DNS แบบ wildcard ไม่ใช่ใบรับรองแบบ wildcard ผู้ให้บริการใบรับรองเริ่มต้นคือ Let's Encrypt Prod - Wildcard ซึ่งต้องพิสูจน์ความเป็นเจ้าของผ่าน DNS ดังนั้นจึงใช้งานได้กับผู้ให้บริการผ่าน API เท่านั้น หากใช้ backend แบบ Wildcard หรือ Manual คุณจะต้องกลับไปใช้ใบรับรองหนึ่งใบต่อหนึ่งแอปซึ่งตรวจสอบผ่าน HTTP ซึ่งหมายความว่าพอร์ต 80 ขาเข้าจะต้องเปิดทิ้งไว้ตลอดเวลา หากผู้รับจดทะเบียนโดเมนหรือโฮสต์ DNS ของคุณอยู่ในรายการ API ให้เลือกใช้ตัวเลือกนั้น เพราะการจัดการระเบียนอีเมลและใบรับรองจะไม่ใช่หน้าที่ของคุณอีกต่อไป

ตรวจสอบให้แน่ใจก่อนดำเนินการต่อ dig +short my.example.com และ dig +short anything.example.com ควรแสดง IP address ของเซิร์ฟเวอร์คุณทั้งคู่ หากการสอบถามแบบ wildcard ไม่แสดงผลลัพธ์ แอปจะล้มเหลวในภายหลังในขณะที่ dashboard ยังคงทำงานได้ตามปกติ

หากโดเมนอยู่หลัง Cloudflare ให้ตั้งค่าระเบียนเป็น DNS only เนื่องจาก proxy จะส่งต่อเฉพาะ HTTP และ HTTPS เท่านั้น ซึ่งจะทำให้พอร์ตอีเมลใช้งานไม่ได้ และแอปทุกตัวจะเห็น IP address ของ Cloudflare แทนที่จะเป็น IP address ของผู้เข้าชม

เรียกใช้สคริปต์ติดตั้ง

wget https://cloudron.io/cloudron-setup
chmod +x cloudron-setup
sudo ./cloudron-setup

ให้เรียกใช้สคริปต์ในฐานะ root หรือผ่าน sudo เนื่องจากหากไม่ทำเช่นนั้น สิ่งแรกที่สคริปต์จะแสดงคือ This script should be run as root. การติดตั้งจะใช้เวลาหลายนาทีและไม่มีการแสดงผลระหว่างทำงาน เนื่องจากเอาต์พุตของ apt และการดึง Docker image จะถูกส่งไปยังไฟล์ log คุณสามารถตรวจสอบการทำงานได้จาก SSH session ที่สอง:

tail -f /var/log/cloudron-setup.log

เมื่อเสร็จสิ้น สคริปต์จะแสดง After reboot, visit one of the following URLs and accept the self-signed certificate to finish setup. ตามด้วยที่อยู่ของเซิร์ฟเวอร์ของคุณ จากนั้นจะถาม The server has to be rebooted to apply all the settings. Reboot now ? [Y/n] ให้ตอบว่า yes ทั้งนี้มีแฟล็ก --skip-reboot ให้ใช้หากคุณต้องการกำหนดเวลาการรีสตาร์ท แต่ Cloudron จะยังไม่สามารถใช้งานได้จนกว่าเซิร์ฟเวอร์จะกลับมาออนไลน์อีกครั้ง

การบูตครั้งแรก: โดเมน, DNS backend และบัญชีผู้ดูแลระบบ

เปิด https://<server-ip> และยอมรับคำเตือนของเบราว์เซอร์ ใบรับรองเป็นแบบ self-signed เนื่องจาก Cloudron ยังไม่ทราบโดเมนของคุณ จึงไม่มีข้อมูลที่จะร้องขอจาก certificate authority ใน Chrome ให้คลิก Advanced จากนั้นคลิก Proceed to <ip> (unsafe) ใน Firefox ให้คลิก Advanced จากนั้นคลิก Accept the Risk and Continue

หน้าจอแรกจะถามหาโดเมนของคุณ ให้ป้อน example.com แล้วแดชบอร์ดจะตั้งค่าอยู่ที่ my.example.com คุณสามารถใช้โดเมนย่อยเช่น cloudron.example.com แทนได้ ซึ่งแดชบอร์ดจะอยู่ที่ my.cloudron.example.com ให้เลือก DNS backend วาง API token หากคุณมี และสร้างบัญชีผู้ดูแลระบบด้วยที่อยู่อีเมลที่คุณใช้งานจริง เนื่องจากระบบจะใช้ที่อยู่นี้สำหรับการลงทะเบียน Let’s Encrypt และการแจ้งเตือนทั้งหมดของแพลตฟอร์ม

เมื่อคุณบันทึก Cloudron จะร้องขอใบรับรองและย้ายแดชบอร์ดไปยัง https://my.example.com หลังจากจุดนี้ URL ที่เป็นที่อยู่ IP จะหยุดทำงาน ดังนั้นให้บันทึก URL ใหม่ไว้ในบุ๊กมาร์ก

ใบรับรอง: สิ่งที่ต่ออายุและเวลาที่หยุดทำงาน

การต่ออายุใบรับรองเป็นไปโดยอัตโนมัติและเป็นไปตาม ACME Renewal Information (ARI) ซึ่งเป็นกำหนดการที่ผู้ออกใบรับรอง (Certificate Authority) ประกาศไว้ โดยในทางปฏิบัติจะต่ออายุล่วงหน้าประมาณหนึ่งเดือนก่อนหมดอายุ หากการต่ออายุล้มเหลว ระบบจะส่งอีเมลแจ้งเตือนไปยังบัญชีผู้ดูแลระบบ และหากใบรับรองหมดอายุ ระบบจะเปลี่ยนไปใช้ใบรับรองแบบ self-signed ที่มีมาให้ในตัวแทน การเปลี่ยนไปใช้ใบรับรองสำรองนี้คือสาเหตุที่ทำให้เบราว์เซอร์แสดงคำเตือนบนเว็บไซต์ที่เคยใช้งานได้ตามปกติเมื่อวานนี้

สาเหตุส่วนใหญ่เกิดจากสองปัจจัย การตรวจสอบสิทธิ์ผ่าน HTTP จำเป็นต้องใช้พอร์ต 80 ขาเข้า ดังนั้นการปิดพอร์ต 80 ด้วยเหตุผลที่ว่า "ทุกอย่างเป็น HTTPS อยู่แล้ว" จะทำให้การต่ออายุของทุกแอปพลิเคชันที่ใช้ Wildcard หรือ Manual DNS backend ล้มเหลว ส่วนการตรวจสอบสิทธิ์ผ่าน DNS จำเป็นต้องใช้ API token ที่ยังมีสิทธิ์เขียนข้อมูลได้ ดังนั้นการหมุนเวียน (rotate) หรือการจำกัดสิทธิ์ของ token ดังกล่าวจะทำให้การต่ออายุล้มเหลวโดยไม่มีการแจ้งเตือนจนกว่าอีเมลแจ้งเตือนจะถูกส่งมาถึง

ในมุมมอง Domains จะมีปุ่ม Renew All สำหรับบังคับให้ลองต่ออายุทันที และมีผู้ให้บริการ Let's Encrypt Staging สำหรับการทดสอบ ใบรับรองจาก Staging จะไม่ได้รับความเชื่อถือจากเบราว์เซอร์โดยเจตนา ซึ่งเป็นจุดประสงค์หลักเพื่อให้คุณสามารถลองใหม่ได้บ่อยเท่าที่ต้องการโดยไม่กระทบต่อขีดจำกัดอัตราการใช้งาน (rate limit) ของระบบจริง

คุณควรใช้ mail server ที่มาพร้อมกับระบบหรือไม่?

Cloudron มาพร้อมกับ mail stack ที่สมบูรณ์ซึ่งประกอบด้วย IMAP mailboxes, submission, sieve filters และการลงนาม DKIM (domainkeys identified mail) คุณสามารถเปิดใช้งานได้ในแต่ละโดเมนภายใต้หัวข้อ Email ในแดชบอร์ด การทำให้เมลถูกส่งถึงปลายทางเป็นส่วนที่ยากที่สุด และความยากลำบากนี้ไม่ได้เกิดจาก Cloudron

• พอร์ตขาออก 25 ถูกบล็อกโดยผู้ให้บริการ VPS ส่วนใหญ่เพื่อควบคุมสแปม ผู้ให้บริการบางรายอาจปลดบล็อกให้หลังจากเปิด support ticket ให้ทดสอบจากเซิร์ฟเวอร์ด้วย nc -zv aspmx.l.google.com 25 (ติดตั้ง netcat-openbsd หากไม่มีคำสั่งนี้) รายงานพอร์ตที่เปิดอยู่คือ succeeded หากพอร์ตถูกบล็อก การเชื่อมต่อจะค้างจนกว่าจะหมดเวลา (time out)
• PTR record (reverse DNS) ถูกกำหนดโดยผู้ให้บริการ VPS ของคุณ ไม่ใช่โดยโฮสต์ DNS และจะต้องตรงกับ mail hostname ของคุณ เมลที่ส่งมาจากที่อยู่ที่มี PTR ทั่วไปมักจะถูกจัดอยู่ในโฟลเดอร์สแปม
• SPF, DKIM และ DMARC records จะถูกเขียนให้โดยอัตโนมัติหากใช้ API DNS backend สำหรับ Wildcard หรือ Manual backends คุณต้องเพิ่ม record เหล่านี้ด้วยตนเอง และการขาด DKIM record หมายความว่าทุกข้อความที่คุณลงนามจะไม่สามารถตรวจสอบความถูกต้องได้

การตั้งค่าที่ใช้งานได้ดีสำหรับคนส่วนใหญ่คือการรับเมลบน Cloudron และส่งเมลผ่าน relay เช่น SendGrid, Postmark, Mailgun หรือ Amazon SES โดยกำหนดค่าในมุมมอง Email ตัว relay จะต้องอนุญาตให้ส่งเมลในนามของที่อยู่ใดก็ได้บนโดเมนของคุณ มิฉะนั้นการแจ้งเตือนจากแอปที่มาจากผู้ส่งที่แตกต่างกันจะถูกปฏิเสธ หากเมลเป็นเหตุผลหลักที่คุณซื้อเซิร์ฟเวอร์นี้ ให้รัน mail server เฉพาะทางอย่าง Mailcow บนเครื่องแยกต่างหากที่มี IP reputation ของตัวเอง

หากคุณไม่ได้ใช้ Cloudron Email เลย ให้บล็อกพอร์ต 25, 465, 587, 993 และ 4190 ใน firewall ของผู้ให้บริการของคุณ ให้ทำที่ระดับนั้นแทนที่จะทำบนเซิร์ฟเวอร์ เพราะ Cloudron เขียนกฎ iptables ด้วยตัวเองและคาดหวังที่จะเป็นผู้จัดการกฎเหล่านั้นแต่เพียงผู้เดียว ซึ่งตรงกันข้ามกับ VPS ทั่วไปที่คุณ จัดการกฎ ufw ด้วยตนเอง

กำหนดค่าปลายทางสำหรับสำรองข้อมูลก่อนที่คุณจะจำเป็นต้องใช้

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

ให้เปิดเมนู Backups จากนั้นไปที่ Backup Sites และกำหนดปลายทางไปยังตำแหน่งอื่นตั้งแต่วันแรก พื้นที่จัดเก็บแบบ Object Storage ที่รองรับ S3 เป็นตัวเลือกที่นิยมใช้กันทั่วไป (เช่น Backblaze B2, Wasabi, Cloudflare R2, DigitalOcean Spaces หรือ MinIO bucket บนเซิร์ฟเวอร์เครื่องที่สอง) นอกจากนี้ยังรองรับการเชื่อมต่อผ่าน SSHFS, NFS, CIFS และไฟล์ระบบทั่วไปอีกด้วย

การตั้งค่า 3 ประการต่อไปนี้จะเป็นตัวตัดสินว่าข้อมูลสำรองนั้นมีประโยชน์หรือไม่:

• รูปแบบ (Format): tgz จะเขียนไฟล์บีบอัดหนึ่งชุดต่อหนึ่งแอปและอัปโหลดใหม่ทั้งหมดในทุกรอบการทำงาน ส่วน rsync จะอัปโหลดเฉพาะไฟล์ที่มีการเปลี่ยนแปลงเท่านั้น ซึ่งประหยัดค่าใช้จ่ายมากกว่ามากสำหรับ Nextcloud ขนาดใหญ่ แต่ต้องแลกมาด้วยจำนวนคำขอ (request) ต่อ API ของพื้นที่จัดเก็บที่เพิ่มขึ้น
• การเข้ารหัส (Encryption): เป็นตัวเลือกเสริมแบบ AES-256 ซึ่งครอบคลุมทั้งเนื้อหาไฟล์และชื่อไฟล์ Cloudron จะไม่เก็บสำเนาของรหัสผ่านไว้ ดังนั้นหากทำรหัสผ่านหาย ข้อมูลสำรองจะไม่สามารถถอดรหัสได้โดยใครทั้งสิ้นรวมถึงตัวคุณเอง ควรจัดเก็บรหัสผ่านไว้ใน โปรแกรมจัดการรหัสผ่านที่คุณโฮสต์เอง ก่อนที่จะกดบันทึก
• การเก็บรักษา (Retention): กำหนดเป็นจำนวนครั้ง เช่น รายวัน 7 วัน และรายสัปดาห์ 4 สัปดาห์ การเก็บข้อมูลไว้นานบน Object Storage จะมีค่าใช้จ่ายเรียกเก็บทุกเดือน ดังนั้นควรเลือกจำนวนที่คุณยินดีจะจ่ายในระยะยาว

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

ข้อจำกัดของแผนการใช้งานฟรี

ณ เดือนสิงหาคม 2026 แผนการใช้งานฟรีจำกัดจำนวนแอปที่ติดตั้งได้ไว้ที่ 2 แอป โดยฟีเจอร์อื่นทั้งหมดจะรวมอยู่ด้วย ได้แก่ การอัปเดตแอป, การสำรองข้อมูลแยกรายแอป, ไฟร์วอลล์, เมลเซิร์ฟเวอร์ และระบบ single sign-on หากต้องการติดตั้งแอปที่ 3 จำเป็นต้องมีไลเซนส์ แผนการใช้งานแบบชำระเงินจะปลดล็อกขีดจำกัดจำนวนแอป และแผนระดับสูงกว่าจะเพิ่มฟีเจอร์กลุ่มผู้ใช้และบทบาท, directory server และการสำรองข้อมูลไปยังหลายตำแหน่ง เนื่องจากราคาอาจมีการเปลี่ยนแปลง โปรดตรวจสอบที่ หน้าแสดงราคาของ Cloudron แทนการอ้างอิงตัวเลขจากบทเรียนนี้

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

เมื่อเกิดปัญหาขึ้น

ให้เริ่มต้นด้วยการตรวจสอบที่มาพร้อมกับระบบ ซึ่งจะดำเนินการตรวจสอบ DNS, ใบรับรอง (certificates), ดิสก์, หน่วยความจำ และบริการแต่ละรายการตามลำดับ พร้อมทั้งแจ้งให้ทราบว่าการทดสอบใดที่ไม่ผ่าน:

sudo cloudron-support --troubleshoot

หลังจากนั้น ให้ใช้เครื่องมือมาตรฐานของ systemd (ตัวจัดการระบบและบริการ) systemctl status box ใช้สำหรับรายงานสถานะของบริการ Cloudron โดยเฉพาะ journalctl -u box -n 100 ใช้สำหรับดู log ล่าสุด และ journalctl -u docker ใช้สำหรับตรวจสอบ container runtime ที่ทำงานอยู่เบื้องหลัง ส่วนข้อผิดพลาดใดๆ ที่เกิดขึ้นระหว่างการติดตั้งจะถูกบันทึกไว้ใน /var/log/cloudron-setup.log

หากหน้า dashboard ไม่โหลด ปัญหามักเกิดจาก DNS หรือ firewall ของผู้ให้บริการมากกว่าตัว Cloudron เอง ให้รันคำสั่ง dig +short my.example.com จากแล็ปท็อปของคุณ และยืนยันว่าพอร์ต 80 และ 443 เปิดใช้งานอยู่บน network firewall ของผู้ให้บริการ ซึ่งเป็นส่วนควบคุมที่แยกต่างหากจากกฎของตัวเซิร์ฟเวอร์เอง หากคุณต้องการเริ่มต้นใหม่ สคริปต์จะปฏิเสธการรันซ้ำด้วย Error: Cloudron is already installed. To reinstall, start afresh ดังนั้นการติดตั้งเซิร์ฟเวอร์ใหม่ตั้งแต่ต้นจึงเป็นวิธีที่สะอาดที่สุดในการแก้ไขปัญหา

เมื่อ Cloudron ไม่ใช่คำตอบที่เหมาะสม

Cloudron เหมาะสมเมื่อคุณต้องการใช้งานแอปพลิเคชันโดยไม่ต้องการจัดการโครงสร้างพื้นฐาน แต่จะไม่เหมาะสมหากคุณต้องการรันคอนเทนเนอร์ด้วยวิธีของคุณเอง เนื่องจาก Cloudron จะเป็นผู้ควบคุม nginx, Docker และ firewall ซึ่งจะเขียนทับการตั้งค่าที่คุณกำหนดไว้ หากแผนของคุณคือการใช้โฟลเดอร์ที่เก็บไฟล์ compose ไว้ การใช้ Traefik หน้า Docker Compose stacks ของคุณเอง จะให้ผลลัพธ์เป็น TLS อัตโนมัติและการทำ routing ตาม subdomain เหมือนกันโดยไม่ต้องมีแพลตฟอร์มมาครอบ หากคุณยังไม่ได้ตัดสินใจ การเปรียบเทียบ Cloudron, CasaOS และ Coolify จะช่วยให้เห็นภาพรวมของแต่ละตัว และ รายการซอฟต์แวร์สำหรับ self-host ที่ครอบคลุมกว่า เป็นจุดเริ่มต้นที่ดีกว่าการอ่านคู่มือการติดตั้งเพียงอย่างเดียว

FAQ

Cloudron ต้องการ RAM เท่าไรบน VPS?

สคริปต์ติดตั้งจะปฏิเสธการทำงานหากมี RAM ต่ำกว่า 941 MB และเอกสารระบุว่าต้องการ 2 GB ซึ่งนั่นเป็นเพียงค่าเริ่มต้นสำหรับตัวแพลตฟอร์มที่ยังไม่มีแอปใดๆ ติดตั้งอยู่ Cloudron จะรัน Docker, nginx, บริการ box ของตัวเอง, คอนเทนเนอร์ฐานข้อมูล และ stack สำหรับอีเมลตั้งแต่เริ่มบูตเครื่อง ควรจัดสรร RAM ไว้ 4 GB สำหรับการรันสองแอป และ 16 GB สำหรับการรันประมาณสิบแอป และควรเพิ่ม swap file เข้าไปด้วย เนื่องจาก Cloudron อนุญาตให้แอปใช้ swap ได้ไม่จำกัด หากเซิร์ฟเวอร์ไม่มี swap จะทำให้เกิดภาวะหน่วยความจำเต็มจนบริการถูกรีสตาร์ท

ฉันสามารถติดตั้ง Cloudron บน Debian หรือบนเซิร์ฟเวอร์ที่มี Docker อยู่แล้วได้หรือไม่?

ไม่ได้ทั้งสองกรณี สคริปต์จะตรวจสอบเวอร์ชันของระบบปฏิบัติการและหยุดทำงานพร้อมแสดง Cloudron requires Ubuntu 20.04, 22.04, 24.04 ดังนั้น Debian, Rocky และ Alpine จึงไม่สามารถใช้ได้ นอกจากนี้สคริปต์จะหยุดทำงานหากพบ nginx, docker หรือ node อยู่ก่อนแล้ว เนื่องจากระบบจะติดตั้งซอฟต์แวร์เหล่านี้ในเวอร์ชันที่กำหนดไว้โดยเฉพาะ และจะเขียนค่าคอนฟิกของ nginx รวมถึงกฎของ iptables ด้วยตัวเอง ให้เริ่มต้นจากอิมเมจ Ubuntu ที่สะอาดบน KVM VPS เท่านั้น

ทำไม subdomain ของแอปถึงใช้งานไม่ได้ในขณะที่ dashboard ใช้งานได้ปกติ?

เกิดจากการขาด wildcard DNS record กระบวนการติดตั้งจะสร้างหรือต้องการ A record สำหรับ my.example.com เพื่อให้ dashboard เข้าถึงได้ ในขณะที่ wiki.example.com จะคืนค่าเป็น NXDOMAIN และเบราว์เซอร์จะแจ้งว่าไม่พบเว็บไซต์ ให้เพิ่ม A record สำหรับ *.example.com โดยชี้ไปยัง IP ของเซิร์ฟเวอร์ จากนั้นตรวจสอบความถูกต้องด้วย dig +short wiki.example.com ก่อนที่คุณจะติดตั้งแอป

ฉันจำเป็นต้องใช้ mail server ของ Cloudron หรือไม่?

ไม่จำเป็น คุณสามารถปิดการรับอีเมลขาเข้าและส่งผ่าน relay ภายนอก เช่น Postmark, Mailgun หรือ Amazon SES ซึ่งเป็นทางเลือกที่ปลอดภัยกว่าในกรณีที่ผู้ให้บริการของคุณบล็อกพอร์ตขาออก 25 หรือ IP address ของคุณไม่มีชื่อเสียงด้านการส่งอีเมล หากคุณไม่ใช้ Cloudron Email เลย ให้ปิดพอร์ต 25, 465, 587, 993 และ 4190 ที่ firewall ของผู้ให้บริการแทนการปิดที่ตัวเซิร์ฟเวอร์

จะเกิดอะไรขึ้นเมื่อฉันใช้งานครบขีดจำกัดสองแอปในแผนฟรี?

Dashboard จะบล็อกการติดตั้งแอปที่สามและขอให้ใส่ licence key แอปที่คุณรันอยู่ก่อนแล้วจะไม่ได้รับผลกระทบใดๆ โดยแอปจะยังคงอัปเดตต่อไป มีการสำรองข้อมูลตามปกติ และยังคงใช้งาน certificate ได้ตามเดิม การเพิ่ม licence จะช่วยปลดล็อกขีดจำกัดโดยไม่ต้องติดตั้งอะไรใหม่ ดังนั้นแผนฟรีจึงเป็นวิธีที่เหมาะสมในการทดสอบแพลตฟอร์มบนโดเมนจริงก่อนตัดสินใจใช้งาน