DEV Community: Garudust

ตรวจ CPU/Memory ทุกชั่วโมงด้วย Garudust Agent Cron ในตัว

Garudust — Wed, 27 May 2026 09:14:17 +0000

garudust-agent มี cron scheduler ในตัวอยู่แล้ว ภายใต้ crates/garudust-cron ที่ wraps tokio_cron_scheduler ไว้ หน้าที่ของมันคือยิง agent task ตาม schedule โดยตรง — ไม่ต้องสร้าง process ใหม่ทุกรอบ session ยังอยู่ใน RAM ข้าม tick ได้ และ agent สร้าง/ลบ job เองตอน runtime ได้ด้วย

บทความนี้ใช้ระบบ cron ใน garudust ทำงานให้ถูกต้อง

สิ่งที่ต้องมี

Linux / macOS
garudust-server binary (v0.13.1+)
API key จาก OpenAI-compatible endpoint

1. ติดตั้ง Binary

ARCH=$(uname -m)

curl -Lo garudust.tar.gz \
  "https://github.com/ninenox/garudust-agent/releases/download/v${GARUDUST_VERSION}/garudust-${ARCH}-unknown-linux-gnu.tar.gz"

tar -xzf garudust.tar.gz
chmod +x garudust-server
sudo mv garudust-server /usr/local/bin/garudust-server

garudust-server --version
# garudust-server 0.13.1

# macOS (Apple Silicon)
curl -Lo garudust.tar.gz \
  "https://github.com/ninenox/garudust-agent/releases/download/v${GARUDUST_VERSION}/garudust-aarch64-apple-darwin.tar.gz"
tar -xzf garudust.tar.gz
chmod +x garudust-server
sudo mv garudust-server /usr/local/bin/garudust-server

2. ตั้ง Config

ไฟล์ config อยู่ที่ ~/.garudust/config.yaml — สร้าง directory ก่อน:

mkdir -p ~/.garudust

# ~/.garudust/config.yaml

model: "gpt-4o-mini"
api_key: "sk-..."

tools:
  terminal:
    enabled: true
    sandbox: none          # รันบน host โดยตรง — monitoring อ่านอย่างเดียว ปลอดภัย
    approval_mode: auto    # cron รันโดยไม่มีคนนั่งดู ต้องเป็น auto

# ── cron ──────────────────────────────────────────────────────────────────────
cron:
  timezone: "Asia/Bangkok"   # IANA timezone — ถ้าไม่ระบุ default เป็น UTC

  jobs:
    - schedule: "0 * * * *"  # 5-field unix cron: ทุกชั่วโมง นาทีที่ 0
      task: >
        ตรวจสอบสุขภาพของระบบตอนนี้ด้วยคำสั่งต่อไปนี้:
        1. `top -bn1 | head -20`
        2. `ps aux --sort=-%cpu | head -10`
        3. `free -h`
        4. `ps aux --sort=-%mem | head -10`
        รายงานผลเป็นภาษาไทยตาม threshold ที่กำหนดไว้

  # (ทางเลือก) จัดระเบียบ memory ของ agent ทุกคืน
  memory_consolidation: "0 3 * * *"

  # (ทางเลือก) ลบ memory เก่ากว่า 30 วัน
  memory_expiry: "0 4 * * *"

system_prompt: |
  คุณคือ system monitor สำหรับเซิร์ฟเวอร์นี้

  Threshold สำหรับแจ้งเตือน:
  - CPU รวม > 80%  → ⚠️ WARNING
  - CPU รวม > 95%  → 🔴 CRITICAL
  - Memory > 75%   → ⚠️ WARNING
  - Memory > 90%   → 🔴 CRITICAL

  เมื่อเกิน threshold ให้:
  1. ระบุ process ที่กินสูงสุด 5 อันดับ
  2. ประเมินว่าเป็น spike ชั่วคราว หรือ trend ต่อเนื่อง
  3. แนะนำ action ถ้าจำเป็น

  ถ้าทุกอย่างปกติ สรุปสั้น 2–3 บรรทัดก็พอ
  ตอบเป็นภาษาไทยเสมอ

3. รัน Server

garudust-server

ที่ startup จะเห็น log ยืนยัน cron ถูก register:

INFO garudust-server 0.13.1 | model: gpt-4o-mini | port: 3000
INFO cron job registered  cron="0 * * * *"  task="ตรวจสอบสุขภาพของระบบ..."
INFO memory consolidation cron registered  cron="0 3 * * *"
INFO memory expiry cron registered  cron="0 4 * * *"
INFO garudust-server listening on 0.0.0.0:3000

เมื่อ cron fire จะเห็น:

INFO cron job starting   task="ตรวจสอบสุขภาพของระบบ..."
INFO cron job completed  task="ตรวจสอบสุขภาพของระบบ..."  iterations=3

หรือถ้า agent เจอปัญหา:

ERROR cron job failed  task="ตรวจสอบสุขภาพของระบบ..."  error="..."

4. รัน Server แบบ Daemon ด้วย systemd

สำหรับ production ไม่ควรรันใน terminal ค้างไว้ — ใช้ systemd:

sudo tee /etc/systemd/system/garudust-monitor.service > /dev/null <<EOF
[Unit]
Description=Garudust System Monitor
After=network.target

[Service]
Type=simple
User=$USER
ExecStart=/usr/local/bin/garudust-server
Restart=on-failure
RestartSec=10
Environment=RUST_LOG=info

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now garudust-monitor
sudo systemctl status garudust-monitor

5. เช็ก Log

เมื่อรันด้วย systemd:

# Log real-time
journalctl -u garudust-monitor -f

# Log ย้อนหลัง 1 ชั่วโมง
journalctl -u garudust-monitor --since "1 hour ago"

# กรองเฉพาะรอบที่ cron fire
journalctl -u garudust-monitor -g "cron job"

# หารอบที่มี WARNING หรือ CRITICAL
journalctl -u garudust-monitor --since today | grep -E "WARNING|CRITICAL|⚠️|🔴"

ถ้าอยากเก็บ log เป็นไฟล์แยก ใส่เพิ่มใน systemd unit:

[Service]
StandardOutput=append:/var/log/garudust-monitor.log
StandardError=append:/var/log/garudust-monitor.log

6. เพิ่ม Job แบบ Runtime ผ่าน API

นอกจาก static job ใน config แล้ว agent มี tool cron_create / cron_list / cron_delete ให้ใช้ตอน runtime — สั่งผ่าน HTTP API ได้เลย:

# สร้าง job ตรวจ disk ทุก 6 ชั่วโมง
curl -s -X POST http://localhost:3000/chat \
  -H "Content-Type: application/json" \
  -d '{
    "message": "สร้าง cron job label: disk_check ทุก 6 ชั่วโมง ให้รัน df -h แล้วแจ้งถ้า disk ใด partition ใดเกิน 85%"
  }' | jq .reply

agent จะใช้ tool cron_create สร้าง job ให้อัตโนมัติ:

{
  "reply": "✅ สร้าง cron job 'disk_check' แล้ว\nschedule: 0 0 */6 * * *\ntask: รัน df -h ตรวจ disk..."
}

หมายเหตุ — Cron syntax ต่างกัน 2 แบบ:

Static job ใน config.yaml → 5-field unix cron ปกติ เช่น 0 * * * *

Runtime job ผ่าน API → 6-field (เพิ่ม field วินาทีนำหน้า) เช่น 0 0 * * * * = ทุกชั่วโมง, 0 0 */6 * * * = ทุก 6 ชั่วโมง

# ดู job ทั้งหมดที่ active ตอนนี้
curl -s -X POST http://localhost:3000/chat \
  -d '{"message": "แสดง cron jobs ทั้งหมด"}' | jq .reply

# ลบ job
curl -s -X POST http://localhost:3000/chat \
  -d '{"message": "ลบ cron job label: disk_check"}' | jq .reply

Tip: Runtime jobs หายเมื่อ restart — สำหรับ permanent job ให้ใส่ใน config.yaml เสมอ Runtime jobs เหมาะสำหรับทดสอบ schedule ก่อน commit config หรือ one-off jobs ชั่วคราว

7. ตั้ง Alert ผ่าน Telegram (ทางเลือก)

เพิ่ม platform Telegram เข้าไปใน config — agent จะส่งข้อความหา admin โดยตรงเมื่อ cron fire และเจอปัญหา:

# ~/.garudust/.env
TELEGRAM_TOKEN=bot_token_here

# config.yaml — เพิ่ม/แก้ cron.jobs section นี้
cron:
  timezone: "Asia/Bangkok"
  jobs:
    - schedule: "0 * * * *"
      task: >
        ตรวจ CPU/Memory ของระบบ ถ้าพบ WARNING หรือ CRITICAL
        ให้ส่งข้อความแจ้งไปยัง admin ทาง Telegram ด้วย
        พร้อมระบุ process และ % ที่เกิน threshold

เปรียบเทียบกับ System Cron

	System Cron	Garudust Cron (built-in)
Process per tick	spawn ใหม่ทุกครั้ง	ทำงานใน event loop เดิม
Session/memory	โหลดใหม่ทุกรอบ	อยู่ใน RAM ข้าม tick ได้
Dynamic schedule	แก้ crontab เอง	agent สร้าง/ลบตอน runtime
Log	ไฟล์แยก	รวมกับ server log เดียวกัน
Timezone	ขึ้นกับ system TZ	กำหนดใน config ได้ per-scheduler
Dependency	ต้องมี cron daemon	ไม่ต้องการ — built into server

สรุป config ทั้งหมด

~/.garudust/
├── config.yaml          ← cron.jobs, tools, system_prompt
└── .env                 ← API keys, tokens (ไม่ commit)

garudust-server start
    ↓
register cron jobs จาก config.yaml
    ↓
ทุก 1 ชม. → agent run → terminal tool → top/free/ps
    ↓
log ออก stdout/journald
    ↓ (ถ้าต่อ Telegram)
send alert เมื่อเกิน threshold

จุดเด่นที่ system cron ทำไม่ได้: agent จำ pattern ข้ามรอบได้ เช่น รู้ว่า CPU spike ทุก 14:00 คือ backup job ไม่ใช่ anomaly — เพราะ memory session ยังอยู่ในหน่วยความจำระหว่าง tick

garudust-agent → github.com/garudust-org/garudust-agent

Chat With Your Raspberry Pi — Control GPIO, Read Sensors, and Manage Services via Telegram Using Garudust

Garudust — Tue, 26 May 2026 15:41:33 +0000

Your Raspberry Pi is sitting at home doing something useful — logging sensor data, driving a relay, running a home assistant script. You're out. You want to check on it.

You used to SSH in from your laptop. Today you just open Telegram and ask.

You:    is the temperature sensor still working?
Agent:  ✓ ran: cat /sys/bus/w1/devices/28-*/w1_slave
        Current temperature: 24.3°C — sensor is responding normally.

You:    turn the fan relay on
Agent:  ⚠ This will trigger GPIO 18 — confirm? [y/n]
You:    y
Agent:  ✓ ran: python3 ~/scripts/relay.py on 18
        Relay ON. Fan is running.

This is Garudust Agent with an SSH sandbox. The agent lives on a cloud VPS (or any server with internet access). You chat via Telegram. The agent SSHes into your Pi and runs whatever it needs to. Your Pi only needs SSH enabled — no extra software, no port forwarding for the agent.

How It Works

You (Telegram)
    │
    ▼
garudust-server          ← runs on a VPS or home server
(Telegram adapter)
    │
    │  SSH  (key auth, BatchMode, StrictHostKeyChecking)
    ▼
Raspberry Pi             ← just needs sshd running
(GPIO, sensors, scripts)

The agent's terminal tool normally runs commands locally. With terminal_sandbox: ssh, every command is forwarded through ssh to the Pi instead. The agent never knows or cares — it still calls the same tool. The routing happens transparently in the sandbox layer.

Prerequisites

A Raspberry Pi with SSH enabled (any model, any recent Raspberry Pi OS)
A server to run Garudust on — a $5 VPS, another machine on your network, or even the Pi itself pointing at localhost
A Telegram bot token (from @BotFather)
Garudust installed on the server

# On the server — install Garudust
curl -LO "https://github.com/garudust-org/garudust-agent/releases/latest/download/garudust-$(curl -s https://api.github.com/repos/garudust-org/garudust-agent/releases/latest | grep tag_name | cut -d'"' -f4)-x86_64-unknown-linux-musl.tar.gz"
tar -xzf garudust-*.tar.gz && sudo mv garudust garudust-server /usr/local/bin/

Step 1 — Set Up a Dedicated SSH Key

Never use your personal SSH key for an agent. Create a dedicated one on the server:

ssh-keygen -t ed25519 -f ~/.ssh/garudust_pi -N "" -C "garudust-agent"

Copy the public key to the Pi:

