ติดตั้ง Uptime Kuma บน VPS: Docker Compose, Caddy, การแจ้งเตือน

Uptime Kuma คือเครื่องมือมอนิเตอร์แบบโอเพนซอร์สที่โฮสต์เองได้ รองรับการตรวจสอบ HTTP(S), TCP, ping, DNS, WebSocket และอื่น ๆ เมื่อรันบน VPS แยกต่างหาก มันจะยังตรวจสอบต่อไปเมื่อเซิร์ฟเวอร์โปรดักชันของคุณล่ม แทนที่จะดับไปพร้อมกัน

การติดตั้ง Uptime Kuma บน VPS นี้จะดีพลอย v2 ด้วย Docker Compose, ผูกพอร์ต 3001 ไว้กับ loopback, เพิ่ม HTTPS ผ่าน Caddy, ส่งการแจ้งเตือนไปยัง Telegram, Discord และ Slack และเผยแพร่หน้าสถานะ

สิ่งที่ต้องเตรียมก่อนเริ่ม

VPS ที่มีอย่างน้อย 1 vCPU, RAM 1 GB และพื้นที่ SSD ในเครื่อง 10 GB
Ubuntu 24.04 LTS หรือ Ubuntu รุ่นปัจจุบันอื่นที่ Docker รองรับ
ติดตั้ง Docker Engine และ Docker Compose บน VPS แล้ว
โดเมนหรือซับโดเมนที่ชี้มายัง VPS ผ่านเรกคอร์ด A (เช่น status.example.com)
การเข้าถึงผ่าน SSH และความคุ้นเคยพื้นฐานกับคอมมานด์ไลน์

หากยังไม่ได้ติดตั้ง Docker ให้ทำตาม คู่มือติดตั้ง Docker บน Ubuntu ซึ่งจะติดตั้ง Docker Engine และปลั๊กอิน Compose ที่ใช้ด้านล่าง

ทำไม VPS ที่ใช้มอนิเตอร์ต้องแยกจากสิ่งที่มันเฝ้าดู

Production in Region A has failed and its website, API and database are down, while Uptime Kuma on a separate VPS in Region B stays online, keeps probing those services and routes alerts to Telegram, Discord and Slack. An external watchdog checks Uptime Kuma itself.

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

มีสองรูปแบบที่ใช้งานได้จริงและช่วยให้ดีขึ้น:

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

อินสแตนซ์ Uptime Kuma เดียวยังคงไม่มีตัวเฝ้าระวังจากภายนอก ให้เพิ่มการตรวจสอบ HTTP(S) จากภายนอกหนึ่งรายการไปยังหน้าสถานะสาธารณะของมัน แพ็กเกจฟรีของ UptimeRobot ปัจจุบันให้มอนิเตอร์ 50 รายการที่ช่วงตรวจสอบทุกห้านาที วิธีนี้ไม่ได้ทำให้ Uptime Kuma มีความพร้อมใช้งานสูง แต่จะบอกคุณได้เมื่อตัวมอนิเตอร์เองหายไป

กฎเดียวกันนี้ใช้กับหน้าสถานะสาธารณะด้วย สิ่งที่คอยบอกคุณว่ามีปัญหาต้องไม่อยู่ในโดเมนความล้มเหลวเดียวกับสิ่งที่ล้มเหลว

พัฒนาบน Linux VPS พร้อมสิทธิ์รูท, NVMe และพลัง AMD EPYC

ดูแพ็กเกจ Linux

การเลือกขนาด VPS

Uptime Kuma ไม่มีสูตรตายตัวที่เชื่อถือได้ระหว่างจำนวนมอนิเตอร์กับ RAM เพราะโหลดเปลี่ยนไปตามชนิดมอนิเตอร์ ช่วงเวลาตรวจสอบ การตั้งค่า retry และระยะเก็บประวัติ การตรวจสอบ HTTP(S), TCP, ping และ DNS แบบพื้นฐานเบากว่าการตรวจแบบ Browser Engine ที่ต้องรัน Chromium

หากมีการตรวจสอบพื้นฐานไม่กี่รายการ ให้เริ่มที่ 1 vCPU, RAM 1 GB และพื้นที่ SSD ในเครื่อง ดูการใช้งานจริงด้วย docker stats uptime-kuma และดูการเติบโตของฐานข้อมูลด้วย du -sh /opt/uptime-kuma/data เพิ่มหน่วยความจำเมื่อการใช้งานสูงต่อเนื่อง เมื่อคอนเทนเนอร์รายงาน OOM kill หรือเมื่อคุณเริ่มใช้การตรวจแบบ Browser Engine

