คู่มือ Self-host Uptime Kuma บน DigitalOcean 2026

A practical, command-by-command guide to self-hosting Uptime Kuma on a DigitalOcean Droplet with Docker, from first deployment through alerting and public status pages.

Uptime Kuma เป็นเครื่องมือ monitoring แบบโอเพนซอร์สที่นิยม self-host กันเองแทนบริการ SaaS อย่าง UptimeRobot เพราะควบคุมข้อมูลได้เต็มที่และไม่จำกัดจำนวน monitor ตามใจ บทความนี้พาไล่ตั้งแต่เลือกขนาด Droplet ที่เหมาะสม ติดตั้งด้วย Docker ตั้งค่า monitor แรก ไปจนถึงต่อระบบแจ้งเตือนและทำหน้า Status Page ที่ใช้งานจริงได้

Uptime Kuma คืออะไร ต่างจาก Monitoring ในตัว DO ยังไง

Uptime Kuma คือซอฟต์แวร์ monitoring แบบ self-hosted เขียนด้วย Node.js และ Vue.js เปิดซอร์สให้ใครก็ตั้งรันเองบนเซิร์ฟเวอร์ของตัวเองได้ฟรี หน้าที่หลักคือคอยยิงเช็คสถานะเว็บไซต์ API หรือบริการต่างๆ ตามช่วงเวลาที่กำหนด แล้วแจ้งเตือนเมื่อเจอปัญหา จุดเด่นคือรองรับ monitor หลายประเภทในตัวเดียว ทั้ง HTTP(s), TCP Port, Ping, DNS Record, Docker Container, gRPC, Push (สำหรับ cron job แบบ dead man's switch) และ Keyword/JSON Query สำหรับเช็คเนื้อหาในหน้าเว็บหรือ response ของ API ว่าตรงตามที่คาดไว้หรือไม่ เนื่องจากรันบนเซิร์ฟเวอร์ของเราเองจึงไม่มีข้อจำกัดเรื่องจำนวน monitor นอกจากทรัพยากรของ Droplet ที่ใช้ ในทางกลับกัน DigitalOcean เองก็มีฟีเจอร์ Monitoring ในตัวให้ใช้ฟรีอยู่แล้ว ครอบคลุมการเก็บ metrics ของ Droplet เช่น CPU, memory, disk และดิสก์ I/O พร้อมตั้ง alert policy ได้ และมี Uptime Check ให้ฟรี 1 รายการต่อบัญชี สำหรับเช็คว่าปลายทาง (เช่นเว็บไซต์หลัก) ยังตอบสนองอยู่หรือไม่ ข้อดีคือไม่ต้องติดตั้งอะไรเพิ่ม ไม่ต้องดูแลเซิร์ฟเวอร์เอง แต่ข้อจำกัดคือมีให้ใช้แค่ 1 check ฟรี หากต้องเฝ้าดูหลายปลายทางพร้อมกัน หรือต้องการ Status Page ของตัวเอง หรือช่องทางแจ้งเตือนที่หลากหลายกว่านั้น การ self-host Uptime Kuma จึงตอบโจทย์มากกว่า แลกกับภาระในการดูแลอัปเดตและความปลอดภัยของ Droplet ที่ใช้รันเอง โดยสรุปคือทั้งสองฝั่งไม่ได้แข่งกันโดยตรง แต่เสริมกันได้ดี เช่น ใช้ DO Uptime Check ฟรีเฝ้าดู Uptime Kuma อีกทีหนึ่ง เพื่อไม่ให้เกิดปัญหา "ใครจะเฝ้าดูคนเฝ้าดู" เมื่อ Droplet ที่รัน Kuma ล่มไปพร้อมกับบริการที่มันเฝ้าดูอยู่

Uptime Kuma is a self-hosted monitoring software written in Node.js and Vue.js, open-source for anyone to run on their own servers for free. Its main job is to continuously check the status of websites, APIs, or other services at set intervals and alert when problems occur. The standout feature is supporting many monitor types in one application: HTTP(s), TCP Port, Ping, DNS Record, Docker Container, gRPC, Push (for cron jobs with dead man's switch), and Keyword/JSON Query to check if specific content appears in a web page or API response exactly as expected. Since it runs on your own server, there's no limit on the number of monitors aside from your Droplet's resources. Meanwhile, DigitalOcean itself offers built-in Monitoring features for free, covering metrics collection for your Droplet like CPU, memory, disk, and disk I/O, with alert policies included. It also gives 1 free Uptime Check per account to verify that an endpoint (like your main website) is still responding. The advantage is no extra setup or server management needed, but the limitation is only 1 free check. If you need to monitor multiple endpoints simultaneously, want your own branded status page, or need more diverse alerting channels, self-hosting Uptime Kuma is more suitable, though it comes with the burden of maintaining and securing your own Droplet. In short, they don't directly compete but complement each other well. For example, you can use DO's free Uptime Check to monitor the Uptime Kuma instance itself, preventing the "who watches the watcher" problem when the Droplet crashes along with the services it's monitoring.

• Uptime Kuma: self-host เอง ไม่จำกัดจำนวน monitor ตามทรัพยากร Droplet ที่มี
• DO Monitoring: ฟรีในตัว ไม่ต้องติดตั้งอะไรเพิ่ม แต่ให้ Uptime Check ฟรีแค่ 1 รายการต่อบัญชี
• Uptime Kuma รองรับ monitor หลายแบบ: HTTP(s), TCP, Ping, DNS, Docker, gRPC, Push, Keyword/JSON Query
• ใช้ร่วมกันได้: เอา DO Uptime Check ฟรีมาเฝ้าดู Droplet ที่รัน Uptime Kuma อีกชั้น กัน single point of failure

Deploy ด้วย Docker

ขั้นแรกต้องมี Droplet สักตัวไว้รัน Uptime Kuma สำหรับ workload ระดับเริ่มต้นที่มี monitor ไม่กี่สิบตัว แพ็กเกจ Basic Shared CPU ขนาด 1 GiB RAM / 1 vCPU / 25 GB SSD / โอนข้อมูล 1,000 GiB ที่ราคา $6/เดือน เพียงพอสบายๆ เพราะ Uptime Kuma กิน RAM ไม่มากและใช้ SQLite เป็นฐานข้อมูลในตัว ถ้าต้องการประหยัดกว่านั้นแพ็กเกจ 512 MiB ที่ $4/เดือน ก็พอรันได้ แต่จะตึงมือเมื่อเปิดหลาย monitor พร้อมกัน สำหรับผู้ใช้ในไทยแนะนำเลือก region sgp1 (Singapore) เพราะ latency ต่ำที่สุด รองลงมาคือ blr1 (Bangalore) หลังสร้าง Droplet เสร็จ ให้ SSH เข้าไปติดตั้ง Docker (จะเลือกใช้ Marketplace image "Docker on Ubuntu" ตอนสร้าง Droplet หรือติดตั้งเองด้วย apt ภายหลังก็ได้) จากนั้นรันคำสั่งเดียวเพื่อสตาร์ท Uptime Kuma: docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1 คำสั่งนี้สร้าง container ชื่อ uptime-kuma เปิดพอร์ต 3001 และที่สำคัญคือแนบ named volume uptime-kuma:/app/data เก็บฐานข้อมูล SQLite ไว้แยกจากตัว container เพื่อไม่ให้ข้อมูลหายเมื่อลบ container ทิ้งแล้วสร้างใหม่ ถ้าอยากจัดการง่ายขึ้นด้วย docker compose ให้สร้างไฟล์ docker-compose.yml แล้วใส่ service เดียวกันนี้ จากนั้นรันด้วย docker compose up -d เมื่อ container รันแล้วให้ตั้งค่า Cloud Firewall ของ DO (ใช้งานฟรี ไม่มีค่าใช้จ่ายเพิ่ม) ให้เปิดเฉพาะพอร์ต 22 (SSH), 80/443 (สำหรับ reverse proxy) และปิดพอร์ต 3001 จากอินเทอร์เน็ตภายนอกโดยตรง แล้วตั้ง Nginx เป็น reverse proxy ยิงเข้า 127.0.0.1:3001 พร้อมใช้ Certbot ออก SSL certificate ฟรีให้โดเมนที่ชี้มาที่ Droplet เพื่อให้เข้าถึงหน้า dashboard ผ่าน HTTPS เท่านั้น ไม่ส่งรหัสผ่านแบบ plain text ผ่านพอร์ต 3001 ตรงๆ

• แนะนำ Droplet $6/เดือน (1 GiB RAM, 1 vCPU, 25 GB SSD, โอนข้อมูล 1,000 GiB) สำหรับใช้งานทั่วไป
• region sgp1 (Singapore) latency ต่ำสุดสำหรับผู้ใช้ไทย รองลงมา blr1 (Bangalore)
• คำสั่งหลัก: docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1

ตั้งค่า Monitor เว็บไซต์/API

เข้าหน้า dashboard ครั้งแรกผ่านโดเมนที่ตั้งไว้ ระบบจะให้สร้างบัญชี admin ก่อน (ตั้งรหัสผ่านที่แข็งแรงเพราะหน้านี้ควบคุมการแจ้งเตือนทั้งหมด) จากนั้นกด "Add New Monitor" เพื่อเริ่มเพิ่มรายการที่ต้องการเฝ้าดู ตัวเลือกประเภท Monitor ที่ใช้บ่อยที่สุดคือ HTTP(s) สำหรับเช็คว่าเว็บไซต์หรือ API endpoint ตอบกลับด้วยสถานะที่ถูกต้องหรือไม่ ใส่ URL ปลายทาง กำหนด Heartbeat Interval (ความถี่ในการเช็ค เช่นทุก 60 วินาที) Retries (จำนวนครั้งที่ยอมให้ล้มเหลวก่อนถือว่า down จริง เพื่อกันการแจ้งเตือนเท็จจาก network blip ชั่วครู่) และ Resend Notification ทุกกี่ครั้งเมื่อยัง down ต่อเนื่อง สำหรับ API ที่ต้องเช็คเนื้อหาลึกกว่าการดูแค่ status code ใช้ประเภท Keyword เพื่อค้นหาข้อความเฉพาะใน response หรือใช้ JSON Query (มีในเวอร์ชันใหม่) เพื่อตรวจสอบค่าฟิลด์ใน JSON response เช่นเช็คว่าฟิลด์ status มีค่าเท่ากับ ok จริงหรือไม่ ไม่ใช่แค่ HTTP 200 เฉยๆ สำหรับ TCP Port ใช้เช็คว่าพอร์ตของฐานข้อมูลหรือบริการ backend เปิดรับ connection อยู่หรือไม่ ส่วน Docker Container monitor ใช้เฝ้าดูสถานะ container อื่นบนเครื่องเดียวกันได้โดยตรงผ่าน Docker socket ถ้ามีหลาย monitor ควรจัดกลุ่มด้วยฟีเจอร์ Group หรือใส่ Tag เพื่อให้จัดการง่ายเมื่อจำนวนเพิ่มขึ้น เช่นแยกกลุ่ม Production กับ Staging หรือแยกตามทีมที่รับผิดชอบ นอกจากนี้ยังตั้ง Upside Down Mode ได้สำหรับกรณีที่อยากให้แจ้งเตือนเมื่อ "บริการทำงาน" แทนที่จะเป็น "บริการล่ม" เช่นเฝ้าดู maintenance mode ว่ายังเปิดอยู่นานเกินไปหรือไม่

• Monitor Type หลัก: HTTP(s), TCP Port, Ping, DNS, Docker Container, Keyword, JSON Query, Push
• ตั้ง Heartbeat Interval และ Retries ให้เหมาะสมเพื่อลด false alert จาก network blip ชั่วคราว
• ใช้ Keyword/JSON Query เช็คเนื้อหา response จริง ไม่ใช่แค่ดู HTTP status code

แจ้งเตือนผ่าน Telegram/Email/Line Notify

ไปที่เมนู Settings > Notifications เพื่อตั้งช่องทางแจ้งเตือน ซึ่งจะผูกกับ monitor แต่ละตัวได้อิสระ สำหรับ Telegram ให้สร้างบอทใหม่ผ่าน BotFather ในแอป Telegram พิมพ์คำสั่ง /newbot ตั้งชื่อบอท จะได้ Bot Token กลับมา จากนั้นหา Chat ID ของกลุ่มหรือบัญชีที่ต้องการรับแจ้งเตือน (เปิดผ่าน API ของ Telegram หรือบอทช่วยอย่าง @userinfobot) แล้วนำ Bot Token และ Chat ID มาใส่ในหน้า Add Notification เลือกประเภท Telegram กดปุ่ม Test เพื่อยืนยันว่าข้อความส่งถึงจริงก่อนบันทึกใช้งาน สำหรับ Email ใช้ประเภท SMTP ใส่ค่า host, port, username, password ของผู้ให้บริการอีเมลที่มีอยู่ (เช่น Gmail App Password หรือ SMTP relay ของผู้ให้บริการโดเมน) พร้อมกำหนดอีเมลต้นทางและปลายทาง เหมาะสำหรับแจ้งเตือนแบบไม่เร่งด่วนหรือสรุปรายงาน ส่วน LINE Notify ที่หลายคนคุ้นเคยนั้น ต้องระบุให้ชัดว่า LINE ได้ประกาศปิดให้บริการ LINE Notify ไปแล้วตั้งแต่วันที่ 31 มีนาคม 2025 ทำให้ตัวเลือกนี้ใช้งานไม่ได้อีกต่อไปในปี 2026 ทางเลือกทดแทนคือใช้ LINE Messaging API ผ่าน LINE Official Account ของตัวเอง โดยตั้ง Webhook รับข้อความแล้วให้ Uptime Kuma ยิงแจ้งเตือนผ่านประเภท Webhook หรือใช้ Apprise (ตัวกลางที่ Uptime Kuma รองรับในตัว) ซึ่งสามารถเชื่อมต่อบริการแจ้งเตือนได้หลายสิบชนิดรวมถึงเขียน custom integration เข้ากับ LINE Messaging API ได้เช่นกัน ควรตั้งอย่างน้อยสองช่องทางคู่กันเสมอ เช่น Telegram เป็นหลักและ Email เป็นสำรอง เพื่อไม่ให้พลาดการแจ้งเตือนหากช่องทางใดช่องทางหนึ่งมีปัญหา

1. Telegram: สร้างบอทผ่าน BotFather ได้ Bot Token ใส่คู่กับ Chat ID แล้วกด Test ก่อนใช้จริง
2. Email: ใช้ประเภท SMTP ใส่ host/port/username/password ของผู้ให้บริการอีเมลที่มีอยู่
3. LINE Notify ปิดให้บริการแล้วตั้งแต่ 31 มีนาคม 2025 ใช้งานไม่ได้อีกต่อไป
4. ทางเลือกแทน LINE Notify: LINE Messaging API ผ่าน Webhook หรือใช้ Apprise ที่ Kuma รองรับในตัว
5. ควรตั้งอย่างน้อย 2 ช่องทางคู่กันเพื่อกันพลาดกรณีช่องทางหนึ่งมีปัญหา

สร้างหน้า Status Page สาธารณะ

Uptime Kuma มีฟีเจอร์ Status Page ในตัว ใช้สร้างหน้าเว็บสาธารณะแสดงสถานะบริการให้ลูกค้าหรือผู้ใช้ดูได้เอง โดยไม่ต้องแยกไปใช้บริการอื่น ไปที่เมนู Status Pages แล้วกด "New Status Page" ตั้งชื่อ ตั้ง slug สำหรับ URL (เช่น /status/production) จากนั้นลาก monitor ที่ต้องการโชว์เข้ามาจัดกลุ่มได้ตามหมวดหมู่ เช่นแยก "Website", "API", "Database" หน้า Status Page จะแสดงสถานะปัจจุบัน uptime percentage ย้อนหลัง และ heartbeat history เป็นแท่งกราฟให้เห็นภาพรวมได้ทันที ปรับแต่งหน้าตาได้ทั้ง theme, โลโก้, คำอธิบาย และเปิด/ปิดการแสดงตัวเลข response time ได้ตามต้องการ ถ้าต้องการ incident history ก็เพิ่มประกาศเหตุการณ์ (Incident) พร้อมข้อความอัปเดตความคืบหน้าได้จากหน้าเดียวกัน เพื่อความน่าเชื่อถือ แนะนำให้ใช้โดเมนย่อยของตัวเองแทนการเปิดผ่าน path เดิม เช่น status.example.com โดยตั้ง DNS record แบบ A หรือ CNAME ชี้มาที่ IP ของ Droplet แล้วเพิ่ม server block ใหม่ใน Nginx เฉพาะโดเมนนี้ ให้ proxy ไปที่ path ของ Status Page พร้อมออก SSL certificate แยกต่างหากด้วย Certbot เช่นกัน หน้า Status Page ที่แยกโดเมนแบบนี้ยังมีข้อดีตรงที่เข้าถึงได้แม้ตัว dashboard หลักจะถูกปิดกั้นด้วย Cloud Firewall เฉพาะ IP ของทีมแล้วก็ตาม เพราะสามารถตั้งให้เฉพาะ path Status Page เปิดสาธารณะ ส่วน path จัดการ dashboard ปิดจำกัดเฉพาะ IP ที่กำหนดไว้ผ่าน Nginx configuration

• สร้างผ่าน Status Pages > New Status Page ตั้ง slug และลาก monitor เข้ามาจัดกลุ่มได้
• แสดง uptime percentage ย้อนหลัง heartbeat history และปรับ theme/โลโก้ได้
• เพิ่ม Incident เพื่อประกาศเหตุการณ์และอัปเดตความคืบหน้าให้ผู้ใช้ทราบ

เมื่อไหร่ควรใช้ฟีเจอร์นี้ (Use Case จริง)

Uptime Kuma เหมาะกับสถานการณ์ที่ Uptime Check ฟรี 1 รายการของ DO ไม่พอใช้แล้ว เช่นทีมที่ดูแลหลายบริการพร้อมกัน ทั้งเว็บไซต์หลัก, API, ฐานข้อมูล, worker queue หรือ microservice ย่อยหลายตัว ที่ต้องการเฝ้าดูสถานะแยกกันแต่ละจุดพร้อมรู้ทันทีว่าจุดไหนล่ม ไม่ใช่แค่รู้ว่า "เว็บล่ม" แบบภาพรวมเดียว อีกกรณีคือทีมที่ให้บริการลูกค้าและต้องการหน้า Status Page แบรนด์ของตัวเองเพื่อความโปร่งใส แทนที่จะให้ลูกค้าทักมาถามตรงเวลาระบบมีปัญหา การมีหน้า status page สาธารณะช่วยลดภาระฝ่ายซัพพอร์ตได้มาก และแสดงความเป็นมืออาชีพในการดูแลระบบ นอกจากนี้ยังเหมาะกับผู้ที่ต้องการช่องทางแจ้งเตือนที่หลากหลายกว่าที่ DO Monitoring รองรับ เช่นอยากได้แจ้งเตือนเข้า Telegram กลุ่มทีม, Discord, Slack, หรือ Webhook เข้าระบบ internal ของตัวเอง ซึ่ง DO Monitoring ไม่ได้ออกแบบมาให้ยืดหยุ่นขนาดนั้น ด้านต้นทุนก็คุ้มค่าเมื่อเทียบกับบริการ SaaS monitoring เชิงพาณิชย์ที่คิดราคาตามจำนวน monitor เพราะ Droplet เดียวราคา $6/เดือน รองรับ monitor ได้หลักสิบถึงหลักร้อยรายการโดยต้นทุนคงที่ ในทางกลับกัน ถ้าธุรกิจมีแค่เว็บไซต์เดียวหรือ endpoint เดียวที่ต้องเฝ้าดู และไม่ต้องการภาระดูแลเซิร์ฟเวอร์เพิ่ม การใช้ DO Monitoring กับ Uptime Check ฟรีที่มีอยู่แล้วก็เพียงพอ ไม่จำเป็นต้องเสียค่า Droplet เพิ่มและดูแลอัปเดต security patch ของ Uptime Kuma เอง ควรชั่งน้ำหนักระหว่างความยืดหยุ่นที่ได้กับภาระดูแลที่เพิ่มขึ้นก่อนตัดสินใจ

• มีหลายบริการ/endpoint ที่ต้องเฝ้าดูแยกกัน เกินกว่า Uptime Check ฟรี 1 รายการของ DO
• ต้องการหน้า Status Page แบรนด์ตัวเองให้ลูกค้าดูได้ ลดภาระฝ่ายซัพพอร์ต
• ต้องการช่องทางแจ้งเตือนหลากหลาย เช่น Telegram, Discord, Slack, Webhook
• ต้นทุนคงที่ที่ $6/เดือน คุ้มกว่า SaaS monitoring ที่คิดราคาตามจำนวน monitor เมื่อมีจำนวนมาก
• ถ้ามีแค่ 1 endpoint และไม่อยากดูแลเซิร์ฟเวอร์เพิ่ม ใช้ DO Monitoring ฟรีที่มีอยู่แล้วก็พอ

ข้อผิดพลาดที่พบบ่อยและวิธีแก้ไข

จุดที่ผู้ใช้มักถามมาคือ ข้อผิดพลาดที่พบบ่อยที่สุดคือเปิดพอร์ต 3001 ให้เข้าถึงได้จากอินเทอร์เน็ตโดยตรงโดยไม่ผ่าน reverse proxy และ SSL ทำให้รหัสผ่านตอน login ส่งเป็น plain text ผ่านเครือข่าย แก้ไขโดยปิดพอร์ต 3001 ที่ Cloud Firewall แล้วเข้าผ่านโดเมนที่มี HTTPS ผ่าน Nginx เท่านั้นตามที่อธิบายไว้ในขั้นตอน deploy อีกปัญหาที่เจอบ่อยคือลืมแนบ volume ตอนรัน container ทำให้เมื่อมีการอัปเดตหรือลบ container เพื่อสร้างใหม่ ข้อมูล monitor และ notification ทั้งหมดหายไปหมด วิธีป้องกันคือต้องมี -v uptime-kuma:/app/data ทุกครั้งที่รันคำสั่ง docker run และควรสำรองข้อมูลโฟลเดอร์นี้เป็นระยะด้วย เช่นใช้ docker run --rm -v uptime-kuma:/app/data -v $(pwd):/backup busybox tar czf /backup/kuma-backup.tar.gz /app/data ปัญหาต่อมาคือการตั้งค่า Heartbeat Interval ถี่เกินไปโดยไม่จำเป็น เช่นทุก 10 วินาที สำหรับเว็บไซต์ที่ปกติเสถียรอยู่แล้ว ทำให้เปลืองทรัพยากร Droplet และเพิ่มโหลดให้ปลายทางโดยไม่จำเป็น ควรตั้งตามความสำคัญของบริการ เช่น API สำคัญมากอาจ 30-60 วินาที ส่วนบริการรองอาจ 5 นาทีก็เพียงพอ อีกจุดที่มักถูกมองข้ามคือไม่มีใครเฝ้าดู Uptime Kuma เอง เพราะมันรันอยู่บน Droplet เดียวกับที่อาจล่มไปพร้อมกับบริการที่กำลังเฝ้าดูอยู่ ทำให้เมื่อ Droplet ล่มจริงๆ จะไม่มีการแจ้งเตือนออกมาเลย แก้ไขได้ด้วยการใช้ DO Uptime Check ฟรีที่มีอยู่แล้วมาเฝ้าดู URL ของ Uptime Kuma เองอีกชั้นหนึ่ง สุดท้ายคือการปล่อยให้ image tag ค้างที่ :1 โดยไม่เคยอัปเดตเลยเป็นเวลานาน ทำให้พลาด security patch สำคัญ ควรตั้งรอบตรวจสอบและอัปเดตด้วย docker compose pull && docker compose up -d อย่างสม่ำเสมอ

1. เปิดพอร์ต 3001 ตรงจากอินเทอร์เน็ต ไม่มี SSL: ปิดที่ Cloud Firewall แล้วใช้ reverse proxy + HTTPS แทน
2. ลืมแนบ volume ตอนรัน container: ข้อมูลหายเมื่อสร้าง container ใหม่ ต้องมี -v uptime-kuma:/app/data เสมอ
3. ตั้ง Heartbeat Interval ถี่เกินจำเป็น: เปลืองทรัพยากรและเพิ่มโหลดปลายทางโดยไม่จำเป็น
4. ไม่มีใครเฝ้าดู Uptime Kuma เอง: ใช้ DO Uptime Check ฟรีเฝ้าดูซ้อนอีกชั้น
5. ปล่อย image tag ค้างไม่อัปเดต: พลาด security patch ควร pull image ใหม่เป็นระยะ

แนวทางปฏิบัติที่ดีที่สุด (Best Practices)

เริ่มจากความปลอดภัยของ dashboard เอง ควรเปิดใช้ Two-Factor Authentication (2FA) ในเมนู Settings > Security ทันทีหลังสร้างบัญชี admin เพราะหน้านี้ควบคุมการแจ้งเตือนและข้อมูล monitor ทั้งหมด ควบคู่กับการจำกัดการเข้าถึง dashboard เฉพาะ IP ของทีมผ่าน Nginx allow/deny หรือ Cloud Firewall ของ DO ที่ใช้งานฟรีอยู่แล้ว ด้านการสำรองข้อมูล ควรตั้ง cron job สำรองโฟลเดอร์ /app/data เป็นประจำ อาจส่งไฟล์ backup ไปเก็บนอก Droplet เพื่อกันกรณี Droplet มีปัญหาทั้งเครื่อง หรือใช้ Droplet Snapshot ของ DO เก็บสถานะทั้งเครื่องเป็นระยะเพิ่มอีกชั้นความปลอดภัย ด้านเวอร์ชัน แนะนำ pin image tag ให้ชัดเจน เช่น louislam/uptime-kuma:1.23.16 แทนการใช้ :1 เฉยๆ เพื่อให้ควบคุมได้ว่าจะอัปเดตเมื่อไหร่ ทดสอบบน Droplet สำรองก่อนแล้วค่อยอัปเดตของจริง ป้องกันปัญหา breaking change หลุดเข้ามาโดยไม่รู้ตัว ด้านการจัดระเบียบ monitor ควรตั้งชื่อและ Tag ให้สื่อความหมายชัดเจนตั้งแต่ต้น เพราะเมื่อจำนวน monitor เพิ่มขึ้นหลักสิบหลักร้อยตัว การจัดกลุ่มที่ดีจะช่วยลดเวลาค้นหาเวลาเกิดเหตุฉุกเฉินได้มาก สำหรับงาน cron job หรือ background job ภายในระบบ แนะนำใช้ Monitor ประเภท Push แทน HTTP ปกติ เพราะเป็นแบบ dead man's switch ที่ตัวงานเองต้องยิง heartbeat เข้ามาบอกว่า "ยังทำงานอยู่นะ" หากขาดหายไปถือว่ามีปัญหาทันที เหมาะกับ job ที่ไม่มี endpoint ให้ยิงเช็คจากภายนอก สุดท้ายเมื่อจำนวน monitor และผู้ใช้เพิ่มขึ้นจนทรัพยากร Droplet เริ่มตึง ให้พิจารณาขยับขึ้นไปที่แพ็กเกจ $12/เดือน (2 GiB RAM, 1 vCPU, 50 GB SSD, โอนข้อมูล 2,000 GiB) ซึ่งรองรับโหลดได้มากขึ้นโดยยังอยู่ในระดับราคาที่จับต้องได้

1. เปิด 2FA ทันทีหลังสร้างบัญชี admin และจำกัด IP เข้าถึง dashboard ผ่าน Cloud Firewall (ฟรี)
2. สำรองโฟลเดอร์ /app/data เป็นประจำ และใช้ Droplet Snapshot เก็บสถานะทั้งเครื่องเพิ่มอีกชั้น
3. Pin image tag ให้ชัดเจน เช่น louislam/uptime-kuma:1.23.16 แทนการใช้ :1 เฉยๆ
4. ใช้ Monitor ประเภท Push สำหรับ cron/background job แบบ dead man's switch
5. เมื่อ monitor เยอะขึ้นจนทรัพยากรตึง ให้อัปเกรดเป็น Droplet $12/เดือน (2 GiB RAM, 1 vCPU, 50 GB SSD)

รับ $200 Free Credit →