ssh-copy-id -i ~/.ssh/garudust_pi.pub pi@192.168.1.50
# or if Pi is not on the same network yet:
# cat ~/.ssh/garudust_pi.pub | ssh pi@<pi-ip> "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Verify it works without a password prompt:

ssh -i ~/.ssh/garudust_pi -o BatchMode=yes pi@192.168.1.50 "echo OK"
# → OK

Step 2 — Configure Garudust

~/.garudust/.env:

ANTHROPIC_API_KEY=sk-ant-...       # or any supported provider
TELEGRAM_TOKEN=123456789:AAFxxx    # your bot token

~/.garudust/config.yaml:

security:
  approval_mode: smart             # read-only commands auto-approve, writes ask first
  terminal_sandbox: ssh
  ssh_host: "192.168.1.50"         # your Pi's IP (or hostname)
  ssh_user: "pi"
  ssh_port: 22
  ssh_key_path: /home/youruser/.ssh/garudust_pi

platforms:
  telegram:
    enabled: true
    port: 8443
    webhook_path: /telegram

roles:
  default_role: ~                  # strangers get no access
  definitions:
    owner:
      approval_mode: auto          # full auto-approve for you
  users:
    telegram:
      "YOUR_TELEGRAM_USER_ID": owner

Find your Telegram user ID by messaging @userinfobot.

Start the server:

garudust-server

What You Can Now Do

Read Sensor Data

DS18B20 temperature sensor (1-Wire):

You:    temperature?
Agent:  24.3°C

You:    log temperature every 10 seconds for 1 minute and tell me the average
Agent:  ✓ ran: for i in $(seq 6); do cat /sys/bus/w1/devices/28-*/w1_slave | grep t= | awk -F= '{print $2/1000}'; sleep 10; done
        Readings: 24.1, 24.2, 24.3, 24.3, 24.4, 24.2
        Average: 24.25°C

DHT22 humidity + temperature:

You:    humidity and temp from the DHT22
Agent:  ✓ ran: python3 ~/scripts/dht22_read.py
        Temperature: 24.3°C  Humidity: 58.2%

Control GPIO (Relay, LED, Motor)

You:    turn on the garden lights (relay on GPIO 18)
Agent:  ⚠ This will modify GPIO state — confirm?
You:    yes
Agent:  ✓ ran: python3 ~/scripts/relay.py on 18
        GPIO 18 HIGH — relay activated.

You:    set the LED strip to blue
Agent:  ✓ ran: python3 ~/scripts/led_strip.py color 0 0 255
        Done.

You:    turn everything off
Agent:  ✓ ran: python3 ~/scripts/all_off.py
        All GPIO outputs set LOW.

Check System Health

You:    how is the Pi doing?
Agent:  ✓ ran: vcgencmd measure_temp && free -h && df -h / && uptime
        CPU temp:    52.1°C
        RAM:         823 MB used / 1.9 GB total
        Disk:        12 GB used / 29 GB total (41%)
        Uptime:      14 days, 3 hours

You:    is anything hogging the CPU?
Agent:  ✓ ran: ps aux --sort=-%cpu | head -6
        python3 sensor_logger.py   4.2%
        node    homebridge          2.8%
        Everything else < 1%.

Manage Services

You:    restart homebridge
Agent:  ⚠ This will restart the homebridge service — confirm?
You:    y
Agent:  ✓ ran: sudo systemctl restart homebridge
        homebridge restarted. Status: active (running).

You:    is the camera stream still up?
Agent:  ✓ ran: systemctl is-active mjpg-streamer
        active

You:    show me the last 20 lines of the sensor log
Agent:  ✓ ran: tail -20 ~/logs/sensor.log
        [2026-05-26 14:01] temp=24.3 hum=58.2
        [2026-05-26 14:02] temp=24.4 hum=57.9
        ...

Run Your Own Scripts

The agent can run any script already on the Pi. You don't need to teach it the commands — just describe what you want:

You:    water the plants for 30 seconds
Agent:  ✓ ran: python3 ~/scripts/sprinkler.py on 30
        Valve opened. Will close in 30 seconds.

You:    take a photo and tell me if the bird feeder is empty
Agent:  ✓ ran: raspistill -o /tmp/feeder.jpg -w 1280 -h 720
        [reads image]
        The feeder appears about 30% full — seeds visible on the left side.

Automate With Cron

Set recurring checks without staying in the chat:

# config.yaml
cron:
  timezone: "Asia/Bangkok"
  jobs:
    - schedule: "0 8 * * *"
      task: "check Pi health and send a morning summary to Telegram"
    - schedule: "*/30 * * * *"
      task: "read the temperature sensor; if above 70°C send a warning to Telegram"

Now the agent proactively messages you — no need to ask.

Security Notes

A few things worth knowing before you deploy this:

The SSH connection is hardened automatically. Garudust uses BatchMode=yes (no password prompts), StrictHostKeyChecking=accept-new (rejects changed host keys to prevent MITM), and clears the subprocess environment before spawning ssh so no API keys or secrets reach the Pi.

Approval mode gates destructive commands. With approval_mode: smart, read-only commands (reading sensors, checking logs, git status) run without asking. Anything that modifies state asks for confirmation first. Set approval_mode: auto only for yourself after you've tested it.

Lock down the pi user if you want to go further. Restrict the SSH key to specific commands using command= in authorized_keys, or run the agent's SSH user in a dedicated account with only the scripts it needs to call.

The Pi never exposes a port to the internet. The agent SSHes out from the server to the Pi — the Pi only needs port 22 open to your server, not to the world.

What's Next

Multiple Pis — point different agent sessions at different hosts; or build a thin wrapper script that SSHes to the right Pi based on what you ask
Voice control — pair with iApp TTS to get spoken responses back on a speaker connected to the Pi
Skill learning — after you run a workflow a few times, Garudust automatically writes it as a reusable skill so you don't need to describe it step by step anymore

The full source for Garudust is at garudust-org/garudust-agent. The SSH sandbox landed in v0.13 — grab the latest binary from Releases or build from source with cargo build --release.

SSH Remote Terminal ใน Garudust Agent — ให้ AI สั่งงานบน Server จริงได้เลย

Garudust — Tue, 26 May 2026 15:18:51 +0000

ก่อนหน้านี้ Garudust Agent รัน terminal tool ได้สองแบบ — บนเครื่อง local โดยตรง หรือ wrap ผ่าน Docker container เพื่อ isolation

v0.13 เพิ่ม SSH sandbox — แบบที่สาม ที่ส่งทุก command ผ่าน ssh ไปรันบน remote host แทน

security:
  terminal_sandbox: ssh
  ssh_host: "build.example.com"
  ssh_user: "deploy"
  ssh_port: 22
  ssh_key_path: ~/.ssh/deploy_key

ไม่ต้องแก้โค้ด ไม่ต้องเพิ่ม dependency — ใช้ ssh binary ที่มีอยู่แล้ว

ทำไมถึงมีประโยชน์?

ปัญหาของ terminal_sandbox: none และ docker คือทั้งคู่รันบนเครื่องที่ garudust อยู่เท่านั้น ถ้า agent อยู่บน laptop แต่อยากให้มันจัดการ production server — ก็ทำไม่ได้

SSH sandbox แก้ปัญหานี้ตรงๆ

Use Case 1 — Build & Deploy บน Remote Server

สมมติมี build server แยกต่างหาก ไม่อยากให้ laptop ต้อง build เอง:

security:
  terminal_sandbox: ssh
  ssh_host: "build.internal.example.com"
  ssh_user: "ci"
  ssh_key_path: ~/.ssh/ci_key

แล้วคุยกับ agent ได้เลย:

"build release และ deploy ไปที่ /opt/app"

Agent จะรัน:

cargo build --release — บน build server
systemctl restart myapp — บน build server

เครื่อง local ไม่ต้องมี Rust, ไม่ต้องมี prod credentials ไม่มีอะไรรั่วออกมา

Use Case 2 — Ops Assistant จาก Telegram

ผูก Garudust เข้า Telegram แล้วถามสุขภาพ server ได้ตลอดเวลา:

คุณ: disk เต็มไหม
Agent: ✓ terminal: df -h /
       / → 23% used (226 GB / 981 GB)
       ปกติดีครับ

คุณ: process ที่กิน RAM มากสุด 5 อันดับ
Agent: ✓ terminal: ps aux --sort=-%mem | head -6
       1. postgres   12.3%
       2. node       8.1%
       ...

ทุก command ผ่าน hardline check + approval gate ก่อนเสมอ — ไม่มีทางที่ prompt injection จะสั่ง rm -rf ได้

Use Case 3 — ควบคุม Raspberry Pi ผ่าน LINE

Pi อยู่ใน home network ไม่ได้ expose port ออกอินเทอร์เน็ต ให้ garudust-server อยู่บน Pi เดียวกันหรือเครื่องในวง LAN แล้วรับคำสั่งจาก LINE:

security:
  terminal_sandbox: ssh
  ssh_host: "192.168.1.50"   # Pi อยู่ใน LAN
  ssh_user: "pi"

"เปิดสปริงเกลอร์ 5 นาที"
→ terminal: python3 ~/scripts/sprinkler.py on 300

"อุณหภูมิตอนนี้เท่าไหร่"
→ terminal: cat /sys/bus/w1/devices/28-*/w1_slave | grep t= | awk -F= '{printf "%.1f°C\n", $2/1000}'

สั่งงานผ่าน LINE ได้เหมือน SSH เข้าไปเอง แต่ไม่ต้องเปิด terminal

Use Case 4 — Isolated Environment โดยไม่ใช้ Docker

บางเครื่อง Docker ไม่ available (ARM SBC, embedded, VPS ราคาถูก) แต่อยากได้ isolation — ใช้ VM หรือ LXC container ที่มี SSH แทน:

laptop (garudust) → SSH → sandbox VM → รัน untrusted code

ถ้า agent ทำอะไรผิดพลาด snapshot VM กลับมาได้ทันที โดยที่ local filesystem ไม่โดนแตะเลย

Security ที่ได้มาโดยอัตโนมัติ

SSH sandbox ไม่ได้แค่ส่ง command ไป remote — มี hardening ติดมาด้วยทุกครั้ง:

Property	วิธีทำ
ไม่มี interactive prompt	`BatchMode=yes` — fail ทันทีถ้า key auth ล้มเหลว
ป้องกัน MITM	`StrictHostKeyChecking=accept-new` — เชื่อ host แรก, ปฏิเสธถ้า key เปลี่ยน
Connection timeout	`ConnectTimeout=min(timeout, 30)` — ไม่แขวน process
ป้องกัน flag injection	`--` ก่อน command เสมอ — command ที่ขึ้นต้นด้วย `-` ไม่ถูกตีความเป็น ssh flag
Secrets ไม่รั่ว	`env_clear()` ก่อน spawn ssh — API key ไม่ถึง remote host

ลองได้เลย — ไม่ต้องมี server จริง

# 1. สร้าง SSH key สำหรับทดสอบ
ssh-keygen -t ed25519 -f /tmp/test_key -N ""

# 2. รัน SSH container
PUBKEY=$(cat /tmp/test_key.pub)
docker build -t sshd-test - << 'EOF'
FROM ubuntu:24.04
RUN apt-get update -qq && apt-get install -y openssh-server \
    && useradd -m testuser && mkdir -p /home/testuser/.ssh /var/run/sshd
ARG PUBKEY
RUN echo "$PUBKEY" > /home/testuser/.ssh/authorized_keys \
    && chmod 700 /home/testuser/.ssh \
    && chmod 600 /home/testuser/.ssh/authorized_keys \
    && chown -R testuser:testuser /home/testuser/.ssh \
    && ssh-keygen -A
EXPOSE 22
CMD ["/usr/sbin/sshd", "-D"]
EOF
docker run -d --name sshd-test -p 2222:22 --build-arg PUBKEY="$PUBKEY" sshd-test

# 3. ทดสอบกับ garudust
GARUDUST_TERMINAL_SANDBOX=ssh \
GARUDUST_SSH_HOST=127.0.0.1 \
GARUDUST_SSH_USER=testuser \
GARUDUST_SSH_PORT=2222 \
GARUDUST_SSH_KEY_PATH=/tmp/test_key \
GARUDUST_APPROVAL_MODE=auto \
  garudust "บอก OS version, จำนวน CPU และ memory บน remote host"

ผลที่ได้ (จาก container):

- ระบบปฏิบัติการ: Ubuntu 24.04.4 LTS (Noble Numbat)
- จำนวน CPU: 14 แกน
- หน่วยความจำ: 7.7 GiB (ใช้ไป 544 MiB, ว่าง 6.7 GiB)

hostname คืน container ID → ยืนยันว่า command รันบน remote จริง ไม่ใช่ local

สรุป

Mode	เหมาะกับ
`none`	dev machine, ทดสอบ, low-risk tasks
`docker`	production local, untrusted code, ต้องการ filesystem isolation
`ssh`	remote server, IoT/Pi, build farm, VM sandbox, ไม่มี Docker