อิมเมจ v2 แบบเต็มมี Chromium และ MariaDB ฝังมาด้วย โดย เอกสารเรื่องแท็ก Docker อธิบายความต่างระหว่างอิมเมจแบบ full กับ slim

ดีพลอย Uptime Kuma ด้วย Docker Compose

บันทึกไฟล์นี้เป็น docker-compose.yml ใน /opt/uptime-kuma/:

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      # Bind to localhost only. The reverse proxy will expose it on 443.
      - "127.0.0.1:3001:3001"
    volumes:
      - ./data:/app/data

มีสามบรรทัดที่ควรพูดถึง:

image: louislam/uptime-kuma:2 ตรึงเวอร์ชันหลักไว้ แท็ก :2 จะตามสายรีลีสเสถียร 2.x อย่าใช้ :latest
127.0.0.1:3001:3001 ผูกคอนเทนเนอร์ไว้กับ localhost เท่านั้น อินเทอร์เน็ตสาธารณะต้องไม่เข้าถึงพอร์ต 3001 โดยตรงเด็ดขาด รีเวิร์สพร็อกซีคือตัวที่ถือใบรับรอง TLS และชื่อโฮสต์สาธารณะ
โวลุ่มข้อมูลเก็บฐานข้อมูล การตั้งค่ามอนิเตอร์ และประวัติ ให้เก็บไว้บนสตอเรจในเครื่อง เพราะ เอกสารการติดตั้งของ Uptime Kuma เตือนว่าไฟล์ซิสเต็มที่ไม่มี POSIX locking ที่เชื่อถือได้ รวมถึงการตั้งค่า NFS จำนวนมาก อาจทำให้ SQLite เสียหายได้ ให้หยุดสแตกก่อนคัดลอกในระดับไฟล์ซิสเต็ม

สั่งรันแล้วตรวจสอบ:

sudo install -d -o "$USER" -g "$USER" /opt/uptime-kuma
cd /opt/uptime-kuma
# Paste the docker-compose.yml file above.
sudo docker compose up -d
sudo docker compose ps

ผลลัพธ์ที่คาดหวังจาก docker compose ps:

NAME          IMAGE                       STATUS                   PORTS
uptime-kuma   louislam/uptime-kuma:2      Up (healthy)             127.0.0.1:3001->3001/tcp

การเข้าแดชบอร์ดครั้งแรก อย่าเปิดพอร์ต 3001 สู่อินเทอร์เน็ตสาธารณะแม้เพียงชั่วครู่ ให้ทำ SSH tunnel แทน:

ssh -L 3001:127.0.0.1:3001 [email protected]

เปิด http://localhost:3001 ในเบราว์เซอร์ สร้างบัญชีผู้ดูแลระบบ ตั้งรหัสผ่านที่แข็งแรง แล้วปิดทันเนล จากนี้ไปแดชบอร์ดจะมาถึงคุณผ่าน HTTPS ทางรีเวิร์สพร็อกซี

หากคุณไม่จำเป็นต้องตั้งค่า Compose เอง เรายังมี Uptime Kuma ให้บริการเป็นแอปติดตั้งคลิกเดียว หน้าแอปปัจจุบันระบุเป็น v1 จึงไม่ตรงกับการติดตั้ง v2 ด้วย Compose ในคู่มือนี้ หากคุณต้องการ v2 โดยเฉพาะ ให้ใช้วิธี Compose แบบทำเอง

รีเวิร์สพร็อกซีและ TLS

Public traffic reaches Caddy on the host or an Nginx Proxy Manager container over HTTPS on port 443. Caddy forwards to Uptime Kuma on 127.0.0.1:3001 while the NPM container uses a shared Docker network instead. Public access to port 3001 is blocked, and first-time setup runs through an SSH tunnel to localhost:3001.

อย่าเปิด Uptime Kuma ออกสู่ภายนอกโดยตรง ให้วางรีเวิร์สพร็อกซีไว้ข้างหน้าเพื่อจัดการ TLS, จัดการ URL อย่างถูกต้อง และมีจุดเข้าสาธารณะเพียงจุดเดียว มีสองทางเลือก