ติดตั้งจาก GitHub Releases หรือ:

cargo install garudust

Source: garudust-org/garudust-agent

Event Triggers บน Garudust

Garudust — Sat, 23 May 2026 03:24:03 +0000

core ของ Garudust เปิดเผย primitive พื้นฐานตัวเดียว: agent.run(task) ทุก entry point — ไม่ว่าจะเป็นข้อความจากแชท, cron job, หรือ webhook call — ล้วนลงเอยที่ call เดียวกันนี้ทั้งสิ้น นั่นหมายความว่าระบบภายนอกใดก็ตามที่ส่ง HTTP POST ได้ ก็สามารถเป็น event trigger ให้ Garudust ได้เลย

บทความนี้จะอธิบายว่ามันทำงานอย่างไรในปัจจุบัน, pattern ที่ใช้งานได้จริงใน production และ use case ที่เป็นรูปธรรม

Webhook Adapter ทำงานอย่างไร

เมื่อ Garudust ถูกตั้งค่าให้ใช้ webhook platform มันจะเปิด Axum HTTP server และลงทะเบียน POST endpoint ไว้ที่ path ที่คุณกำหนด request ขาเข้าจะมีหน้าตาแบบนี้:

{
  "text": "A new billing invoice has arrived from Acme Corp for $4,200.",
  "callback_url": "https://your-system.example.com/garudust/reply",
  "user_id": "billing-watcher",
  "session_key": "billing-acme-corp"
}

Field	Required	คำอธิบาย
`text`	✅	Task prompt ที่ agent จะนำไปรัน
`callback_url`	✅	URL ที่ Garudust จะ POST คำตอบกลับมา
`user_id`	optional	ใช้สำหรับ role-based access control
`session_key`	optional	ตรึง conversation history ไว้; ถ้าไม่ระบุจะ default เป็น `webhook:{callback_url}`

Garudust จะห่อข้อมูลนี้เป็น InboundMessage, ส่งผ่าน GatewayHandler, spawn agent.run() ขึ้นมา และเมื่อ agent ทำงานเสร็จก็จะ POST คำตอบกลับไปที่ callback_url:

{
  "text": "Invoice from Acme Corp for $4,200 — categorised as SaaS/Infrastructure. Flagged for approval above $3,000 threshold. Draft approval request sent to #finance."
}

HTTP response ที่ตอบกลับ POST ของคุณทันทีคือ 202 Accepted — agent ทำงานแบบ asynchronous

Security

Garudust ตรวจสอบ HMAC-SHA256 signature ทุก request ที่เข้ามา ตั้ง shared secret ใน config แล้ว sign ทุก POST ขาออกด้วย:

X-Hub-Signature-256: sha256=<hex(HMAC-SHA256(secret, raw_body))>

Request ที่ไม่มี signature ถูกต้องจะถูกปฏิเสธด้วย 401 และ callback URL ที่ชี้ไป private IP (192.168.x.x, 10.x.x.x, localhost) ก็ถูก block โดย network guard ด้วย — agent ไม่สามารถถูกบังคับให้ call back หา internal infrastructure ได้

Core Pattern

การแบ่งหน้าที่ชัดเจนมาก:

ระบบภายนอก                   Garudust
─────────────────             ──────────────────────────
Event source (email,    →     Webhook adapter
  calendar, DB, queue)
Filter / match logic    →     โค้ดของคุณ (ก่อน POST)
Task description        →     agent.run(task)
Result handling         →     handler ที่ callback_url ของคุณ

ระบบของคุณเป็นเจ้าของ filter — Garudust เป็นเจ้าของการรัน agent ทั้งสองฝั่งไม่จำเป็นต้องรู้โครงสร้างภายในของกันและกันเลย

Use Cases

1. Billing Email Monitor

บริการประมวลผลอีเมลคอยดักจับอีเมลจากผู้ส่งที่เป็นระบบ billing เมื่อเจออีเมลที่ match ก็ดึง subject, ผู้ส่ง และจำนวนเงิน แล้ว trigger Garudust:

{
  "text": "New invoice received: Stripe — $1,840 for May 2026. Attach to this month's expense report and notify the finance channel if it exceeds the $1,500 alert threshold.",
  "callback_url": "https://your-ops.example.com/hooks/garudust",
  "session_key": "finance-inbox"
}

Agent ใช้ tool ของมันอ่านไฟล์ expense report, เพิ่ม line item และโพสต์แจ้ง Slack บริการอีเมลทำแค่ match ผู้ส่งแล้วยิง — ไม่ต้องรู้อะไรเกี่ยวกับ expense report หรือ Slack เลย

2. GitHub PR Review Gate

GitHub Actions workflow เรียก Garudust หลังมี PR เปิดเข้ามาที่ branch main โดย workflow สร้าง payload จาก GitHub context:

{
  "text": "PR #214 opened by @alice: 'feat: add OAuth2 PKCE flow'. Changed files: src/auth/oauth.rs, src/auth/pkce.rs, tests/auth_integration.rs. Diff summary attached. Review for security issues in the auth flow and post a summary comment.",
  "callback_url": "https://your-ci.example.com/garudust/pr-review",
  "session_key": "pr-214"
}

webhook ของ GitHub ยิง workflow → workflow สร้าง task text → Garudust รีวิว และ session_key ที่ผูกกับเลข PR ทำให้ trigger ครั้งถัดไป (commit ใหม่, ขอรีวิวซ้ำ) ต่อเนื่องใน conversation thread เดิม

3. Database Anomaly Alert

Monitoring job query ฐานข้อมูลตามตาราง schedule แล้วตรวจ aggregate metric เมื่อ metric ข้ามเกณฑ์ แทนที่จะส่ง static alert มันยิง Garudust แทน:

{
  "text": "Anomaly detected: orders table insert rate dropped 94% in the last 10 minutes (baseline 340/min, current 19/min). Last successful insert: 09:42 UTC. Investigate root cause and summarise for on-call.",
  "callback_url": "https://ops.example.com/garudust/incidents",
  "session_key": "incident-2026-05-23-orders"
}

Agent สามารถใช้ terminal หรือ database tool รัน query เพิ่มเติม, ตรวจ deploy ล่าสุด และสรุป incident แบบมีโครงสร้าง — monitoring job ทำแค่ตรวจ threshold breach เท่านั้น

4. Calendar External-Attendee Watch

Integration layer poll Google Calendar (หรือรับ push notification) แล้วยิง Garudust เมื่อมี event ถูกสร้างขึ้นพร้อม attendee ที่ domain ไม่ตรงกับองค์กรของคุณ:

{
  "text": "New calendar event: 'Q3 partnership discussion' on 2026-06-04 14:00 UTC. External attendees: jane@partner.com, bob@partner.com. Prepare a one-page briefing on Partner Corp using the CRM notes and recent email thread.",
  "callback_url": "https://your-system.example.com/garudust/calendar",
  "session_key": "meeting-prep-2026-06-04"
}

Calendar integration เป็นเจ้าของ logic กรอง "external attendee" — Garudust เป็นเจ้าของการสร้าง briefing

5. Queue Worker Trigger

Background worker ดึงงานออกจาก task queue (SQS, Redis, RabbitMQ) แล้วส่งแต่ละชิ้นให้ Garudust ทำ เหมาะกับงานที่ปริมาณผันแปรและต้องการให้ agent จัดการแต่ละชิ้นในแบบของตัวเอง:

{
  "text": "Customer support ticket #8821 (priority: high): User reports that export to CSV silently truncates rows above 10,000. Reproduce the scenario, identify the code path responsible, and draft a fix description for the engineering team.",
  "callback_url": "https://support.example.com/garudust/tickets",
  "session_key": "ticket-8821"
}

Queue worker dequeue, จัดรูป task text, ยิง webhook หลาย ticket สามารถรันเป็น concurrent agent session พร้อมกันได้

Session Keys และความต่อเนื่อง

session_key คือสิ่งที่ทำให้ event trigger มีประโยชน์เกินกว่างานแบบ one-shot เมื่อคุณตรึง key ไว้ webhook call ทั้งหมดที่ใช้ key เดียวกันจะแชร์ conversation history ร่วมกัน หมายความว่า:

PR review trigger บน commit 1 และ re-review trigger บน commit 2 คือ conversation เดียวกัน — agent จำสิ่งที่พูดไปก่อนหน้าได้
Incident trigger และ "ตอนนี้เป็นยังไงบ้าง?" ที่ on-call engineer ถามทีหลังใช้ context เดียวกัน
Billing session สะสม invoice ทั้งเดือนจากหลาย trigger ก่อนสร้าง monthly summary

ถ้าต้องการแยก session ออกจากกันสมบูรณ์ (แต่ละ event เป็นอิสระ) ก็ไม่ต้องระบุ session_key — Garudust จะใช้ callback_url เป็น key แทน ทำให้ได้ context ใหม่ต่อ callback target ที่ไม่ซ้ำกัน

สิ่งที่ Pattern นี้ยังไม่ครอบคลุม

Webhook adapter คือ push target — ระบบภายนอกต้องเป็นฝ่ายเริ่มการเชื่อมต่อ ถ้าต้องการให้ Garudust ดึงข้อมูลจากแหล่งต้นทางเอง (ตรวจ inbox, poll API, เฝ้าดูไฟล์) โดยไม่ต้องมี scheduler นั้นต้องใช้ cron job ที่คอย poll หรือรอ primitive watch/filter ที่ยังไม่มีในปัจจุบัน

สำหรับ use case ที่เป็น push-based จริงๆ (GitHub webhook, queue worker, calendar push notification, email routing service) สถาปัตยกรรมปัจจุบันรองรับได้ครบและการแบ่งหน้าที่ก็ชัดเจนดีอยู่แล้ว

Event Triggers on Garudust

Garudust — Sat, 23 May 2026 03:10:52 +0000

Garudust's agent core exposes a single base primitive: agent.run(task). Every entry point — a chat message, a cron job, a webhook call — eventually resolves to that same call. This means any external system that can send an HTTP POST can act as an event trigger.

This article covers how that works today, the patterns that hold up in production, and concrete use cases.

How the Webhook Adapter Works

When Garudust is configured with the webhook platform, it starts an Axum HTTP server and registers a POST endpoint at a path you configure. An inbound request looks like this:

{
  "text": "A new billing invoice has arrived from Acme Corp for $4,200.",
  "callback_url": "https://your-system.example.com/garudust/reply",
  "user_id": "billing-watcher",
  "session_key": "billing-acme-corp"
}

Field	Required	Notes
`text`	✅	The task prompt the agent will run
`callback_url`	✅	Where Garudust POSTs the agent's reply
`user_id`	optional	Used for role-based access control
`session_key`	optional	Pins conversation history; defaults to `webhook:{callback_url}`

Garudust wraps this into an InboundMessage, passes it through GatewayHandler, spawns agent.run(), and when the agent finishes it POSTs the reply back to callback_url:

{
  "text": "Invoice from Acme Corp for $4,200 — categorised as SaaS/Infrastructure. Flagged for approval above $3,000 threshold. Draft approval request sent to #finance."
}

The HTTP response to your POST is 202 Accepted immediately — the agent runs asynchronously.

Security

Garudust verifies an HMAC-SHA256 signature on every inbound request. Set a shared secret in your config, and sign every outbound POST with:

X-Hub-Signature-256: sha256=<hex(HMAC-SHA256(secret, raw_body))>

Requests without a valid signature are rejected with 401. Private IP callback URLs (192.168.x.x, 10.x.x.x, localhost) are also blocked by the network guard — the agent cannot be made to call back to internal infrastructure.

The Core Pattern

The separation of concerns is explicit:

External system               Garudust
─────────────────             ──────────────────────────
Event source (email,    →     Webhook adapter
  calendar, DB, queue)
Filter / match logic    →     Your code (pre-POST)
Task description        →     agent.run(task)
Result handling         →     Your callback_url handler

Your system owns the filter. Garudust owns the agent execution. Neither needs to know the other's internal structure.

Use Cases

1. Billing Email Monitor

An email processing service watches your inbox for messages from known billing senders. When one matches, it extracts the subject, sender, and amount, then triggers Garudust:

{
  "text": "New invoice received: Stripe — $1,840 for May 2026. Attach to this month's expense report and notify the finance channel if it exceeds the $1,500 alert threshold.",
  "callback_url": "https://your-ops.example.com/hooks/garudust",
  "session_key": "finance-inbox"
}

The agent uses its tools to read the expense report file, append the line item, and post to Slack. Your email service only had to match sender and fire — it did not need to know anything about expense reports or Slack.

2. GitHub PR Review Gate

A GitHub Actions workflow calls Garudust after a PR is opened against main. The workflow builds the payload from the GitHub context:

{
  "text": "PR #214 opened by @alice: 'feat: add OAuth2 PKCE flow'. Changed files: src/auth/oauth.rs, src/auth/pkce.rs, tests/auth_integration.rs. Diff summary attached. Review for security issues in the auth flow and post a summary comment.",
  "callback_url": "https://your-ci.example.com/garudust/pr-review",
  "session_key": "pr-214"
}

GitHub's webhook fires the workflow; the workflow builds the task text; Garudust runs the review. The session_key is tied to the PR number so follow-up triggers (new commits, re-review requests) continue the same conversation thread.

3. Database Anomaly Alert

A monitoring job queries your database on a schedule and checks aggregate metrics. When a metric crosses a threshold, it fires Garudust instead of just sending a static alert:

{
  "text": "Anomaly detected: orders table insert rate dropped 94% in the last 10 minutes (baseline 340/min, current 19/min). Last successful insert: 09:42 UTC. Investigate root cause and summarise for on-call.",
  "callback_url": "https://ops.example.com/garudust/incidents",
  "session_key": "incident-2026-05-23-orders"
}

The agent can use its terminal or database tools to run follow-up queries, check recent deploys, and produce a structured incident summary — the monitoring job only needed to detect the threshold breach.

4. Calendar External-Attendee Watch

An integration layer polls Google Calendar (or receives push notifications) and fires Garudust when an event is created with an attendee whose domain does not match your organisation:

{
  "text": "New calendar event: 'Q3 partnership discussion' on 2026-06-04 14:00 UTC. External attendees: jane@partner.com, bob@partner.com. Prepare a one-page briefing on Partner Corp using the CRM notes and recent email thread.",
  "callback_url": "https://your-system.example.com/garudust/calendar",
  "session_key": "meeting-prep-2026-06-04"
}

The calendar integration owns the "external attendee" filter logic. Garudust owns the briefing generation.

5. Queue Worker Trigger

A background worker drains a task queue (SQS, Redis, RabbitMQ) and dispatches each item to Garudust. This is useful for workloads where volume is variable and you want the agent to handle each item at its own pace:

{
  "text": "Customer support ticket #8821 (priority: high): User reports that export to CSV silently truncates rows above 10,000. Reproduce the scenario, identify the code path responsible, and draft a fix description for the engineering team.",
  "callback_url": "https://support.example.com/garudust/tickets",
  "session_key": "ticket-8821"
}

The queue worker dequeues, formats the task text, fires the webhook. Multiple tickets run as concurrent agent sessions.

Session Keys and Continuity

session_key is what makes event triggers useful beyond one-shot tasks. When you pin a key, all webhook calls with that key share the same conversation history. This means:

A PR review trigger on commit 1 and a re-review trigger on commit 2 are the same conversation — the agent remembers what it said before.
An incident trigger and a follow-up "what's the status?" call from your on-call engineer share context.
A billing session can accumulate all invoices for the month across multiple triggers before generating the monthly summary.

If you want complete isolation (each event is independent), omit session_key — Garudust will key the session to the callback_url, giving you a fresh context per unique callback target.

What This Pattern Does Not Cover

The webhook adapter is a push target — your external system must initiate the call. If you need Garudust to pull from a source (check an inbox, poll an API, watch a file) on its own without a scheduler, that requires either a cron job that polls, or a future watch/filter primitive that does not exist yet.

For use cases that are genuinely push-based (GitHub webhooks, queue workers, calendar push notifications, email routing services), the current architecture is sufficient and the separation of concerns is clean.

Cron & Scheduled Tasks in Garudust Agent — Autonomous Agents That Run Without You

Garudust — Thu, 21 May 2026 07:17:45 +0000

Most AI agents wait. They sit idle until a human types something, respond, then go back to waiting.

Garudust Agent can be different. With garudust-cron, you schedule tasks using standard cron syntax — the agent wakes up, runs a full LLM loop with all its tools, and goes back to sleep. No human required.

This post shows you exactly how to configure it, with the correct syntax pulled straight from the source.

How It Works

garudust-cron is a crate within the Garudust workspace. When a scheduled trigger fires, it calls agent.run(task) — the same code path as a user typing a message. The agent has access to all its configured tools: file read/write, terminal, RAG, web search, and anything else you've enabled.

Cron runs as part of garudust-server. There is no separate daemon.

Three Ways to Set Up Cron Jobs

1. `config.yaml` — Permanent, survives restarts

# ~/.garudust/config.yaml
cron:
  jobs:
    - schedule: "0 0 9 * * 1-5"   # weekdays at 09:00 (server timezone)
      task: "Write a morning briefing and append it to ~/briefing.md"

    - schedule: "0 0 18 * * 5"    # Fridays at 18:00
      task: "Summarise this week's git commits and save to ~/weekly.md"

CronJob has exactly two fields: schedule and task. Nothing else.

schedule uses 6-field cron syntax (seconds first):

┌───────── second (0–59)
│ ┌─────── minute (0–59)
│ │ ┌───── hour (0–23)
│ │ │ ┌─── day of month (1–31)
│ │ │ │ ┌─ month (1–12)
│ │ │ │ │ ┌ day of week (0–6, Sun=0)
│ │ │ │ │ │
0 0 9 * * 1-5

Timezone follows the server process — set your system timezone before starting garudust-server if needed.

2. CLI flag or environment variable — One-off / Docker

# CLI flag — comma-separated "cron_expr=task" pairs
garudust-server --cron-jobs "0 0 9 * * *=Write morning briefing,0 0 18 * * 5=Weekly summary"

# Or via environment variable in ~/.garudust/.env
GARUDUST_CRON_JOBS="0 0 9 * * *=Write morning briefing"

These take precedence over config.yaml when both are set.

3. Runtime via chat — No restart needed

Once the server is running, you (or any admin) can create jobs live by asking the agent:

You:   Create a cron job that runs every day at 7am to check disk usage
       and send me an alert if any partition is above 80%.

Agent: [uses cron_create tool]
       Created cron job 'disk_check' with schedule: 0 0 7 * * *

Note: cron_create uses 6-field cron syntax (seconds first): sec min hour dom month dow
Same format as config.yaml.

Format	Where used	Example
6-field	everywhere (`config.yaml`, `--cron-jobs`, env var, `cron_create`)	`0 0 9 * * 1-5`

Runtime jobs are not persisted — they disappear on server restart. Add them to config.yaml for permanent schedules.

Manage runtime jobs:

You:   List all active cron jobs.
Agent: - [disk_check]  schedule: 0 0 7 * * *  task: Check disk usage...  created: 2025-05-21 07:00 UTC

You:   Delete the disk_check job.
Agent: Cron job 'disk_check' removed.

Memory Maintenance (Bonus)

CronConfig has two extra fields specifically for automatic memory housekeeping:

cron:
  jobs:
    - schedule: "0 0 9 * * *"
      task: "Morning briefing"

  # Consolidate and deduplicate memory entries
  memory_consolidation: "0 0 3 * * *"   # daily at 03:00

  # Expire stale memory entries (based on memory_expiry settings)
  memory_expiry: "0 0 4 * * 0"          # weekly on Sunday at 04:00

These run lightweight maintenance tasks — no LLM call required.

Practical Examples

Morning Briefing

cron:
  jobs:
    - schedule: "0 0 8 * * 1-5"
      task: >
        Write a morning briefing covering: (1) any new files in ~/inbox/,
        (2) a summary of yesterday's ~/logs/app.log errors,
        (3) today's date and day of week.
        Save the result to ~/briefing/$(date +%Y-%m-%d).md.

Log Monitoring

cron:
  jobs:
    - schedule: "0 */15 * * * *"   # every 15 minutes
      task: >
        Check /var/log/app/error.log for entries in the last 15 minutes.
        If there are more than 10 errors, append a summary to ~/alerts/errors.log.

Weekly Git Summary

cron:
  jobs:
    - schedule: "0 0 17 * * 5"   # Fridays at 17:00
      task: >
        Run git log --since="1 week ago" --oneline in ~/project/,
        summarise what changed by area, and save to ~/reports/weekly.md.

Sending Results to Telegram

Cron jobs have no built-in delivery mechanism — the agent writes to files or uses tools. To send to Telegram, write it into the task prompt:

cron:
  jobs:
    - schedule: "0 0 9 * * *"
      task: >
        Write a morning briefing (top 3 priorities for today, weather summary).
        Then send it to Telegram chat ID 123456789 using the send_message tool.

The agent calls send_message itself. The chat ID must be hardcoded in the task or retrievable from a file the agent can read.

Disabling Cron Tools

If you want to prevent the agent from creating or deleting jobs at runtime, disable the toolset:

disabled_toolsets: [cron]

Config-file jobs still run — only the cron_create / cron_list / cron_delete runtime tools are disabled.

Summary

	`config.yaml`	`--cron-jobs` / env var	Runtime (`cron_create`)
Cron syntax	6-field	6-field	6-field
Persists across restarts	✅	❌	❌
Requires restart to activate	✅	✅	❌
`cron_list` shows it	❌	❌	✅

Start with config.yaml for anything you want running reliably. Use runtime jobs for experiments or tasks you only need for the current server session.

Garudust Agent — GitHub · Releases

Chat With Your Documents Using Garudust Agent — No Vector Database Required

Garudust — Thu, 21 May 2026 06:47:49 +0000

Most RAG tutorials start the same way: "First, install a vector database…" Then come the embedding models, the chunking strategies, the similarity thresholds. By the time you can ask a question about a PDF, you've deployed three services and written 200 lines of boilerplate.

Garudust Agent takes a different path. RAG is built in — backed by SQLite FTS5 with a trigram tokenizer. No vector database. No embedding API calls. Drop a PDF (or TXT, CSV, Markdown, JSON) into the conversation and start asking questions in seconds.

How It Works

When you ingest a document, Garudust:

Extracts text (native PDF parser, no external tools)
Splits it into chunks (≤ 800 chars, paragraph-aware)
Indexes chunks into an FTS5 virtual table with tokenize = 'trigram'

When you ask a question, doc_search runs a full-text query against the index and feeds the top matching chunks to the LLM as context. That's the whole pipeline — one SQLite file at ~/.garudust/state.db.

The trigram tokenizer means it works on any language, including Thai, Chinese, and Japanese, without any tokenizer configuration.

Setup

RAG is enabled by default. The only thing you need to configure is which directories the agent is allowed to read from:

# ~/.garudust/config.yaml
security:
  allowed_read_paths:
    - /home/you/documents
    - /data/company-docs

That's it. If you want to turn RAG off entirely:

disabled_toolsets: [rag]

Your First Ingestion

Start the CLI:

garudust

Then tell the agent to ingest a file:

You: ingest /home/you/documents/employee-handbook.pdf

Agent: Indexed employee-handbook.pdf — 47 chunks ready for search.
       Preview: "This handbook outlines the policies and procedures for all employees…"

Now ask anything:

You: What is the remote work policy?

Agent: According to the employee handbook, remote work is permitted up to 3 days per week
       for roles that do not require on-site presence. Employees must notify their manager
       at least 24 hours in advance and maintain availability during core hours (10am–4pm).

The Four RAG Tools

Tool	What it does
`doc_ingest`	Extract and index a file (PDF, TXT, CSV, MD, JSON…)
`doc_search`	Full-text search across all ingested documents
`doc_list`	List all indexed documents with chunk count and timestamp
`doc_forget`	Remove one file or clear the entire index

You never call these directly — the agent decides when to use them based on your question. But knowing they exist helps you understand what's happening.

Re-ingesting a file

If a document changes, just ingest it again. The old index for that path is replaced automatically.

Forgetting a document

You: Remove the Q1 report from the index.
Agent: Document removed from index.

Or clear everything:

You: Clear all indexed documents.
Agent: Removed 5 document(s) from index.

FTS5 Query Syntax

doc_search supports full FTS5 syntax, which the agent uses automatically when your question benefits from it:

Syntax	Example
AND (default)	`remote work policy`
Phrase	`"annual leave"`
OR	`vacation OR leave`
NOT	`policy NOT contractor`
Prefix	`terminat*`

You don't need to write FTS5 queries yourself — the agent figures this out. But if you want to guide it:

You: Search for "termination clause" in the contract documents.

Real-World Use Cases

1. Company Knowledge Base

Ingest your onboarding docs, SOPs, and internal wikis. New team members can ask questions in plain language instead of searching through Confluence.

You: ingest /docs/sop-release-process.md
You: What approvals are needed before a hotfix can go to production?

2. Contract and Legal Review

You: ingest /legal/vendor-agreement-2025.pdf
You: Does this contract include a limitation of liability clause? What is the cap?

3. Log Analysis

Ingest a log file and ask questions without writing grep patterns:

You: ingest /var/log/app/error.log
You: Which service caused the most errors in the last hour?
You: Are there any database connection timeouts?

4. Codebase Documentation

You: ingest /project/docs/api-reference.md
You: What parameters does the /auth/refresh endpoint accept?

Ingesting Files Sent via Telegram or LINE