Caddy หากยังไม่ได้ติดตั้ง Caddy ให้ทำตามขั้นตอนแพ็กเกจอย่างเป็นทางการสำหรับ Ubuntu เมื่อ Caddy รันเป็นเซอร์วิสบนโฮสต์ Caddyfile ด้านล่างจะพร็อกซีไปยัง Uptime Kuma บน loopback และจัดการออกใบรับรองกับต่ออายุให้อัตโนมัติ

เคล็ดลับ: ถ้า VPS สำหรับมอนิเตอร์รันแค่ Uptime Kuma อย่างเดียว ให้ใช้ Caddy ไฟล์ Caddyfile ยาวแค่สามบรรทัด และ Caddy จัดการออกใบรับรองกับต่ออายุให้เอง ไม่ต้องมี Certbot และไม่ต้องมีตัวจับเวลาต่ออายุแยกให้คอยดูตอนตีสี่

บันทึกสิ่งนี้เป็น /etc/caddy/Caddyfile:

status.example.com {
    reverse_proxy 127.0.0.1:3001
}

รีโหลด Caddy:

sudo systemctl reload caddy

ตรวจสอบ:

curl -I https://status.example.com

คุณควรได้รับการตอบกลับ 2xx หรือ 3xx ที่สำเร็จพร้อมใบรับรองที่ถูกต้อง หากเชื่อมต่อไม่สำเร็จ ให้ยืนยันว่าเรกคอร์ด A หรือ AAAA ของโดเมนชี้มาที่ VPS นี้ พอร์ต 80 และ 443 เข้าถึงได้ และ Caddy สามารถ bind ทั้งสองพอร์ตได้ ทั้งหมดนี้เป็นส่วนหนึ่งของ ข้อกำหนดของ HTTPS อัตโนมัติใน Caddy.

Nginx Proxy Manager ถ้า NPM รันบนโฮสต์โดยตรง ให้เพิ่ม Proxy Host สำหรับ status.example.com ส่งต่อไปที่ 127.0.0.1 พอร์ต 3001 ขอใบรับรอง Let's Encrypt แล้วเปิด Websockets Support แต่ถ้า NPM รันใน Docker ค่า 127.0.0.1 จะชี้กลับไปที่คอนเทนเนอร์ NPM เอง ให้เชื่อม NPM กับ Uptime Kuma เข้ากับ Docker network เดียวกันแทน แล้วส่งต่อ proxy host ไปยัง uptime-kuma พอร์ต 3001

การส่งการแจ้งเตือน: Telegram, Discord, Slack

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

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

ใน Telegram ให้ส่งข้อความหา @BotFather แล้วรัน /newbot เลือกชื่อและ username จากนั้น BotFather จะตอบกลับด้วย bot token ให้เก็บไว้
ส่งข้อความอะไรก็ได้ไปหาบอทตัวใหม่ จากนั้นเปิด https://api.telegram.org/bot<YOUR_TOKEN>/getUpdates ในเบราว์เซอร์ มองหาฟิลด์ chat.id นั่นคือ chat ID ของคุณ
ใน Uptime Kuma: Settings > Notifications > Setup Notification > Telegram วางบอทโทเคนและ chat ID แล้วคลิก ทดสอบ แล้วยืนยันว่าบอทส่งการแจ้งเตือนทดสอบออกมาจริง
ถ้าข้อความทดสอบไม่มาถึง ให้ตรวจสอบว่าบอทโทเคนและ chat ID ถูกต้อง และยืนยันว่าไฟร์วอลล์ของ VPS อนุญาต HTTPS ขาออกไปยัง api.telegram.org

Discord

เปิดเซิร์ฟเวอร์ Discord ที่ต้องการให้แจ้งเตือนเข้า คลิกขวาที่แชนเนลเป้าหมาย แล้วเลือก Edit Channel > Integrations > Webhooks > New Webhook ตั้งชื่อให้มัน (เช่น "Uptime Kuma") เลือกแชนเนล แล้วคัดลอก URL ของเว็บฮุก
ใน Uptime Kuma: Settings > Notifications > Setup Notification > Discord วาง URL ของเว็บฮุก และจะตั้งชื่อผู้ใช้กับอวาตาร์เพิ่มด้วยก็ได้
คลิก ทดสอบ แล้วยืนยันว่าเว็บฮุกโพสต์การแจ้งเตือนทดสอบลงแชนเนลจริง

Slack