If you're running garudust-server with a messaging platform, users can send files directly to the bot. Attachments are automatically saved to a temporary path and can be ingested on request:

User sends: quarterly-report.pdf (attached)

Agent: I received your file. Would you like me to index it for search?

User: yes

Agent: Indexed quarterly-report.pdf — 83 chunks ready.
       Preview: "Q1 2025 Financial Summary — Total Revenue: $4.2M…"

User: What was the gross margin for Q1?
Agent: According to the report, gross margin for Q1 2025 was 61.3%,
       up from 58.9% in Q4 2024.

Platform attachments (files from Telegram, LINE, Discord, etc.) are always allowed regardless of allowed_read_paths, since they're written to /tmp/garudust_* by the platform adapter.

Multiple Documents at Once

You can ingest multiple files and search across all of them in the same session:

You: ingest /docs/policy-2024.pdf
You: ingest /docs/policy-2025.pdf
You: What changed in the travel expense policy between 2024 and 2025?

The agent searches both documents and synthesizes the differences.

Check what's indexed at any time:

You: What documents have you indexed?

Agent: 2 documents indexed:
       - policy-2024.pdf | 34 chunks | ingested 2025-05-21 09:14
       - policy-2025.pdf | 38 chunks | ingested 2025-05-21 09:15

Limitations

No semantic search — FTS5 is keyword/trigram matching, not embedding similarity. If the document says "annual leave" and you ask about "vacation days," the agent bridges this with its language understanding, but results depend on the LLM's reasoning.
Session-scoped by default — The index persists in state.db, but searches are scoped to the current conversation key. Starting a new session means re-ingesting if you want to query the same files.
Text-only — Images, tables, and charts inside PDFs are not extracted. Text content only.

Summary

	Garudust RAG	Vector DB approach
Setup	One config line	Vector DB + embedding API
Storage	SQLite (single file)	Separate service
Languages	Any (trigram)	Depends on embedding model
Cost	Zero (no embedding calls)	Per-token embedding cost
Search type	FTS5 keyword + LLM reasoning	Semantic similarity

Garudust's RAG won't replace a purpose-built vector search pipeline for large-scale production retrieval. But for a developer who wants to ask questions about their documents right now — without running a second service — it's the fastest path from PDF to answer.

Garudust Agent — GitHub · Releases

ให้ AI พูดภาษาไทยได้ด้วย Garudust Agent + iApp TTS

Garudust — Tue, 19 May 2026 02:29:43 +0000

ถ้าคุณใช้ Garudust Agent อยู่แล้ว การเพิ่มความสามารถให้ AI พูดภาษาไทยออกมาเป็นเสียง ทำได้ในไม่กี่ขั้นตอน — ไม่ต้องแก้โค้ดใด ๆ เพราะ Garudust มีระบบ script tool ที่ pluggable อยู่แล้ว

TTS คืออะไร และทำไมต้อง iApp

TTS (Text-to-Speech) คือการแปลงข้อความเป็นเสียงพูด เหมาะกับ use case เช่น

ตอบกลับผู้ใช้ด้วยเสียงแทนข้อความบน LINE / Telegram
สร้างไฟล์เสียงสำหรับ podcast / narration อัตโนมัติ
Accessibility — ผู้ใช้ที่อ่านหน้าจอยาก

iApp Technology เป็นบริษัทไทยที่มี TTS API รองรับภาษาไทยโดยเฉพาะ เสียงฟังเป็นธรรมชาติ รองรับสูงสุด 10,000 ตัวอักษรต่อ request คิดค่าใช้จ่าย 1 IC ต่อ 400 ตัวอักษร สมัครได้ที่ iapp.co.th

ขั้นตอนที่ 1 — ติดตั้ง tts tool จาก Hub

Garudust มี Hub รวม script tool ให้ install ได้ทันที

garudust tool install tts

ระบบจะดึง tool.yaml และ run.py มาไว้ที่ ~/.garudust/tools/tts/ และ register ใน registry อัตโนมัติ

ขั้นตอนที่ 2 — เพิ่ม Provider Profile ใน config.yaml

Garudust ใช้ระบบ provider profile จัดการ API endpoint และ key — ไม่ต้อง hardcode ใน script

เปิด ~/.garudust/config.yaml แล้วเพิ่ม:

providers:
  # ... providers ที่มีอยู่แล้ว ...
  tts-iapp:
    url: https://api.iapp.co.th/v3/store/audio/tts
    key: ${IAPP_API_KEY}

tools:
  tts:
    model: tts-iapp   # ชี้ไปที่ profile ข้างบน

Garudust จะ inject GARUDUST_BASE_URL และ GARUDUST_API_KEY เข้า script อัตโนมัติตอน runtime

ขั้นตอนที่ 3 — เพิ่ม API Key ใน .env

# ~/.garudust/.env
IAPP_API_KEY=iapp_live_xxxxxxxxxxxxxxxx

รับ key ได้จาก iapp.co.th/dashboard

ทดสอบผ่าน CLI

garudust "ใช้ tts tool แปลงข้อความว่า สวัสดีครับ ผมคือ Garudust ผู้ช่วย AI ของคุณ แล้วบอก path ไฟล์ที่ได้"

ผลลัพธ์:

สร้างไฟล์เสียงสำเร็จ
เสียงอยู่ที่: /tmp/tts_88b5bba372dd41a7acc7e37ea75df89b.wav

เปิดฟัง:

open /tmp/tts_88b5bba372dd41a7acc7e37ea75df89b.wav

เบื้องหลัง — run.py ทำงานยังไง

iApp TTS API คืน raw PCM มาโดยไม่มี WAV header ดังนั้น run.py จัดการ wrap header ให้เอง:

def pcm_to_wav(pcm: bytes, sample_rate: int = 24000, channels: int = 1, bits: int = 16) -> bytes:
    byte_rate   = sample_rate * channels * bits // 8
    block_align = channels * bits // 8
    data_size   = len(pcm)
    header = struct.pack(
        "<4sI4s4sIHHIIHH4sI",
        b"RIFF", 36 + data_size, b"WAVE",
        b"fmt ", 16,
        1, channels, sample_rate, byte_rate, block_align, bits,
        b"data", data_size,
    )
    return header + pcm

ผลที่ได้คือ RIFF WAV 16-bit mono 24kHz — เปิดได้กับทุก audio player

เปลี่ยน Provider ได้ทันทีโดยไม่แตะโค้ด

นี่คือจุดแข็งของ Garudust provider profile — ถ้าอยากลอง provider อื่นเช่น AIS หรือ local model แค่เพิ่ม profile และเปลี่ยน tools.tts.model บรรทัดเดียว:

providers:
  tts-ais:
    url: https://your-ais-tts-endpoint/api/tts
    key: ${AIS_TTS_API_KEY}

tools:
  tts:
    model: tts-ais   # เปลี่ยนแค่นี้

run.py ไม่ต้องแตะเลย เพราะอ่าน GARUDUST_BASE_URL และ GARUDUST_API_KEY จาก profile เสมอ

ขั้นต่อไปที่ทำได้

LINE voice message — เพิ่ม OutboundMessage::Audio ใน Garudust core แล้วส่งไฟล์ WAV เป็น voice message บน LINE ได้เลย
Auto TTS reply — สั่งให้ agent เรียก tts ทุกครั้งที่ตอบ โดย inject ใน system prompt
Speaker selection — iApp มีหลายเสียง ตั้ง TTS_SPEAKER_ID ใน .env เพื่อเลือกเสียงที่ชอบ

สรุป

ขั้นตอน	คำสั่ง
ติดตั้ง tool	`garudust tool install tts`
เพิ่ม profile	แก้ `config.yaml`
เพิ่ม key	แก้ `~/.garudust/.env`
ใช้งาน	สั่ง agent พูดภาษาไทย

Garudust Agent เป็น open source ที่ github.com/garudust-org/garudust-agent — ติดตามหรือ contribute ได้เลย 🦅

10 Things You Can Do With Logs Using Garudust Agent 🦅

Garudust — Mon, 18 May 2026 08:11:41 +0000

10 Things You Can Do With Logs Using Garudust Agent 🦅

Most developers treat logs the same way: something breaks, you grep for errors, squint at timestamps, and piece together what happened. That's table stakes.

Garudust Agent is a self-hostable AI agent runtime written in Rust. Pair it with the log-analyst skill from garudust-hub, and your logs become something you can talk to — and that can act on your behalf.

Here are 10 things you can do that go well beyond grepping for ERROR.

Setup in 60 Seconds

# Install
wget -qO- https://github.com/garudust-org/garudust-agent/releases/latest/download/garudust-$(uname -m)-unknown-linux-musl.tar.gz | tar -xz
sudo mv garudust garudust-server /usr/local/bin/

# Configure (picks your LLM provider)
garudust setup

# Install the log skill
garudust skill install log-analyst

Local GPU? Skip the API entirely:

export VLLM_BASE_URL=http://localhost:8000/v1
export GARUDUST_MODEL=Qwen/Qwen3-8B-AWQ

1. 🕵️ Explain Why an Incident Happened

grep finds what. Garudust explains why.

garudust "read /var/log/app.log around 2025-05-14 03:22:00 ±10 minutes.
Reconstruct the chain of events that led to the service crash.
What was the root cause?"

The agent reads the surrounding context — not just the error line — and builds a timeline:

Timeline reconstruction:
  03:14:22 — Memory usage crossed 80% threshold (first warning)
  03:19:05 — DB connection pool exhausted (upstream pressure)
  03:21:58 — Request queue backed up, workers stalled
  03:22:11 — OOM killer terminated process (root cause)

Root cause: sustained traffic spike + connection pool too small for load
Recommendation: increase pool size from 10 → 25, add circuit breaker

2. 📊 Generate a Weekly Incident Report

Stop writing incident summaries by hand.

garudust "read /var/log/app.log for the past 7 days.
Generate a weekly incident report with:
- Total error count by day
- Top 5 recurring error types
- Mean time between incidents
- Any worsening trends
Format as Markdown."

Pipe it to a file, commit it, send it to Slack — whatever fits your workflow:

garudust "weekly incident report from /var/log/app.log" > reports/week-$(date +%V).md

3. 🔁 Detect Crash Loops Before They Become Outages

A service that restarts every 4 minutes isn't down — your uptime monitor won't catch it. But Garudust will.

garudust "scan /var/log/syslog for the last 2 hours.
Detect any process that has started and stopped more than 3 times.
Flag it as a crash loop candidate with restart intervals."

⚠️  CRASH LOOP DETECTED: api-worker
    Restarts in last 2h: 7
    Average interval: 16 minutes
    Last restart: 10 minutes ago
    Pattern: always crashes ~2 min after start (initialization failure likely)

4. 🌡️ Baseline "Normal" and Alert on Deviations

What if you don't know what an anomaly looks like — only that something feels off?

garudust "compare /var/log/nginx/access.log from last Monday vs this Monday,
same time window 09:00–12:00.
What's statistically different? Flag anything that deviates by more than 2x."

Garudust doesn't need pre-defined rules. It compares distributions and reasons about what changed:

Deviations vs. last Monday baseline:
  • 4xx error rate: 0.3% → 4.1%  (13.7x increase) ⚠️
  • Avg response time: 120ms → 380ms  (3.2x increase) ⚠️
  • /api/search endpoint: 2% → 31% of traffic  (unusual spike)

Hypothesis: new client or bot hitting /api/search aggressively

5. 🔒 Audit Security Events

Spot brute force attempts, suspicious IPs, and unusual access patterns.

garudust "analyze /var/log/auth.log from the last 24 hours.
Find:
- Failed login attempts > 5 from the same IP
- Successful logins from IPs with prior failures
- Any logins at unusual hours (outside 08:00–20:00 local time)
- New user accounts created
Summarize as a security audit."

🔴 Brute Force Attempt:
   IP: 185.234.xx.xx — 847 failed SSH attempts in 3 hours
   ⚠️  This IP succeeded once at 03:41 — INVESTIGATE IMMEDIATELY

🟡 Off-hours Logins:
   user: deploy  — login at 02:14 from 10.0.1.55 (internal, but unusual)

6. 📈 Build a Performance Degradation Timeline

Know exactly when things started slowing down — not just that they're slow now.

garudust "read /var/log/app.log for the past 30 days.
Plot response time trends by week.
Identify the exact date when p95 latency started increasing.
What changed around that time in the logs?"

This is invaluable for debugging regressions that crept in silently over weeks.

7. 🤖 Auto-Remediate Known Issues

Garudust has a terminal tool. Combine log analysis with action.

garudust "check /var/log/app.log — if you see more than 20 'disk quota exceeded'
errors in the last hour, run: find /tmp -mtime +1 -delete
then report how many files were removed and current disk usage."

Or for a service restart:

garudust "monitor /var/log/api.log — if the error rate exceeds 15% over 5 minutes,
run: sudo systemctl restart api-service
and report what you did and why."

Note: Garudust's GARUDUST_APPROVAL_MODE defaults to smart — it will ask before running destructive commands. Set to auto only in controlled environments.

8. 🔍 Trace a Single Request Across Services

Distributed systems scatter a single user request across multiple log files. Garudust can stitch them back together.

garudust "find all log entries related to request_id=a3f9c2b1 across these files:
/var/log/gateway.log
/var/log/auth-service.log
/var/log/api.log
/var/log/db-proxy.log
Build a complete trace timeline with latency at each hop."

Request trace: a3f9c2b1
  00ms  gateway.log      — request received, routed to auth
  12ms  auth-service.log — token validated
  13ms  api.log          — handler invoked
  891ms api.log          — ⚠️ waiting on DB (unusually long)
  903ms db-proxy.log     — query executed (full table scan detected)
  905ms gateway.log      — response returned  total: 905ms

9. 📝 Generate a `CHANGELOG` from Deploy Logs

If your deploy pipeline writes structured logs, you can generate changelogs automatically.

garudust "read /var/log/deploy.log for this month.
Extract all deployments: service name, version, timestamp, who deployed.
Format as a CHANGELOG grouped by week, in Keep a Changelog style."

## [Week 20] — 2025-05-12 to 2025-05-18

### Deployed
- **api-service** v2.4.1 — 2025-05-14 10:32 (alice)
- **worker** v1.9.0 — 2025-05-16 14:15 (bob)
- **gateway** v3.1.2 — 2025-05-17 09:00 (alice)

10. ⏰ Schedule All of the Above

Everything above can run automatically on a cron schedule — no extra infrastructure needed.

TELEGRAM_TOKEN=your_token \
GARUDUST_CRON_JOBS="
0 9 * * 1=Read /var/log/app.log last 7 days, generate weekly incident report, send to telegram;
*/15 * * * *=Check /var/log/app.log last 15 minutes for crash loops or error spikes, alert telegram if found;
0 8 * * *=Audit /var/log/auth.log last 24 hours for security anomalies, send daily security digest to telegram
" \
garudust-server --anthropic-key sk-ant-...

Three jobs. Zero extra services. No Prometheus, no Grafana, no ELK cluster.

The Mental Model Shift

Traditional log tooling asks you to define rules upfront:

"Alert me when error rate > 5%"

Garudust lets you ask questions in plain language — after something happens, or proactively via cron — and get reasoning, not just matching:

"What went wrong this week, and is it getting worse?"

The difference is the jump from pattern matching to understanding.

What's Next

Install the log-analyst skill and try #1 on your own logs right now
Write a custom SKILL.md for your specific log format in ~/.garudust/skills/
Contribute your own log tools to garudust-hub

🔗 Links:

GitHub: garudust-org/garudust-agent
Hub: garudust-org/garudust-hub
🇹🇭 Thai version: (link after publishing)

Which of these 10 use cases would save you the most time? Drop a comment — I read every one. 🙌

ตรวจจับ Log Anomaly อัตโนมัติด้วย Garudust Agent 🦅

Garudust — Mon, 18 May 2026 07:19:00 +0000

ตรวจจับ Log Anomaly อัตโนมัติด้วย Garudust Agent 🦅

ถ้าคุณเคยนั่งไล่ดู log ไฟล์ที่ยาวหลายหมื่นบรรทัดเพื่อหาว่า "มันพังตรงไหน" — บทความนี้เขียนมาเพื่อคุณโดยเฉพาะ

Garudust Agent คือ AI agent runtime ที่เขียนด้วย Rust รองรับการ self-host บน hardware ของคุณเอง และมี skill ชื่อ log-analyst ใน garudust-hub ที่ถูกออกแบบมาสำหรับงานนี้โดยตรง

🤔 ปัญหาจริงที่นักพัฒนาเจอ

ระบบ production ทุกระบบมี log แต่การไล่อ่าน log ด้วยมือมีปัญหาหลายอย่าง:

ปริมาณมหาศาล — log หลักล้านบรรทัดต่อวัน ไม่มีใครอ่านได้หมด
Pattern ซับซ้อน — error เดียวกันอาจโผล่ในหลาย format
เจอช้า — กว่าจะรู้ว่าพัง ผู้ใช้แจ้งมาก่อนแล้ว
Context ขาด — รู้ว่า error ตรงไหน แต่ไม่รู้ว่า "ก่อนหน้านั้นมีอะไรเกิดขึ้น"

Garudust แก้ปัญหาเหล่านี้ด้วยการให้ LLM อ่านและวิเคราะห์ log แทนคุณ — แบบ real-time หรือ scheduled ก็ได้

🛠️ ติดตั้ง Garudust

วิธีที่ 1 — ใช้ Pre-built Binary (แนะนำ)

# Linux x86_64
wget https://github.com/garudust-org/garudust-agent/releases/latest/download/garudust-*-x86_64-unknown-linux-musl.tar.gz
tar -xzf garudust-*.tar.gz
sudo mv garudust garudust-server /usr/local/bin/

วิธีที่ 2 — Build จาก Source (ต้องมี Rust 1.75+)

git clone https://github.com/garudust-org/garudust-agent
cd garudust-agent
cargo build --release
export PATH="$PATH:$(pwd)/target/release"

ตั้งค่าเริ่มต้น

garudust setup

Wizard จะถามว่าใช้ LLM provider ไหน รองรับทั้ง Anthropic, OpenRouter, vLLM (local), Ollama และ AWS Bedrock

สำหรับคนที่มี GPU และ self-host: ใช้ vLLM กับ model เช่น Qwen3-8B ได้เลยโดยไม่เสียค่า API
export VLLM_BASE_URL=http://localhost:8000/v1
export GARUDUST_MODEL=Qwen/Qwen3-8B-AWQ

📦 ติดตั้ง `log-analyst` Skill

Skill คือ instruction set แบบ Markdown ที่บอก agent ว่าต้องทำอะไร เมื่อไหร่ อย่างไร

garudust skill install log-analyst

แค่นี้พอ — ครั้งถัดไปที่คุณพูดถึง log, agent จะโหลด skill นี้มาใช้อัตโนมัติ

🔍 ใช้งานจริง: วิเคราะห์ Log ทันที

กรณีที่ 1 — วิเคราะห์ syslog

garudust "วิเคราะห์ /var/log/syslog 500 บรรทัดล่าสุด หา error pattern ที่ผิดปกติ"

ตัวอย่าง output ที่ได้:

🔍 Log Analysis Report — /var/log/syslog
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

⚠️  ANOMALY DETECTED: Connection timeout spike
    → 47 occurrences ใน 3 นาที (ปกติ < 2/ชั่วโมง)
    → First seen: 14:32:01, Last: 14:35:18
    → Probable cause: Network interface congestion หรือ upstream service down

❌ ERROR Pattern: OOM Killer activated
    → Process: python3 (PID 18423)
    → Memory usage: 7.8GB / 8GB
    → Recommendation: เพิ่ม swap หรือ review memory leak ใน process

✅ ไม่พบ segfault, kernel panic หรือ disk I/O error

กรณีที่ 2 — วิเคราะห์ Application Log

garudust "อ่าน /opt/myapp/logs/app.log แล้วหา:
- Error rate ต่อนาที
- Request ที่ใช้เวลา > 5 วินาที  
- Pattern ที่น่าสงสัย
สรุปเป็นภาษาไทย"

กรณีที่ 3 — เปรียบเทียบ Log สองช่วงเวลา

garudust "เปรียบเทียบ /var/log/nginx/access.log ระหว่าง 10:00-11:00 กับ 14:00-15:00 
ว่า error rate ต่างกันไหม และ traffic pattern เปลี่ยนแปลงอย่างไร"

⏰ Cron: ตรวจ Log อัตโนมัติ ทุก 30 นาที

นี่คือจุดที่ทำให้ Garudust ต่างจากการรัน script ธรรมดา — agent สามารถ ตัดสินใจเองได้ ว่าสิ่งที่เจอนั้น "ผิดปกติ" หรือเปล่า

GARUDUST_CRON_JOBS="*/30 * * * *=Read /var/log/app.log last 300 lines, detect ERROR or WARNING anomalies, if severity is HIGH report summary with timestamp and probable cause" \
garudust-server --anthropic-key sk-ant-...

แจ้งเตือนผ่าน Telegram อัตโนมัติ

TELEGRAM_TOKEN=your_bot_token \
GARUDUST_CRON_JOBS="*/15 * * * *=Check /var/log/app.log for critical errors in last 15 minutes. If error rate exceeds 10 per minute, send alert to telegram with details" \
garudust-server --anthropic-key sk-ant-...

Agent จะส่ง message ไปยัง Telegram bot ของคุณเองอัตโนมัติเมื่อเจอ anomaly

🏭 Use Case จริง: ระบบ Industrial / Edge AI

สำหรับงาน IoT หรือ Edge AI ที่มี log จากเซนเซอร์หรือกล้องวงจรปิด สามารถทำแบบนี้ได้:

# ตรวจสอบ log จากระบบ OCR กล้อง factory ทุก 1 ชั่วโมง
GARUDUST_CRON_JOBS="0 * * * *=Analyze /opt/vision/logs/ocr_results.log, find rows where confidence_score < 0.6 or recognition_failed = true, count anomaly rate, if > 5% in last hour generate incident report" \
VLLM_BASE_URL=http://localhost:8000/v1 \
GARUDUST_MODEL=Qwen3-8B-AWQ \
garudust-server

ข้อดีคือรันบน local GPU ได้เลย ไม่ต้องส่ง log ออกไปยัง cloud เหมาะมากสำหรับระบบ industrial ที่ข้อมูลเป็น confidential

✏️ เขียน Skill เองสำหรับ Log Format เฉพาะทาง

ถ้า log ของคุณมี format แปลก หรืออยากให้ agent วิเคราะห์แบบเฉพาะเจาะจง เขียน SKILL.md เองได้ใน ~/.garudust/skills/:

---
name: factory-log-analyst
description: Analyze industrial machine log from SMARTSense IDA system
version: 1.0.0
---

เมื่อถูกขอให้วิเคราะห์ log จากระบบ IDA ให้ทำตามนี้:

1. อ่าน log file ด้วย terminal tool
2. หา pattern เหล่านี้ที่บ่งบอกปัญหา:
   - confidence_score < 0.5 (OCR accuracy ต่ำผิดปกติ)
   - frame_drop_rate > 0.1 (กล้องส่งภาพไม่ครบ)
   - roi_timeout (พื้นที่ตรวจสอบไม่ response)
   - connection_lost (กล้องหลุด)
3. คำนวณ:
   - Anomaly rate ต่อชั่วโมง
   - ROI ที่มีปัญหาบ่อยที่สุด
4. สรุปเป็นภาษาไทย ระบุ:
   - ความรุนแรง (Critical / Warning / Info)
   - เวลาที่เกิด
   - สาเหตุที่น่าจะเป็น
   - คำแนะนำในการแก้ไข

🔧 Tool เพิ่มเติมจาก garudust-hub

นอกจาก log-analyst skill แล้ว ยังมี tools ใน hub ที่ช่วยงาน log ได้:

# ติดตั้ง tools ที่มีประโยชน์
garudust tool install csv_to_json    # แปลง log CSV → JSON
garudust tool install file_info      # เช็ค size/encoding ก่อนอ่าน
garudust tool install token_count    # เช็คว่า log ยาวเกิน context ไหม
garudust tool install extract_urls   # ดึง URL จาก access log

ใช้คู่กันในคำสั่งเดียว:

garudust "ใช้ file_info ดูขนาดของ /var/log/nginx/error.log ก่อน แล้วถ้าไม่เกิน 100KB ให้วิเคราะห์หา anomaly ทั้งหมดที่เกิดขึ้นวันนี้"

📊 เปรียบเทียบ: Garudust vs วิธีเดิม

	Script ธรรมดา (grep/awk)	ELK Stack	Garudust
ติดตั้ง	ง่าย	ซับซ้อน	ง่าย (binary เดียว)
Resource	ต่ำ	สูงมาก (ต้องการ RAM หลาย GB)	ต่ำ (~10MB binary)
วิเคราะห์ context	❌	❌	✅ (LLM เข้าใจ context)
แจ้งเตือนอัตโนมัติ	ต้องเขียนเอง	✅	✅ built-in
Self-host	✅	✅	✅
ภาษาไทย	❌	❌	✅
สรุปสาเหตุ	❌	❌	✅

🚀 เริ่มต้น 5 นาที

# 1. ติดตั้ง
wget -qO- https://github.com/garudust-org/garudust-agent/releases/latest/download/garudust-$(uname -m)-unknown-linux-musl.tar.gz | tar -xz
sudo mv garudust /usr/local/bin/

# 2. ตั้งค่า
garudust setup

# 3. ติดตั้ง skill
garudust skill install log-analyst