ใน Slack ให้สร้าง Incoming Webhook สำหรับแชนเนลที่คุณต้องการให้แจ้งเตือนเข้า Slack จะคืน URL เว็บฮุกในรูปแบบ https://hooks.slack.com/services/T.../B.../....
ใน Uptime Kuma: Settings > Notifications > Setup Notification > Slack วาง URL ของเว็บฮุก และจะตั้งค่าไอคอนกับการเปลี่ยนแชนเนลเพิ่มด้วยก็ได้
คลิก ทดสอบ.

เมื่อทุกการทดสอบผ่านแล้ว ให้แก้ไขมอนิเตอร์แต่ละตัวและเลือกช่องทางแจ้งเตือนที่จะใช้ ตั้งค่า Max Retries (จำนวนครั้งที่ลองซ้ำสูงสุด) และ Retry Interval (ระยะเวลาระหว่างการลองซ้ำ) เพื่อไม่ให้ความล้มเหลวชั่วครู่เพียงครั้งเดียวทำให้เกิดการแจ้งเตือนทันที

หน้าสถานะที่มีมาให้ในตัว (และเมื่อไหร่ที่คุณจะเริ่มรู้สึกว่าไม่พอ)

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

ข้อจำกัดที่ใหญ่กว่าคือการสื่อสารกับลูกค้า ตอนนี้ผู้เข้าชมยังสมัครรับอัปเดตทางอีเมลจากหน้าสถานะโดยตรงไม่ได้ และหน้าสาธารณะนั้นก็ยังเป็นส่วนหนึ่งของแอป Uptime Kuma ตัวเดียวกับแดชบอร์ดของผู้ดูแล การให้ผู้เข้าชมสมัครเองยังคงถูกติดตามในฐานะ คำขอฟีเจอร์ที่ยังเปิดอยู่.

หากคุณต้องการให้ลูกค้าสมัครรับข่าวสาร หรืออยากได้ระบบสถานะที่แยกจากแดชบอร์ดมอนิเตอร์ Kener คือทางเลือกหนึ่ง บทความ สแตกมอนิเตอร์แบบโฮสต์เอง ของเราอธิบายว่าจะจับสองเครื่องมือนี้มาใช้ร่วมกันได้อย่างไร

ปัญหาที่พบบ่อย

การแจ้งเตือนล้มเหลวแบบเงียบ ๆ เมื่อไฟร์วอลล์ของ VPS บล็อก HTTPS ขาออก อาการ: ปุ่ม Test ใช้ได้กับบางช่องทาง แต่บางช่องทางไม่ได้ วิธีแก้: ยืนยันว่าอนุญาตการเชื่อมต่อ HTTPS ขาออก และคำสั่ง curl -I https://api.telegram.org ทำงานสำเร็จจากบน VPS

เบราว์เซอร์ขึ้น "ERR_TOO_MANY_REDIRECTS" หลังจากเปิดใช้พร็อกซี ให้ตรวจหาการรีไดเรกต์ HTTP ไป HTTPS ที่ซ้ำซ้อนใน Caddy, Nginx Proxy Manager หรือ CDN ที่อยู่ด้านหน้า Uptime Kuma ควรให้บริการ HTTP บนพอร์ต 3001 ต่อไป โดยให้รีเวิร์สพร็อกซีสาธารณะเป็นตัวจบ TLS หากคุณเปิดใช้เฮดเดอร์พร็อกซีที่เชื่อถือได้ เส้นทางปัจจุบันคือ Settings > Reverse Proxy > HTTP Headers > Trust Proxy.

คอนเทนเนอร์รีสตาร์ททุกไม่กี่นาที ตรวจดูว่าคอนเทนเนอร์ถูกสั่งหยุดเพราะหน่วยความจำหมดหรือไม่ แล้วเฝ้าดูการใช้งานปัจจุบันด้วย docker stats uptime-kuma หากคอนเทนเนอร์โดน OOM kill หรือหน่วยความจำค้างอยู่ใกล้เพดานของ VPS ให้เพิ่ม RAM ลดการตรวจที่หนัก หรือขยายช่วงเวลาตรวจให้ห่างขึ้น