# 4. ลองเลย!
garudust "วิเคราะห์ /var/log/syslog 100 บรรทัดล่าสุด หา error ที่น่าสงสัย"

สรุป

Garudust ไม่ใช่แค่ tool อ่าน log — มันคือ agent ที่เข้าใจ context ของ log และช่วยตัดสินใจว่าอะไรคือ "ปกติ" หรือ "ผิดปกติ" โดยใช้ความสามารถของ LLM

จุดแข็งที่สำคัญสำหรับ DevOps และ Industrial Engineer คือ:

Self-host ได้ 100% — ไม่ต้องส่ง log ออก cloud
รองรับ local LLM — ใช้ vLLM + Qwen/LLaMA บน GPU ของตัวเองได้
ภาษาไทยได้เลย — detect ภาษาอัตโนมัติ ไม่ต้องตั้งค่า
Cron built-in — ตั้งตรวจอัตโนมัติได้ทันที

🔗 Links:

GitHub: garudust-org/garudust-agent
Hub: garudust-org/garudust-hub
Facebook Community: Garudust Agent Thailand

มีคำถามหรืออยากแลกเปลี่ยนประสบการณ์ใช้ Garudust? comment ได้เลยครับ 🙌

Build a Self-Improving AI Agent in Rust with Garudust — Daily Briefing Bot in 10 Minutes

Garudust — Sun, 17 May 2026 06:55:29 +0000

Most AI agent frameworks feel like they were designed for Python developers who love ceremony. You write adapters, glue code, orchestrators, memory stores — and by the time your agent actually does something useful, you've got a monorepo and a headache.

Garudust Agent takes a different approach: a single ~10 MB statically-linked Rust binary that gives you persistent memory, cron scheduling, multi-platform gateways (Telegram, Discord, Slack, Matrix), and MCP tool support — out of the box, no runtime dependencies.

In this article I'll show you how to build a Telegram Daily Briefing Bot that:

Wakes up every morning at 9 AM and sends you a personalised briefing
Remembers your preferences across sessions (no repeating yourself)
Reads files from your server and summarises them
Uses a custom Skill to keep its briefing format consistent

By the end you'll understand the core Garudust concepts well enough to build your own agents.

Why Garudust?

Before diving in, here's what sets it apart from other agent runtimes:

Feature	Garudust	LangChain/LangGraph	AutoGen
Language	Rust	Python	Python
Binary size	~10 MB	N/A (pip install)	N/A (pip install)
Cold start	< 20 ms	1–5 s	1–5 s
Persistent memory	Built-in	Plugin needed	Plugin needed
Platform adapters	Built-in	Plugin needed	Plugin needed
Self-hosted	Yes, trivially	Needs extra infra	Needs extra infra

The self-improvement angle is genuinely interesting: the agent notices when it keeps doing something wrong and patches its own Skill files. We'll see that in action below.

Prerequisites

A Linux server or Mac (the binary is statically linked — no Rust required to run it)
An API key for any LLM provider: Anthropic, OpenRouter, Ollama, vLLM, etc.
A Telegram bot token (free — create one via @BotFather)

Step 1 — Install Garudust

Download the pre-built binary from GitHub Releases.

# Linux x86_64
curl -LO https://github.com/garudust-org/garudust-agent/releases/latest/download/garudust-x86_64-unknown-linux-musl.tar.gz
tar -xzf garudust-*.tar.gz
sudo mv garudust garudust-server /usr/local/bin/

# Verify
garudust --version

For macOS (Apple Silicon):

curl -LO https://github.com/garudust-org/garudust-agent/releases/latest/download/garudust-aarch64-apple-darwin.tar.gz
tar -xzf garudust-*.tar.gz
sudo mv garudust garudust-server /usr/local/bin/

Or build from source if you have Rust 1.75+:

git clone https://github.com/garudust-org/garudust-agent
cd garudust-agent
cargo build --release
export PATH="$PATH:$(pwd)/target/release"

Step 2 — Configure Your LLM Provider

Run the setup wizard:

garudust setup

This walks you through picking a provider and saving your key. Under the hood it writes to ~/.garudust/config.yaml.

You can also set environment variables directly:

# Anthropic
export ANTHROPIC_API_KEY="sk-ant-..."

# OpenRouter (gives you access to 200+ models)
export OPENROUTER_API_KEY="sk-or-..."

# Self-hosted vLLM (like the Qwen3-8B-AWQ setup I run locally)
export VLLM_BASE_URL="http://localhost:8000/v1"
export GARUDUST_MODEL="Qwen/Qwen3-8B-AWQ"

# Ollama (fully local, no key needed)
export OLLAMA_BASE_URL="http://localhost:11434"
export GARUDUST_MODEL="llama3.2"

Let's verify everything is working:

garudust doctor

You should see all green checkmarks. Now try a quick chat:

garudust "hello, what can you do?"

Step 3 — Create a Telegram Bot

Open Telegram and message @BotFather
Send /newbot and follow the prompts
Copy your bot token (looks like 7123456789:AAHxxx...)

Set it in your environment:

export TELEGRAM_TOKEN="7123456789:AAHxxx..."

Step 4 — Create a Briefing Skill

This is where Garudust gets interesting. Skills are Markdown files that the agent automatically loads when relevant. They live in ~/.garudust/skills/ and are hot-reloaded on every call — no restarts needed.

Create the directory and your first skill:

mkdir -p ~/.garudust/skills/daily-briefing

Now create ~/.garudust/skills/daily-briefing/SKILL.md:

---
name: daily-briefing
description: Instructions for generating a personalised morning briefing via Telegram
version: 1.0.0
---

## Daily Briefing Format

When asked to generate a morning briefing, always follow this structure:

1. **Greeting** — Use the user's name and current local time
2. **Today's Focus** — 2–3 bullet points on what to prioritise (infer from memory or files)
3. **Quick Stats** — If any log files or data files are available in ~/briefing-data/, summarise key numbers
4. **Reminder** — One motivational sentence, varied each day, never generic

## Style Rules

- Keep the total message under 300 words
- Use Telegram-compatible formatting (bold with *, italic with _)
- Never use HTML tags
- If no data files are found, skip the Quick Stats section gracefully
- Always end with: "Have a great day, Garudian! 🦅"

That last line — "Have a great day, Garudian!" — is a nod to the Garudust contributor community name.

Step 5 — Set Up Cron Scheduling

Garudust's cron scheduler uses standard cron expressions. You configure it via the GARUDUST_CRON_JOBS environment variable:

export GARUDUST_CRON_JOBS="0 9 * * *=Generate a morning briefing using the daily-briefing skill and send it to me on Telegram"

The format is "cron_expression=natural language task". The agent handles the rest — it knows who "me" is from the user profile it builds over time.

You can also add multiple jobs separated by commas:

export GARUDUST_CRON_JOBS="0 9 * * *=Generate a morning briefing and send via Telegram,0 18 * * 5=Send a weekly summary of tasks completed this week"

Step 6 — Start the Server

Create a simple .env file to keep everything together:

# ~/.garudust/.env
ANTHROPIC_API_KEY=sk-ant-...
TELEGRAM_TOKEN=7123456789:AAHxxx...
GARUDUST_MODEL=anthropic/claude-sonnet-4-6
GARUDUST_CRON_JOBS="0 9 * * *=Generate a morning briefing using the daily-briefing skill and send it to me on Telegram"
GARUDUST_APPROVAL_MODE=auto
RUST_LOG=info

Now start the server:

# Load env and start
set -a; source ~/.garudust/.env; set +a
garudust-server --port 3000

Or with Docker (the docker-compose.yml in the repo is ready to use):

cp .env.example .env
# Edit .env with your keys
docker compose up -d

You should see logs like:

INFO garudust_server: Starting Garudust server on port 3000
INFO garudust_platforms::telegram: Telegram adapter connected
INFO garudust_cron: Scheduled job: "0 9 * * *" → Generate a morning briefing...

Step 7 — Teach the Agent About You

Open Telegram and message your bot. The first time, introduce yourself:

Hi! I'm Alex. I'm a backend developer working on Rust microservices.
I usually check logs in ~/briefing-data/app.log and ~/briefing-data/errors.log.
I prefer short, direct messages with no fluff.

The agent saves this to persistent memory automatically. You'll see something like:

Got it, Alex! I've saved your preferences:
- Name: Alex
- Role: Backend developer (Rust microservices)
- Briefing data path: ~/briefing-data/
- Communication style: short and direct

I'll use these tomorrow morning at 9 AM for your briefing.

This is the self-improvement loop: you teach it once, and it remembers forever. On the next session — or the next day's cron job — the context is already loaded.

What Happens at 9 AM

At 9 AM, the cron job fires. The agent:

Loads the daily-briefing Skill — sees the format rules
Reads persistent memory — knows your name, preferences, file paths
Calls read_file on ~/briefing-data/app.log and errors.log
Generates the briefing using the Skill's format
Sends it to you on Telegram

A real message might look like:

*Good morning, Alex!* It's 9:00 AM.

*Today's Focus*
• 3 errors in errors.log since yesterday — worth a look before standup
• PR #142 still open — you had this on your radar
• Dependency audit due this sprint

*Quick Stats (from app.log)*
• 14,203 requests last 24h
• p99 latency: 187 ms
• 3 ERRORs, 0 WARNings

_Have a great day, Garudian!_ 🦅

Step 8 — Test the HTTP API

You don't have to wait until 9 AM. The HTTP gateway is always running:

# Trigger a briefing right now
curl -X POST http://localhost:3000/chat \
  -H "Content-Type: application/json" \
  -d '{"message": "Generate my morning briefing now and send it to me on Telegram"}'

For streaming responses (great for long tasks):

curl -X POST http://localhost:3000/chat/stream \
  -H "Content-Type: application/json" \
  -d '{"message": "Summarise my error logs from the last 7 days"}'

Step 9 — Run as a systemd Service

For production use on a Linux server:

sudo nano /etc/systemd/system/garudust.service

[Unit]
Description=Garudust Agent Server
After=network.target

[Service]
Type=simple
User=youruser
WorkingDirectory=/home/youruser
EnvironmentFile=/home/youruser/.garudust/.env
ExecStart=/usr/local/bin/garudust-server --port 3000
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now garudust
sudo journalctl -u garudust -f

The Self-Improving Part

Here's something that makes Garudust distinct from a static chatbot: if the briefing format stops being useful, the agent fixes itself.

Suppose you message your bot:

The briefing is too long. Cut the Quick Stats section to just one line.

The agent updates ~/.garudust/skills/daily-briefing/SKILL.md immediately — while the server is running, without a restart. The next morning's briefing will already follow the updated format.

You can also ask it to create new skills on the fly:

Write a skill for when I ask you to review a Rust PR — check for unwraps, missing error handling, and doc comments.

It creates ~/.garudust/skills/rust-pr-review/SKILL.md automatically. From that point on, whenever you paste a PR and ask for a review, it loads that skill without being told.

Architecture at a Glance

Your Telegram ──► garudust-server
                       │
                  ┌────┴────────────────────┐
                  │   daily-briefing SKILL  │  ← hot-reloaded markdown
                  │   Persistent Memory     │  ← ~/.garudust/memory/
                  │   Session DB (FTS5)     │  ← SQLite full-text search
                  └────┬────────────────────┘
                       │
                  LLM Transport
          (Anthropic / OpenRouter / vLLM / Ollama)
                       │
                  Tool Registry
         (read_file, write_skill, memory, web_search…)

Every piece is a separate Rust crate. If you want to add a new platform or tool, you touch exactly one crate and typically write under 100 lines.

What to Build Next

Now that you have the basics, here are some natural extensions:

Add web search to the briefing
Set BRAVE_SEARCH_API_KEY and update your Skill to include: "Always search for the top 3 tech news headlines and include them under a 'News' section."

Multi-platform: Run Telegram + Slack simultaneously

export SLACK_BOT_TOKEN="xoxb-..."
export SLACK_APP_TOKEN="xapp-..."
# garudust-server handles both in the same process

Connect to your database via MCP
Add to ~/.garudust/config.yaml:

mcp_servers:
  - name: postgres
    command: npx
    args: ["-y", "@modelcontextprotocol/server-postgres", "postgresql://localhost/mydb"]

The briefing can now query your own database directly.

Delegate to sub-agents
For heavy tasks, use the delegate_task tool — it spawns parallel sub-agents that run concurrently and report back. Great for summarising large codebases or doing multi-step research.

Wrapping Up

Garudust isn't trying to be the most featureful agent framework — it's trying to be the most practical one. A single binary, sensible defaults, and just enough structure to let you build real things without ceremony.

The daily briefing bot we built today shows the core loop:

Install — one binary, no dependencies
Configure — env vars or YAML
Teach — talk to it, it remembers
Extend — write a Skill in Markdown

The project is actively developed and welcoming contributors. If you want to add a new platform adapter, a tool, or improve the TUI — check out the CONTRIBUTING.md and look for "good first issue" labels.