หน้าสถานะใช้ได้บน localhost แต่ใช้ผ่านชื่อโฮสต์สาธารณะไม่ได้ ยืนยันว่ารีเวิร์สพร็อกซีส่งต่อพาธรากโดยไม่ดัดแปลง คงเฮดเดอร์ Host ไว้ และรองรับ WebSockets ทั้งนี้ Uptime Kuma ไม่รองรับการติดตั้งใต้ไดเรกทอรีย่อย จึงควรใช้โดเมนหรือซับโดเมนเฉพาะ แทนที่จะใช้พาธแบบ example.com/uptime-kuma

สรุป

การรัน Uptime Kuma บน VPS แยกต่างหากทำให้คุณคุมการตรวจสอบ เส้นทางแจ้งเตือน และหน้าสถานะสาธารณะได้เอง แต่คุณก็ต้องรับผิดชอบการอัปเดต การสำรองข้อมูล การแพตช์ระบบปฏิบัติการ และตัวเฝ้าระวังภายนอกสำหรับตัวมอนิเตอร์เองด้วย เลือก VPS ที่อยู่คนละโลเคชันกับโปรดักชัน ดีพลอย v2 ด้วย Docker Compose หรือใช้แอปคลิกเดียวหลังตรวจเวอร์ชันที่ระบุไว้แล้ว วาง Caddy ไว้ข้างหน้า และต่อช่องทางที่ทีมคุณเฝ้าดูจริง ๆ

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

Uptime Kuma ต้องใช้ RAM เท่าไร?

Uptime Kuma ไม่มีสูตรที่เชื่อถือได้ระหว่างจำนวนมอนิเตอร์กับ RAM เพราะการใช้งานเปลี่ยนไปตามชนิดมอนิเตอร์ ช่วงเวลาตรวจสอบ การตั้งค่า retry ระยะเก็บประวัติ และการใช้ Browser Engine หากมีการตรวจสอบพื้นฐานไม่กี่รายการ ให้เริ่มที่ RAM 1 GB แล้วดูการใช้งานจริงด้วย docker stats uptime-kuma เพิ่มหน่วยความจำถ้าการใช้งานค้างอยู่ใกล้เพดาน หรือคอนเทนเนอร์โดน OOM kill

ควรรัน Uptime Kuma บนเซิร์ฟเวอร์เดียวกับแอปของฉันไหม?

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

Uptime Kuma ส่งการแจ้งเตือนไปยัง Telegram, Discord และ Slack ได้ไหม?

ได้ Telegram, Discord และ Slack เป็นบริการแจ้งเตือนที่มีมาให้ในตัว เคียงข้างอีเมล เว็บฮุกทั่วไป PagerDuty, ntfy, Mattermost และอีกมาก Telegram ใช้บอทโทเคนกับ chat ID ส่วน Discord และ Slack ใช้ URL ของเว็บฮุก คุณผูกหลายช่องทางแจ้งเตือนเข้ากับมอนิเตอร์ตัวเดียวกันได้

Uptime Kuma กับ UptimeRobot ต่างกันอย่างไร?

Uptime Kuma เป็นแบบโฮสต์เอง คุณจึงต้องดูแลเซิร์ฟเวอร์ การอัปเดต การสำรองข้อมูล และการส่งการแจ้งเตือนเอง โดยรองรับช่วงเวลาตรวจสอบสั้นสุดถึง 20 วินาที ส่วน UptimeRobot เป็น SaaS ที่เขาโฮสต์ให้ และแพ็กเกจฟรีปัจจุบันให้มอนิเตอร์ 50 รายการ ตรวจทุกห้านาที เลือก Uptime Kuma ถ้าคุณต้องการควบคุมเอง หรือเลือก UptimeRobot ถ้าไม่อยากดูแลเซิร์ฟเวอร์มอนิเตอร์

Uptime Kuma มีหน้าสถานะสาธารณะไหม?

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

เขียนโดย

Chike

นักเขียนด้าน DevOps รับเชิญ

Chike เป็นวิศวกร DevOps ที่ชอบงานคอนเทนต์ ทำงานทางไกลจากลากอส เขามีประสบการณ์กับไปป์ไลน์การดีพลอยทั้งสาย ทั้ง CI/CD การมอนิเตอร์ การจัดการคอนเทนเนอร์ และการจัดเตรียมเซิร์ฟเวอร์ เขาเข้าสู่งานคอนเทนต์ด้วยการอาสาอัปเดตบทความที่ไม่มีใครอยากแตะ แล้วต่อยอดเป็นอาชีพจากตรงนั้น

วิธีติดตั้ง Uptime Kuma บน VPS