Star the repo, join the community, and become a Garudian 🦅

→ github.com/garudust-org/garudust-agent

Have questions or want to share what you built? Drop a comment below — I read everything.

สร้าง AI Agent บน LINE ด้วย Garudust (Rust) — ตั้งแต่ต้นจนใช้งานได้จริง

Garudust — Thu, 14 May 2026 05:06:47 +0000

ถ้าคุณอยากมี AI Agent ส่วนตัวที่คุยได้ผ่าน LINE โดยไม่ต้องพึ่ง no-code platform บทความนี้จะพาคุณทำตั้งแต่ต้นจนจบ เครื่องมือที่ใช้คือ Garudust — AI Agent framework เขียนด้วย Rust รองรับ OpenAI, Anthropic, Ollama, vLLM และ OpenAI-compatible endpoint ทุกเจ้า

สิ่งที่ต้องมี

เซิร์ฟเวอร์ Linux หรือ macOS (หรือรันบน VPS ก็ได้)
บัญชี LINE Developers (ฟรี) → developers.line.biz
API Key จาก OpenAI, Anthropic, หรือ endpoint อื่นๆ
ngrok — เฉพาะกรณีรันบนเครื่องตัวเองที่ไม่มี public IP

1. ติดตั้ง Garudust

วิธีที่ 1 — ดาวน์โหลด binary

ไปที่ Releases แล้วดาวน์โหลดไฟล์ที่ตรงกับระบบของคุณ:

# Linux x86_64
curl -LO https://github.com/garudust-org/garudust-agent/releases/latest/download/garudust-v0.3.1-x86_64-unknown-linux-musl.tar.gz
tar -xzf garudust-*.tar.gz
sudo mv garudust*/garudust garudust*/garudust-server /usr/local/bin/

วิธีที่ 2 — Build จาก source (ต้องมี Rust 1.87+)

git clone https://github.com/garudust-org/garudust-agent.git
cd garudust-agent
cargo build --release --bin garudust --bin garudust-server
sudo cp target/release/garudust target/release/garudust-server /usr/local/bin/

ตรวจสอบว่าติดตั้งสำเร็จ:

garudust --version
garudust-server --version

2. ตั้งค่า LINE Messaging API

เข้าไปที่ LINE Developers Console
สร้าง Provider ใหม่ (หรือใช้อันที่มีอยู่)
สร้าง Channel ประเภท Messaging API
ที่ tab Basic settings → คัดลอก Channel secret
ที่ tab Messaging API → คลิก Issue เพื่อสร้าง Channel access token (long-lived)
เปิด Use webhook → toggle เป็น Enable

เก็บค่าสองอย่างนี้ไว้:

LINE_CHANNEL_SECRET=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
LINE_CHANNEL_TOKEN=eyJhbGci...

3. ตั้งค่าไฟล์ config

Garudust แยก secret ออกจาก config เป็น 2 ไฟล์:

~/.garudust/.env — credentials เท่านั้น (ห้าม commit)
~/.garudust/config.yaml — ตั้งค่าพฤติกรรม, platform, port (แชร์ได้)

`~/.garudust/.env`

# LLM provider
ANTHROPIC_API_KEY=sk-ant-...

# LINE adapter — tokens ต้องอยู่ใน .env เสมอ
LINE_CHANNEL_SECRET=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
LINE_CHANNEL_TOKEN=eyJhbGci...

`~/.garudust/config.yaml`

provider: anthropic
model: claude-sonnet-4-6

system_prompt: |
  คุณคือผู้ช่วย AI ชื่อ "น้องการุด" พูดภาษาไทย ตอบสั้นกระชับ
  ช่วยงานด้านข้อมูล วิเคราะห์ข้อความ และตอบคำถามทั่วไป
  ไม่ตอบเนื้อหาที่ไม่เหมาะสม

platforms:
  line:
    enabled: true
    port: 3002
    webhook_path: /line      # webhook URL: https://your-host/line

หลักการ: config.yaml เก็บโครงสร้าง (enabled, port, webhook_path) ส่วน .env เก็บ secret (LINE_CHANNEL_SECRET, LINE_CHANNEL_TOKEN) เท่านั้น

เมื่อรัน garudust-server แล้ว Garudust จะเปิด HTTP server รอรับ webhook จาก LINE ที่ 0.0.0.0:3002/line โดยอัตโนมัติ — ไม่ต้องตั้งค่า webhook server เพิ่มเอง

4. รัน garudust-server

garudust-server

ดู log จะเห็น:

INFO garudust_server: LINE webhook listening on 0.0.0.0:3002/line
INFO garudust_server: API server listening on 0.0.0.0:3000

Port mapping ของ Garudust:

Port	ใช้สำหรับ
`3000`	HTTP API หลัก (`/chat`, `/health`, `/metrics`)
`3001`	Generic webhook
`3002`	LINE adapter
`3003`	WhatsApp adapter

5. ตั้งค่า Webhook URL ใน LINE Developers Console

ขั้นตอนนี้แตกต่างกันตามสภาพแวดล้อม:

กรณี A — VPS หรือเซิร์ฟเวอร์ที่มี public IP (Production)

ไม่ต้องใช้ ngrok — LINE เข้าถึง server ของคุณได้ตรงๆ ผ่าน nginx

ตั้งค่า nginx reverse proxy ก่อน (ดูขั้นตอนที่ 7) แล้วใช้ URL:

https://yourdomain.com/line

กรณี B — เครื่องตัวเองที่ไม่มี public IP (Dev/ทดสอบ)

LINE ไม่สามารถเข้าถึง localhost ได้และต้องการ HTTPS — ใช้ ngrok สร้าง tunnel ชั่วคราว:

ngrok http 3002

ngrok จะแสดง URL เช่น:

Forwarding  https://abc123.ngrok-free.app -> http://localhost:3002

webhook URL ของคุณคือ:

https://abc123.ngrok-free.app/line

หมายเหตุ: ngrok free tier เปลี่ยน URL ทุกครั้งที่รีสตาร์ท เหมาะสำหรับทดสอบเท่านั้น ใช้ VPS หรือ ngrok paid plan สำหรับ production

ตั้ง webhook URL ใน LINE Developers Console:

Tab Messaging API → ส่วน Webhook settings
ใส่ URL ตามสภาพแวดล้อมของคุณ (จากด้านบน)
คลิก Verify — ควรได้ "Success"
เปิด Use webhook ให้เป็น Enable

ลองส่งข้อความหา LINE Official Account ของคุณ — AI จะตอบกลับทันที

6. เพิ่ม Cron Job (ทำงานอัตโนมัติ)

Garudust มีระบบ cron ในตัว ตั้งค่าใน .env:

# ส่ง briefing ทุกเช้า 8 โมง
GARUDUST_CRON_JOBS="0 8 * * *=สรุปข่าวเทคโนโลยีไทยวันนี้ บันทึกลงไฟล์ ~/briefing.md"

# รวบรวม memory อัตโนมัติทุกคืน 03:00
GARUDUST_MEMORY_CRON="0 3 * * *"

7. Deploy Production (systemd + nginx)

nginx reverse proxy

LINE ต้องการ HTTPS — nginx จัดการ SSL แล้ว proxy ต่อไปยัง Garudust บน port 3002:

# /etc/nginx/sites-available/garudust
server {
    listen 443 ssl;
    server_name yourdomain.com;

    ssl_certificate     /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

    # LINE webhook — proxy ไปที่ Garudust LINE adapter port 3002
    location /line {
        proxy_pass http://127.0.0.1:3002;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # HTTP API หลัก
    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
    }
}

sudo ln -s /etc/nginx/sites-available/garudust /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

systemd service

# /etc/systemd/system/garudust.service
[Unit]
Description=Garudust AI Agent Server
After=network.target

[Service]
Type=simple
User=ubuntu
ExecStart=/usr/local/bin/garudust-server
Restart=on-failure
RestartSec=5
EnvironmentFile=/home/ubuntu/.garudust/.env
WorkingDirectory=/home/ubuntu

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now garudust
sudo systemctl status garudust

webhook URL สำหรับตั้งใน LINE Console:

https://yourdomain.com/line

สรุป config ทั้งหมด

~/.garudust/.env — secrets เท่านั้น

ANTHROPIC_API_KEY=sk-ant-...
LINE_CHANNEL_SECRET=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
LINE_CHANNEL_TOKEN=eyJhbGci...
GARUDUST_MEMORY_CRON="0 3 * * *"

~/.garudust/config.yaml — พฤติกรรมและโครงสร้าง

provider: anthropic
model: claude-sonnet-4-6

system_prompt: |
  คุณคือผู้ช่วย AI ชื่อ "น้องการุด" พูดภาษาไทย ตอบสั้นกระชับ

platforms:
  line:
    enabled: true
    port: 3002
    webhook_path: /line

สรุปขั้นตอนตามสภาพแวดล้อม

	Dev (localhost)	Production (VPS)
Garudust รัน webhook ที่	`localhost:3002/line`	`localhost:3002/line`
เปิด HTTPS ด้วย	ngrok tunnel	nginx + Let's Encrypt
Webhook URL ใน LINE Console	`https://xxx.ngrok-free.app/line`	`https://yourdomain.com/line`
ngrok	✅ จำเป็น	❌ ไม่ต้อง

Garudust รองรับ OpenAI, Anthropic, Ollama, vLLM และ OpenAI-compatible endpoint ทุกเจ้า — เปลี่ยน provider ได้แค่แก้ 2 บรรทัดใน config.yaml แล้วรีสตาร์ท

GitHub: garudust-org/garudust-agent
Docs: garudust-org.github.io/garudust-agent

ถ้ามีคำถามหรือเจอปัญหา เปิด Issue บน GitHub ได้เลย หรือ comment ไว้ด้านล่างครับ

DEV Community: Garudust

ตรวจ CPU/Memory ทุกชั่วโมงด้วย Garudust Agent Cron ในตัว

สิ่งที่ต้องมี

1. ติดตั้ง Binary

2. ตั้ง Config

3. รัน Server

4. รัน Server แบบ Daemon ด้วย systemd

5. เช็ก Log

6. เพิ่ม Job แบบ Runtime ผ่าน API

7. ตั้ง Alert ผ่าน Telegram (ทางเลือก)

เปรียบเทียบกับ System Cron

สรุป config ทั้งหมด

Chat With Your Raspberry Pi — Control GPIO, Read Sensors, and Manage Services via Telegram Using Garudust

How It Works

Prerequisites

Step 1 — Set Up a Dedicated SSH Key

Step 2 — Configure Garudust

What You Can Now Do

Read Sensor Data

Control GPIO (Relay, LED, Motor)

Check System Health

Manage Services

Run Your Own Scripts

Automate With Cron

Security Notes

What's Next

SSH Remote Terminal ใน Garudust Agent — ให้ AI สั่งงานบน Server จริงได้เลย

ทำไมถึงมีประโยชน์?

Use Case 1 — Build & Deploy บน Remote Server

Use Case 2 — Ops Assistant จาก Telegram

Use Case 3 — ควบคุม Raspberry Pi ผ่าน LINE

Use Case 4 — Isolated Environment โดยไม่ใช้ Docker

Security ที่ได้มาโดยอัตโนมัติ

ลองได้เลย — ไม่ต้องมี server จริง

สรุป

Event Triggers บน Garudust

Webhook Adapter ทำงานอย่างไร

Security

Core Pattern

Use Cases

1. Billing Email Monitor

2. GitHub PR Review Gate

3. Database Anomaly Alert

4. Calendar External-Attendee Watch

5. Queue Worker Trigger

Session Keys และความต่อเนื่อง

สิ่งที่ Pattern นี้ยังไม่ครอบคลุม

Event Triggers on Garudust

How the Webhook Adapter Works

Security

The Core Pattern

Use Cases

1. Billing Email Monitor

2. GitHub PR Review Gate

3. Database Anomaly Alert

4. Calendar External-Attendee Watch

5. Queue Worker Trigger

Session Keys and Continuity

What This Pattern Does Not Cover

Cron & Scheduled Tasks in Garudust Agent — Autonomous Agents That Run Without You

How It Works

Three Ways to Set Up Cron Jobs

1. config.yaml — Permanent, survives restarts

2. CLI flag or environment variable — One-off / Docker

3. Runtime via chat — No restart needed

Memory Maintenance (Bonus)

Practical Examples

Morning Briefing

Log Monitoring

Weekly Git Summary

Sending Results to Telegram

Disabling Cron Tools

Summary

Chat With Your Documents Using Garudust Agent — No Vector Database Required

How It Works

Setup

Your First Ingestion

The Four RAG Tools

Re-ingesting a file

Forgetting a document

1. `config.yaml` — Permanent, survives restarts

9. 📝 Generate a `CHANGELOG` from Deploy Logs

📦 ติดตั้ง `log-analyst` Skill