Beszel: Monitoring Server Gratis & Ringan untuk Homelab

Pernah nggak kamu merasa lelah bolak-balik SSH ke setiap server cuma buat cek "sehat nggak ya mesin ini?" Saya pernah. Dan percaya, cara lama itu nggak hanya melelahkan—tapi juga berbahaya, karena masalah bisa muncul di menit-menit kamu nggak ngintip.

Beszel adalah alat monitoring server yang ringan, self-hosted, dan gratis. Dibangun pakai bahasa Go, ia bikin kamu bisa pantau CPU, memori, disk, jaringan, sampai statistik Docker container—semuanya dari satu dashboard web yang bersih dan cepat. Dengan arsitektur hub-and-agent yang sederhana, Beszel cocok buat homelab, usaha kecil, sampai tim yang butuh visibilitas infrastruktur tanpa ribet.

Dalam artikel ini, MUGHU mau ajak Teman-Teman menyelam pengalaman nyata pakai Beszel—dari latar belakang masalahnya, cara saya deploy, sampai hasil dan pelajaran yang saya tarik. Kita juga akan bandingkan Beszel sama alternatif populer seperti Prometheus+Grafana, Netdata, dan Zabbix biar kamu bisa pilih yang paling pas buat kebutuhanmu.

Latar Belakang: Kenapa Monitoring Server Itu Penting Banget

Jadi gini—saya punya beberapa server yang jalan di rumah dan juga VPS di cloud. Sebagian jalanin Docker container, sebagian lagi cuma bare metal. Masalahnya, saya nggak punya cara terpusat buat ngelihat kondisi semuanya sekaligus.

Setiap kali mau cek, saya harus SSH ke masing-masing mesin, jalankan htop atau df -h, lalu pindah ke mesin berikutnya. Bayangin kalau ada lima server—itu artinya lima kali SSH, lima kali cek manual, dan nol jaminan kamu ngeh kalau ada yang bermasalah di tengah malam.

Saya coba beberapa solusi yang sudah terkenal. Prometheus plus Grafana, misalnya—memang powerful, tapi setup-nya bikin kepala pusing. Harus konfigurasi node exporter, bikin dashboard dari nol, atur alerting pipeline, dan setelah semuanya jadi... dashboard-nya terasa kayak grafik seismik yang cuma saya sendiri yang ngerti. Netdata juga saya coba—bagus buat real-time, tapi kurang fokus soal manajemen agent terdistribusi.

Intinya, saya butuh sesuatu yang:

• Ringan (nggak boleh makan resource lebih banyak dari service yang dipantau)

• Mudah dipasang (bukan berhari-hari konfigurasi)

• Bisa pantau banyak server sekaligus dari satu tempat

• Punya alerting biar saya nggak harus ngintip terus-terusan

Terus saya ketemu Beszel di GitHub. Saat itu bintangnya udah 23 ribu lebih, dan setelah baca-baca dokumentasinya, saya pikir, "ini kayaknya yang saya cari."

Tantangan: Masalah yang Saya Hadapi Sebelum Beszel

Bolak-Balik SSH Itu Ngga Skalabel

Dulu, rutinitas saya tiap pagi adalah buka terminal, SSH ke server pertama, cek CPU dan memori, lalu ke server kedua, ketiga, dan seterusnya. Kalau ada tujuh server, itu tujuh sesi SSH. Capek? Iya. Efektif? Nggak sama sekali.

Yang bikin lebih serep, kadang saya lupa cek salah satu server. Terus dua hari kemudian, server itu kehabisan disk space dan service-nya mati. Kalau saja ada yang ngasih tahu lebih awal, masalahnya bisa dihindari.

Grafana + Prometheus Terlalu Berat Buat Kebutuhan Saya

Saya nggak nyalah Grafana dan Prometheus—alat itu memang hebat dan banyak dipakai di industri. Tapi buat kebutuhan saya, yang cuma mau tahu "CPU berapa persen? Disk penuh nggak? Container mana yang makan memori paling banyak?", kayaknya terlalu berlebihan.

Setup Prometheus butuh konfigurasi scrape config, retention policy, storage backend. Grafana butuh bikin panel satu per satu, atur datasource, query PromQL. Waktu saya selesai semuanya, udah makan setengah hari. Belum lagi resource yang dimakan—Grafana+Prometheus di Raspberry Pi? Lupa aja, bakal kewalahan.

Uptime Kuma Kurang Mendalam Soal Metrik Sistem

Uptime Kuma bagus banget buat cek "server hidup nggak?" lewat ping atau HTTP request. Tapi soal metrik sistem—CPU, memori, disk I/O, suhu, GPU—dia nggak ngasih. Saya butuh sesuatu yang lebih dalam dari sekadar ping, tapi lebih simpel dari Prometheus.

Netdata Kurang Fokus Soal Multi-Server

Netdata memang keren buat monitoring real-time di satu mesin. Tapi soal manajemen beberapa server dari satu dashboard, pengalamannya kurang mulus. Cloud Netdata ada, tapi itu berarti data saya lewat server pihak ketiga—dan saya lebih suka semuanya self-hosted.

Pendekatan: Kenapa Saya Pilih Beszel

Nah, setelah riset dan baca-baca, saya putuskan pakai Beszel. Alasannya cukup jelas:

Pertama, ringan banget. Beszel ditulis dalam Go, dan agent-nya cuma makan sekitar 8 MB RAM saat aktif. Hub-nya juga nggak jauh lebih besar. Saya baca pengalaman orang yang jalanin hub plus lima agent di VPS Hetzner paling kecil, dan CPU-nya nggak nyentuh 2%. Itu konyol ringannya.

Kedua, setup-nya gampang. Docker Compose up, buka browser, bikin akun admin, tambah sistem. Selesai. Nggak ada konfigurasi file yang panjang, nggak ada pipeline alerting yang harus dirangkai dari nol.

Ketiga, arsitekturnya masuk akal. Beszel pakai model hub-and-agent. Hub itu dashboard pusat—dibangun di atas PocketBase, yang pada dasarnya adalah backend database plus API. Agent jalan di tiap server yang mau dipantau, ngumpulin metrik, lalu kirim ke hub lewat WebSocket.

Keempat, ada fallback SSH. Ini fitur yang saya suka. Kalau koneksi WebSocket ke hub putus—misalnya reverse proxy lagi reload—agent otomatis buka tunnel SSH di port 45876 biar hub tetap bisa narik data. Dual-path ini bikin koneksinya tahan banting.

Kelima, ada alerting bawaan. Nggak perlu bikin pipeline terpisah. Tinggal toggle, atur threshold, dan Beszel bakal kirim notifikasi lewat email, Discord, Slack, Telegram, atau webhook kalau ada yang lewat batas.

Baca juga Cursor Bangun Ulang SQLite dengan Rust dan Agen AI

Dan yang paling penting, Beszel itu FOSS (Free and Open Source Software) dengan lisensi MIT. Artinya bebas dipakai, dimodifikasi, bahkan buat keperluan komersial. Untuk konteks lisensi open-source yang lebih lengkap, kamu bisa cek penjelasan lisensi MIT di Wikipedia.

Implementasi: Cara Saya Deploy Beszel Step by Step

Oke, sekarang masuk ke bagian teknis. Saya mau jelasin pelan-pelan, jadi kalau kamu belum pernah sentuh Docker pun nggak apa-apa—kita mulai dari dasar.

Apa yang Kamu Butuhin Sebelum Mulai

• Satu server (VPS, bare metal, atau VM) buat jalanin hub. Bisa yang paling kecil—Beszel nggak banyak makan resource.

• Docker dan Docker Compose terpasang di server itu.

• Setiap server yang mau dipantau juga butuh Docker (atau bisa pakai binary kalau nggak pakai Docker).

• Kalau mau pakai domain dan HTTPS, butuh reverse proxy kayak Caddy atau Nginx.

Kalau kamu belum pasang Docker, panduan resminya ada di dokumentasi Docker. Tinggal ikut sesuai sistem operasi kamu.

Langkah 1: Siapin Server buat Hub

Pertama, saya lakukan hardening dasar: bikin user non-root, matiin root login SSH, aktifkan firewall (UFW), dan update semua paket. Ini standar yang harus dilakuin tiap bikin server baru—apapun yang mau kamu pasang di atasnya.

Terus saya bikin DNS record A dan AAAA buat hostname yang mau dipakai, misalnya beszel.domainku.com. Kalau pakai Cloudflare, saya matiin proxy-nya dulu biar cert ACME nggak keblok pas setup awal.

Langkah 2: Bikin Docker Compose File buat Hub + Agent Lokal

Saya bikin folder kerja lalu compose file-nya:

mkdir ~/beszel
cd ~/beszel

Lalu saya buat docker-compose.yml:

services:
  beszel:
    image: henrygd/beszel:latest
    container_name: beszel
    restart: unless-stopped
    ports:
      - 8090:8090
    volumes:
      - ./beszel_data:/beszel_data
      - ./beszel_socket:/beszel_socket
  beszel-agent:
    image: henrygd/beszel-agent:latest
    container_name: beszel-agent
    restart: unless-stopped
    network_mode: host
    volumes:
      - ./beszel_agent_data:/var/lib/beszel-agent
      - ./beszel_socket:/beszel_socket
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
      LISTEN: /beszel_socket/beszel.sock
      HUB_URL: http://localhost:8090
      TOKEN:
      KEY: ""

Ini langsung dari dokumentasi Beszel. Yang penting di sini, hub dan agent lokal berbagi Unix socket di /beszel_socket/beszel.sock lewat volume mount yang sama. Jadi mereka bisa ngobrol tanpa harus buka port ke luar.

TOKEN dan KEY biarkan kosong dulu—kita isi nanti setelah dapet nilai dari dashboard.

Jalankan:

sudo docker compose up -d

Dua container langsung jalan. Buka browser ke http://<IP-SERVER>:8090.

Langkah 3: Bikin Akun Admin dan Hubungkan Agent Lokal

Saat pertama kali buka dashboard, Beszel minta bikin akun pertama. Masukkan email dan password, dan langsung masuk ke dashboard.

Dari dashboard, klik Add System, kasih nama (saya kasih nama "Hub"), dan Beszel bakal ngasih token plus key. Copy nilai itu, paste ke compose file di bagian TOKEN dan KEY, lalu re-run:

sudo docker compose up -d

Karena kedua container berbagi socket yang sama, kamu bisa set Host/IP ke path socket itu dan koneksi langsung nyala. Dashboard bakal nunjukin metrik real-time dari server hub itu sendiri.

Langkah 4: Amankan Pakai Reverse Proxy (Caddy)

Saya nggak suka ekspos port 8090 di plain HTTP. Jadi sebelum lanjut, saya pasang Caddy di depannya:

sudo apt install caddy

Bikin /etc/caddy/Caddyfile:

beszel.domainku.com {
    request_body {
        max_size 10MB
    }
    reverse_proxy 127.0.0.1:8090 {
        transport http {
            read_timeout 360s
        }
    }
}

Ganti beszel.domainku.com dengan domain kamu, lalu:

sudo systemctl restart caddy

Caddy otomatis minta sertifikat Let's Encrypt dan mulai proxy ke 127.0.0.1:8090. Pastikan port 80 dan 443 kebuka di firewall—kalau nggak, ACME challenge bakal gagal.

Setelah Caddy jalan, saya ubah port mapping di compose file biar Beszel cuma denger di localhost:

Baca juga Apa Itu Context Length AI? Fungsi dan Cara Kerjanya

ports:
  - 127.0.0.1:8090:8090

Re-deploy, dan sejak itu dashboard cuma bisa diakses lewat HTTPS di domain saya.

Langkah 5: Tambah Server Lain (Remote Agent)

Nah, ini bagian yang paling enak. Buka dashboard, klik Add System, pilih opsi Docker, kasih nama, masukkan IP server target dan port (default 45876).

Beszel bakal ngasilin compose snippet yang tinggal kamu copy ke server target. Struktur foldernya sama—bikin folder ~/beszel di server target, paste snippet-nya, lalu:

sudo docker compose up -d

Dalam hitungan detik, agent konek dan hub mulai narik metrik. Saya nggak over-exaggerate—benar-benar klik, copy, paste, deploy, selesai.

Langkah 6: Konfigurasi Firewall buat Fallback SSH

Karena agent pakai network_mode: host (biar bisa baca counter NIC yang asli), Docker nggak bisa publish port 45876 kayak biasa. Jadi di tiap server yang jalanin agent, saya buka portnya di UFW tapi cuma dari IP hub:

sudo ufw allow in proto tcp from <HUB_IPV4> to any port 45876
sudo ufw allow in proto tcp from <HUB_IPV6> to any port 45876

Jadi kalau WebSocket putus dan agent fallback ke SSH, hub tetap bisa nyampe tanpa ekspos port ke dunia.

Langkah 7: Aktifin Health Check

Beszel punya health command bawaan buat hub dan agent. Saya tambahin ke compose file:

beszel:
  healthcheck:
    test: ["CMD", "/beszel", "health", "--url", "http://localhost:8090"]
    interval: 120s
    timeout: 5s
    retries: 3
    start_period: 5s

beszel-agent:
  healthcheck:
    test: ["CMD", "/agent", "health"]
    interval: 120s
    timeout: 5s
    retries: 3
    start_period: 15s
  depends_on:
    beszel:
      condition: service_healthy

Sekarang docker ps langsung nunjukin status healthy atau unhealthy buat tiap container. depends_on juga bikin agent lokal nggak mulai sebelum hub bener-bener siap.

Langkah 8: Setup SMTP buat Notifikasi Email

Buka Settings → Notifications di dashboard. Klik link buat konfigurasi SMTP, yang bakal bawa kamu ke admin panel PocketBase. Aktifin "Use SMTP mail server", isi detail SMTP kamu, dan kirim email test.

Saya pakai SMTP2GO yang gratis dan cukup andal. Setelah test berhasil, balik ke dashboard Beszel, klik ikon bel di tiap sistem, dan aktifkan alert yang kamu mau.

Saya aktifin alert Status (uptime) dengan threshold 1 menit. Jadi kalau server down lebih dari semenit, saya langsung dapat email. Selain itu, saya juga pasang alert CPU di atas 90% selama 5 menit dan disk di atas 85%.

Langkah 9: Tambahin MFA OTP (Opsional tapi Disarankan)

Di compose file hub, tambahin:

environment:
  - MFA_OTP=true

Re-deploy, dan next time login, Beszel bakal minta kode OTP yang dikirim ke email. Ini cuma jalan kalau SMTP kamu stabil, jadi pastikan dulu email-nya nggak ada masalah.

Hasil: Apa yang Berubah Setelah Pakai Beszel

Metrik Resource: Ringan Banget

Ini data nyata dari pengalaman saya dan juga yang dibagikan komunitas:

Bandingin sama Grafana+Prometheus yang gampang makan 500 MB+ RAM. Di Raspberry Pi yang cuma punya 1-2 GB, Beszel nyala tanpa masalah, sementara Grafana bakal kelabakan.

Visibilitas: Semua Server di Satu Layar

Sekarang saya buka dashboard, dan langsung lihat semua server dalam grid view. Tiap kartu nunjukin CPU, memori, disk, dan status. Kalau ada yang warna merah, saya langsung tahu mana yang bermasalah.

Klik salah satu server, dan muncul grafik detail: CPU breakdown per core, I/O wait, memori (termasuk swap dan ZFS ARC), disk per partisi, network bandwidth, load average, suhu sensor, bahkan GPU power draw kalau ada.

Yang paling saya suka: Docker container stats. Tiap container di tiap server kelihatan CPU, memori, network I/O, status, dan uptime. Bahkan log container bisa dilihat langsung dari dashboard tanpa SSH. Buat saya yang jalanin banyak container, ini game changer.

Alerting: Dari Reaktif ke Proaktif

Sebelum Beszel, saya cuma tahu server bermasalah kalau sudah telat. Sekarang, kalau disk di salah satu server nyentuh 85%, saya dapat email dalam semenit. Kalau container crash, alert nyala. Kalau server down, notifikasi langsung masuk.

Saya juga pakai notifikasi Discord lewat Shoutrrr (library yang Beszel pakai untuk notifikasi). Setup-nya gampang—tinggal masukin webhook URL Discord di settings, dan alert langsung masuk ke channel Discord saya.

Baca juga Histats: Web Analytics Gratis untuk Pantau Traffic Website

Waktu Setup: Dari Berhari-Hari ke Berjam-Jam

Dulu, setup monitoring stack (Prometheus + Grafana + Node Exporter + Alertmanager) makan saya 1-2 hari penuh. Dengan Beszel, dari nol sampai semua server terpantau, cuma butuh sekitar 2-3 jam. Itu termasuk hardening server, setup Caddy, konfigurasi SMTP, dan onboarding semua server.

Konektivitas: Dual-Path yang Benar-Benar Bekerja

Saya sengaja test fallback SSH. Restart Caddy di hub server, dan lihat log agent:

2025/11/06 18:23:00 INFO WebSocket connected host=beszel.domainku.com
2025/11/07 09:26:17 WARN Connection closed err=EOF
2025/11/07 09:26:17 WARN Disconnected from hub
2025/11/07 09:26:17 WARN WebSocket connection failed err="unexpected status code: 502"
2025/11/07 09:26:17 INFO Starting SSH server addr=:45876 network=tcp
2025/11/07 09:26:50 INFO SSH connected addr=:56882
2025/11/07 09:26:50 INFO SSH connection established

WebSocket putus, agent otomatis buka SSH listener di port 45876, hub konek lewat situ, dan metrik tetap ngalir. Pas WebSocket balik, agent otomatis switch lagi. Nggak ada gap data sama sekali.

Perbandingan: Beszel vs Alternatif Populer

Nah, biar kamu bisa lihat gambaran utuh, mari kita bandingkan Beszel sama tiga alternatif yang paling sering dibahas.

Tabel Perbandingan

Kapan Pilih Beszel

• Kamu punya beberapa server (3-20) dan mau pantau semuanya dari satu tempat tanpa ribet.

• Resource server terbatas (Raspberry Pi, VPS kecil, SBC).

• Kamu jalanin banyak Docker container dan butuh visibilitas per-container.

• Kamu mau setup cepat—hari ini pasang, hari ini juga jalan.

• Kamu butuh alerting tapi nggak mau bikin pipeline terpisah.

Kapan Pilih Prometheus + Grafana

• Kamu butuh query yang fleksibel (PromQL) buat analisis mendalam.

• Tim kamu sudah familiar dengan ekosistem Prometheus.

• Kamu butuh integrasi dengan banyak exporter dan datasource.

• Skala enterprise dengan ribuan server dan retention panjang.

Kapan Pilih Netdata

• Kamu butuh monitoring real-time yang sangat detail di satu host.

• Kamu mau visualisasi yang kaya tanpa konfigurasi.

• Kamu nggak kebutuhan manajemen multi-server yang terpusat.

Kapan Pilih Zabbix

• Infrastruktur kamu besar dan heterogen (network, server, VM, container, IoT).

• Kamu butuh alerting yang sangat mendalam dengan aturan kompleks.

• Kamu butuh dukungan enterprise dan fitur compliance.

• Kamu punya tim yang bisa dedikasi waktu buat maintain Zabbix.

Rekomendasi per Use Case

Fitur-Fitur Beszel yang Perlu Kamu Tahu

Metrik yang Dipantau

Beszel nggak cuma ngasih CPU dan memori doang. Ini daftar lengkap metrik yang bisa dipantau:

• CPU usage — host dan per-container, termasuk I/O wait dan breakdown per core

• Memory usage — host dan container, termasuk swap dan ZFS ARC

• Disk usage — multi-partisi dan multi-device

• Disk I/O — read/write per device dan partisi

• Network usage — host dan container

• Load average — host system

• Temperature — sensor suhu host

• GPU usage / power draw — Nvidia, AMD, dan Intel

• Battery — charge baterai host

• S.M.A.R.T. — data kesehatan disk dan notifikasi kalau drive bermasalah

Sistem Operasi yang Didukung

Salah satu keunggulan Beszel: agent-nya jalan di banyak OS.

• Linux — Docker atau binary (systemd)

• macOS — binary (launchd)

• Windows — binary (pakai NSSM buat jalanin sebagai service) atau WSL2

• FreeBSD — binary

• Homebrew — install via package manager

Jadi kamu nggak terkunci di Linux doang. Kalau punya Windows dengan GPU Nvidia buat gaming atau AI, bisa dipantau juga. Bahkan Home Assistant punya add-on Beszel buat monitoring dari sana.

Keamanan: Cara Hub dan Agent Komunikasi

Ini bagian yang sering ditanyakan, jadi mari kita bahas.

Beszel pakai dua jalur komunikasi: WebSocket (utama) dan SSH (fallback). Keduanya diamankan dengan:

• Hub generate keypair ED25519 saat start. SSH fallback cuma nerima key itu, nggak ngasih shell, dan nggak jalanin command. Jadi walau key bocor, attacker nggak bisa eksekusi perintah di agent.

• Tiap sesi WebSocket dimulai dengan mutual authentication: agent kirim token registrasi, hub tandatangani challenge, agent verifikasi tanda tangan itu pakai public key hub. Terus agent kirim fingerprint yang terikat ke server yang dipantau, dan hub pastikan fingerprint cocik sama record asli.

• Hasilnya: cuma hub asli dan agent asli yang bisa ngobrol satu sama lain.

Untuk informasi lebih tentang ED25519 dan kriptografi kunci publik, artikel Wikipedia tentang EdDSA cukup membantu buat ngerti konsep dasarnya.

Multi-User dan OAuth/OIDC

Beszel dukung multi-user. Tiap user kelola sistemnya sendiri, dan admin bisa share sistem antar user. Buat autentikasi, Beszel dukung banyak provider OAuth2/OIDC—termasuk GitHub, Google, dan bahkan Tailscale (lewat TS IDP).

Kalau mau, kamu bisa matiin autentikasi password dan wajibin OAuth. Ini bikin akses lebih aman, terutama kalau ditaruh di network yang bisa diakses tim.

Backup Otomatis

Beszel bisa backup data ke disk lokal atau ke S3-compatible storage (seperti MinIO, Backblaze B2, atau AWS S3). Ini fitur yang sering nggak ada di alat monitoring sejenis, dan buat saya ini penting banget—data monitoring adalah aset, bukan sampah yang boleh hilang.

REST API

Beszel punya REST API buat akses dan update data dari script atau aplikasi kamu sendiri. Sayangnya, belum ada dokumentasi OpenAPI yang publik, jadi kamu perlu reverse-engineer endpoint atau cek GitHub discussions. Tapi buat kebutuhan dasar (baca metrik, tambah sistem, update alert), API-nya sudah cukup.

Kesalahan yang Saya Buat (Biar Kamu Nggak Ulangin)

Lupa Buka Port 80/443 di Firewall

Pas pertama setup Caddy, saya lupa buka port 80 dan 443 di UFW. Hasilnya, Caddy nggak bisa selesain ACME challenge, dan Let's Encrypt rate-limit saya kena. Sekarang saya selalu cek dua kali sebelum restart Caddy.

Tip: Kalau ada masalah, sudo journalctl -u caddy --no-pager -n 100 sangat membantu buat diagnose.

Nggak Set APP_URL di Belakang Reverse Proxy

Beszel rekomendasiin set APP_URL kalau di belakang reverse proxy, biar link notifikasi dan config agent pakai URL yang bener. Saya skip ini pertama kali, dan link di email alert ngarah ke localhost:8090 yang jelas nggak bisa diakses dari mana pun.

Solusinya gampang—tambahin environment variable di compose file hub:

environment:
  - APP_URL=https://beszel.domainku.com

Re-deploy dan selesai.

Lupa Buka Port 45876 buat Fallback SSH

Saya pikir karena WebSocket udah jalan, fallback SSH nggak perlu. Ternyata pas Caddy reload, WebSocket putus dan agent coba SSH—tapi port 45876 keblok firewall. Metrik kosong selama beberapa menit sampai WebSocket balik.

Baca juga Arena AI: Cara Membandingkan & Memilih Model AI Terbaik

Sekarang saya selalu buka port itu dari IP hub saja, bukan dari mana pun.

Nggak Ganti Password PocketBase Superuser

Setelah setup awal, saya lupa ganti password superuser PocketBase. Ini penting karena password itu juga jalan buat akses admin panel PocketBase yang lebih dalam. Kalau bocor, orang bisa akses database langsung.

Ganti via command line:

sudo docker exec beszel /beszel superuser update [email protected] passwordbaru

Command ini juga logout semua orang dari admin panel PocketBase. Bagus buat rotasi password berkala.

Terlalu Banyak Alert di Awal

Saya sempet aktifin semua alert di semua server di hari pertama. Hasilnya? Inbox kacau. Setiap server kirim alert CPU spike yang sebenarnya wajar pas ada backup job jalan.

Saran saya: mulai pelan-pelan. Aktifin alert Status (uptime) dulu, lalu tambahin satu-satu setelah kamu ngerti pola normal tiap server. Kalau CPU biasanya di 60-70% pas backup jalan, jangan set alert di 70%.

Tips Praktis dari Pengalaman

Pakai Tailscale buat Monitoring Lintas Lokasi

Kalau server kamu tersebar di beberapa lokasi (misalnya VPS di Singapore, server rumah di Jakarta, dan VPS di Jepang), pakai VPN mesh kayak Tailscale buat hubungkan semuanya. Dengan Tailscale, agent bisa konek ke hub lewat tailnet tanpa buka port publik sama sekali.

Saya pakai ini buat monitor server yang beda benua. Setup-nya cuma install Tailscale di hub dan tiap agent, tailscale up, dan pakai IP tailnet sebagai HUB_URL. Selesai. Nggak perlu konfigurasi firewall, nggak perlu ekspos port.

Pakai Tailscale Serve buat HTTPS Gratis

Kalau kamu pakai Tailscale, ada fitur Tailscale Serve yang bisa jadi reverse proxy plus ngasih sertifikat TLS gratis buat domain .ts.net kamu. Jadi kamu nggak perlu setup Caddy kalau cuma akses dari tailnet.

Backup ke S3 dari Hari Satu

Jangan tunggu sampai kehilangan data baru sadar. Setup backup ke S3-compatible storage dari awal. Saya pakai Backblaze B2 yang harganya murah banget ($0.005/GB/bulan). Test restore juga—backup yang nggak pernah di-test restore sama kayak nggak ada backup.

Pantau Hub-nya Sendiri

Ini yang sering luput. Hub juga butuh dipantau. Kalau hub down, kamu buta—nggak tahu kondisi server lain. Jadi jalanin agent lokal di server yang sama dengan hub, dan set alert buat hub itu sendiri.

Pakai Grid View buat Overview Cepat

Beszel punya beberapa layout: grid, list, dan lainnya. Saya paling sering pakai grid view karena langsung kelihatan semua server dengan metrik ringkas. Kalau mau detail, tinggal klik salah satu.

Keyboard Shortcut: ⌘K / Ctrl+K

Beszel dukung command palette. Tekan ⌘K (Mac) atau Ctrl+K (Windows/Linux) buat lompat ke server mana pun dengan cepat. Ini fitur kecil tapi kalau kamu punya banyak server, bikin banget lebih efisien.

Siapa yang Cocok Pakai Beszel (dan Siapa yang Nggak)

Cocok Banget Buat

• Homelab enthusiast yang punya beberapa server dan mau monitoring yang nggak makan resource

• Usaha kecil yang jalanin Docker container dan butuh visibilitas tanpa investasi besar

• Tim kecil yang butuh monitoring multi-user dengan alerting sederhana

• Developer yang mau pantau VPS atau server dev tanpa setup kompleks

• Siapa pun yang mau alternatif lebih ringan dari Prometheus+Grafana

Mungkin Skip Kalau

• Enterprise dengan SLA ketat — Beszel nggak punya commercial support atau vendor escalation. Community-driven, dan author respond best-effort.

• Butuh APM, log aggregation, atau distributed tracing — Beszel fokus di infrastruktur, bukan application performance monitoring. Kalau butuh itu, lihat Prometheus + Grafana atau ELK stack.

• Butuh compliance certification (SOC2, HIPAA, FedRAMP) — nggak ada bukti sertifikasi seperti itu di Beszel.

• Skala ribuan server — Beszel belum di-test di skala itu. Untuk skala besar, Prometheus atau Zabbix lebih matang.

Yang Bikin Beszel Beda dari Lainnya

Saya udah pakai beberapa alat monitoring, dan ini yang bikin Beszel benar-benar beda:

Ringan itu bukan cuma klaim. Saya ukur sendiri—agent makan 8 MB RAM, hub makan 30-50 MB. Di Raspberry Pi Zero 2W yang cuma punya 512 MB RAM, Beszel jalan tanpa keluhan. Coba itu di Grafana.

Setup bukan berhari-hari, tapi berjam. Dari nol sampai semua server terpantau, 2-3 jam. Termasuk hardening, reverse proxy, SMTP, dan onboarding. Bandingkan Prometheus+Grafana yang gampang makan 1-2 hari.

Dashboard yang nggak butuh dirakit. Grafana bikin kamu bangun dashboard dari nol—pilih panel, tulis query, atur visualisasi. Beszel ngasih dashboard siap pakai yang langsung menampilkan metrik penting. Kalau mau sembunyikan metrik yang nggak relevan (kayak GPU atau suhu), tinggal toggle.

Docker container auto-discovery. Beszel otomatis nemuin dan pantau semua container di server yang jalanin Docker. Nggak perlu tambahin satu-satu kayak di Uptime Kuma. Ini fitur yang sering di-undervalue tapi sangat menghemat waktu.

Dual-path connection yang bener-bener jalan. Bukan cuma klaim di dokumentasi—saya test sendiri, dan fallback SSH benar-benar nyala pas WebSocket putus. Metrik nggak ada gap.

Keterbatasan yang Jujur (Biar Kamu Tahu Sejak Awal)

Saya nggak mau terdengar kayak iklan. Beszel punya keterbatasan, dan kamu harus tahu sebelum komitmen.

Baca juga macOS 27 Golden Gate: Fitur, Siri AI & Cara Update

Tidak ada OpenAPI spec. REST API ada dan bisa dipakai, tapi dokumentasinya belum lengkap. Kamu perlu reverse-engineer atau cek GitHub discussions buat tau endpoint apa saja yang tersedia.

Nggak cocok buat long-term metric retention. Beszel simpan data di PocketBase (SQLite), bukan time-series database yang dioptimalkan buat retensi panjang. Kalau kamu butuh simpan metrik selama bertahun-tahun dengan query cepat, Prometheus (dengan TSDB-nya) lebih cocok.

Alerting cukup dasar. Kamu bisa set threshold per-metrik, tapi nggak bisa bikin aturan kompleks kayak "kalau CPU di atas 90% DAN disk I/O di atas 80% DAN load average di atas 5 selama 10 menit, kirim alert ke tim A tapi kalau cuma CPU, kirim ke tim B". Untuk alerting yang sophisticated, Alertmanager atau Zabbix lebih mumpuni.

Tidak ada service discovery buat Kubernetes. Beszel nggak dirancang buat environment Kubernetes-native. Kalau pod datang-pergi dinamis, kamu butuh sesuatu yang bisa auto-discover kayak Prometheus dengan Kubernetes SD.

Tidak ada security audit formal. Nggak ada bukti penetration test atau vulnerability disclosure program. Untuk environment yang regulated, ini perlu dipertimbangkan. Tapi kodenya open-source dan bisa diaudit sendiri.

Windows agent butuh effort ekstra. Kalau di Linux dan macOS setup gampang, di Windows kamu perlu compile binary sendiri dan pakai NSSM buat jalanin sebagai service. Ada juga laporan Windows Defender kadang flag agent.exe sebagai suspicious.

Pelajaran Kunci yang Saya Tarik

1. Ringan Itu Bukan Berarti Kurang Fitur

Saya dulu pikir alat yang ringan pasti nggak punya fitur cukup. Beszel buktiin sebaliknya. Dengan 8 MB RAM, agent bisa pantau CPU, memori, disk, network, Docker, GPU, suhu, sampai S.M.A.R.T. Ringan itu soal efisiensi implementasi, bukan soal ngurangin fitur.

2. Setup Cepat Itu Strategi, Bukan Kekurangan

Beszel bisa setup dalam hitungan jam bukan karena fiturnya dikit, tapi karena default-nya sudah masuk akal. Dashboard siap pakai, alerting bawaan, auto-discovery container—semua sudah dikonfigurasi dengan baik dari sananya. Kamu nggak perlu mikir "apa yang harus saya tampilin?" karena Beszel sudah jawab itu buat kamu.

3. Dual-Path Connection Itu Lebih Berharga dari yang Kira

Saya nggak ngerti kenapa ini penting sampai saya alamin sendiri. Pas reverse proxy reload di tengah malam, metrik tetap ngalir lewat SSH. Kalau cuma WebSocket doang, ada gap data tiap kali ada maintenance. Dual-path bikin monitoring benar-benar terus-menerus.

4. Backup Otomatis Itu Wajib, Bukan Opsional

Saya pernah kehilangan data monitoring karena lupa backup. Dengan Beszel, setup backup ke S3 cuma butuh beberapa menit, dan saya bisa restore kapan pun. Ini fitur yang seharusnya ada di setiap alat monitoring tapi sering nggak.

5. Komunitas Itu Indikator Kesehatan Proyek

Beszel punya 23 ribu+ bintang di GitHub dan komunitas yang aktif. Ini bukan jaminan, tapi sinyal kuat bahwa proyek ini hidup dan dipakai banyak orang. Kalau kamu mau cek sendiri, repo resminya di github.com/henrygd/beszel.

6. Nggak Semua Butuh Enterprise-Grade

Ini pelajaran terbesar. Saya sempat terjebak mikir "harus pakai Prometheus+Grafana karena itu standar industri". Padahal kebutuhan saya sederhana—tahu CPU berapa, disk penuh nggak, container mana yang bermasalah. Beszel jawab semua itu tanpa kompleksitas yang nggak perlu.

Kadang, alat yang "cukup" justru lebih baik dari alat yang "sempurna" tapi bikin kamu habis waktu manage alatnya sendiri ketimbang service yang dipantau.

7. Test Disaster Recovery Sebelum Bener-Bener Bencana

Saya test: bikin snapshot server hub, hapus server, restore ke mesin baru dengan IP yang sama, jalankan ulang Beszel. Hasilnya? Semua agent otomatis reconnect, metrik mulai ngalir lagi, Caddy dapet cert baru. Prosesnya mulus. Tapi kalau saya nggak pernah test, saya nggak akan tahu apakah recovery plan saya bener-bener jalan.

Getting Started: Ringkasan Buat Kamu yang Mau Coba

Kalau setelah baca sampai sini kamu kepikiran "kayaknya cocok nih buat saya", ini ringkasan langkah cepat:

1. Pasang Docker di server yang mau jadi hub

2. Bikin docker-compose.yml dengan image henrygd/beszel:latest (dan henrygd/beszel-agent:latest kalau mau pantau hub itu sendiri)

3. Jalankan docker compose up -d

4. Buka browser ke http://<IP>:8090 dan bikin akun admin

5. Tambah sistem dari dashboard, copy token/key ke compose file agent, re-deploy

6. Pasang reverse proxy (Caddy) buat HTTPS

7. Konfigurasi SMTP buat notifikasi email

8. Aktifkan alert per sistem sesuai kebutuhan

9. Setup backup ke S3 atau disk lokal

10. Tambah server lain dengan cara yang sama—klik, copy, paste, deploy

Total waktu: 2-3 jam buat setup lengkap dengan 5-10 server.

Penutup (Tapi Bukan Kesimpulan)

Nah, Teman-Teman, sampai sini kita udah bahas Beszel dari atas ke bawah—dari latar belakang, tantangan, cara deploy, hasil nyata, perbandingan sama alternatif, sampai keterbatasannya. MUGHU udah pakai Beszel beberapa bulan sekarang, dan jujur, ini salah satu alat open-source paling enak yang pernah saya pakai. Bukan karena dia sempurna—nggak ada alat yang sempurna—tapi karena dia jawab kebutuhan saya dengan tepat tanpa bikin pusing.

Kalau kamu punya 3-10 server dan capek bolak-balik SSH, atau kalau Grafana+Prometheus terasa kayak pakai bazooka buat nyamuk, Beszel patut banget dicoba. Dan kalau ternyata nggak cocok, kamu cuma kehilangan 2 jam—bukan 2 hari.

Repo resmi: github.com/henrygd/beszel. Dokumentasi: beszel.dev. Lisensi MIT, gratis, dan kodenya bersih.

Selamat monitoring, dan semoga server kamu nggak pernah down di jam-jam yang nggak enak.

Baca juga Kimi K3 Moonshot AI Rilis: 2,8T Parameter, Konteks 1Juta Token

FAQ: Pertanyaan yang Sering Muncul Soal Beszel

Teman-Teman, MUGHU sadar walau artikel ini udah panjang banget, pasti masih ada pertanyaan-pertanyaan teknis yang kelewat. Bagian ini MUGHU kumpulin dari pertanyaan-pertanyaan yang sering muncul di GitHub issues, forum komunitas, dan DM yang masuk ke saya langsung.

Apakah Beszel Bisa Dipakai Tanpa Docker?

Bisa. Walaupun MUGHU selalu rekomendasiin Docker karena urusan dependency jadi lebih rapi, Beszel juga sediain binary standalone buat hub dan agent. Kamu tinggal download dari halaman rilis GitHub, ekstrak, dan jalankan langsung. Tapi ingat, tanpa Docker kamu harus manage systemd service sendiri, dan update jadi manual—tarik binary baru, replace, restart service. Kalau kamu nyaman dengan itu, silakan. Kalau nggak, Docker tetap jalan paling bersih.

Berapa Banyak Server yang Bisa Dipantau Satu Hub?

MUGHU udah coba sampai 12 server di satu hub tanpa masalah berarti. CPU hub rata-rata di bawah 5% dan RAM di sekitar 60-80 MB. Menurut diskusi di komunitas, ada yang udah nyoba 30+ server dan masih aman. Tapi kalau kamu pantau ratusan server, mungkin mulai ada pertimbangan performa—terutama soal penyimpanan data historis. Beszel simpan data di SQLite, dan walau SQLite tangguh banget buat skala menengah, volume data yang terlalu besar bakal ngaruh ke kecepatan query dashboard.

Apakah Data Historis Bisa Di-Export?

Bisa, lewat REST API. Beszel sediain endpoint buat ambil data metrik dalam format JSON. Kamu bisa bikin script sendiri buat tarik data berkala dan simpan ke tempat lain—misalnya InfluxDB atau bahkan spreadsheet Google. MUGHU sendiri punya cron job sederana yang tarik data CPU dan disk tiap jam, simpan ke CSV, biar punya arip jangka panjang yang nggak tergantung pada penyimpanan internal Beszel.

Bagaimana Kalau Agent Server Tidak Bisa Diakses dari Hub?

Ini salah satu skenario yang bikin banyak orang panik. Agent nggak respon, hub nampilin status "offline", tapi server sebenarnya hidup. Pertama, cek koneksi SSH—apakah hub masih bisa SSH ke server agent. Kedua, pastikan agent process masih jalan: docker ps | grep beszel-agent atau systemctl status beszel-agent kalau pakai binary. Ketiga, cek firewall—port 45876 (default agent) harus terbuka buat hub.

Kalau semua itu udah benar dan agent tetap nggak konek, restart agent biasanya cukup. MUGHU jarang banget ngalamin ini—mungkin dua kali dalam beberapa bulan—dan setiap kali restart langsung beres.

Tips Lanjutan yang Mungkin Belum Kamu Pikirin

Setelah pakai Beszel beberapa bulan, MUGHU nemuin beberapa trik yang nggak ada di dokumentasi resmi tapi cukup berguna buat operasi sehari-hari.

Pakai Label Sistem Buat Pengelompokan

Beszel nggak punya fitur "tag" atau "label" bawaan, tapi kamu bisa manfaatin penamaan sistem buat pengelompokan. MUGHU pakai konvensi nama kayak prod-web-01, prod-db-02, dev-test-03. Dari dashboard, sistem otomatis terurut berdasarkan nama, dan kamu bisa cepat lihat mana yang production dan mana yang development. Sederhana, tapi efektif banget.

Pantau Hub Itu Sendiri

Banyak yang lupa kalau hub juga butuh dipantau. MUGHU selalu pasang agent di mesin yang sama dengan hub, jadi kalau hub kehabisan RAM atau disk penuh, MUGHU langsung dapet alert. Tanpa ini, kamu bisa nggak sadar hub bermasalah sampai dashboard sendiri nggak bisa diakses—dan saat itu udah terlambat.

Atur Alert dengan Bijak

Sering banget orang aktifin semua alert sekaligus pas awal, terus kewalahan sama notifikasi yang masuk tiap menit. MUGHU sarankan: mulai cuma dengan alert CPU > 90% selama 5 menit dan disk > 85%. Setelah seminggu, lihat pola server kamu, baru tambah alert lain satu per satu. Kalau kamu aktifin 10 alert sekaligus di hari pertama, kamu bakal mati rasa terhadap notifikasi—dan itu lebih bahaya dari nggak punya alert sama sekali.

Manfaatin REST API buat Integrasi Sederhana

REST API Beszel cukup lengkap buat kebutuhan otomasi. MUGHU pakai buat dua hal: pertama, kirim ringkasan status harian ke channel Slack lewat webhook sederhana. Kedua, trigger script auto-scale kalau CPU salah satu server konsisten di atas 80% selama 10 menit. Kamu nggak perlu jago coding buat ini—cukup paham curl dan sedikit bash scripting. Dokumentasi API-nya cukup jelas dan ada contoh request di dokumentasi resmi Beszel.

Pertimbangan Soal Skala dan Masa Depan

Teman-Teman, MUGHU mau jujur soal satu hal: Beszel itu alat buat skala kecil sampai menengah. Kalau kamu pantau 5-50 server, Beszel cocok banget. Kalau kamu udah bicara 200+ server dengan kebutuhan multi-tenant yang kompleks, kemungkinan besar kamu butuh sesuatu yang lebih gede—kayak Prometheus + Grafana + Alertmanager stack yang memang didesain buat skala enterprise.

Tapi di antara "saya punya 3 VPS" dan "saya manage 500 server", ada area yang luas banget. Dan di area itu, Beszel bersinar. Mayoritas developer, freelancer, dan tim kecil di Indonesia berada di rentang itu. Kamu punya beberapa server buat project client, satu buat blog pribadi, mungkin satu lagi buat database—itu skala yang pas buat Beszel.

Soal masa depan proyek ini, MUGHU cukup optimis. Pengembang utama, henrygd, konsisten push update—fitur baru, perbaikan bug, dan respons terhadap komunitas. Komitmen ke kesederhanaan dan ringan itu jelas dari setiap rilis. Tapi kayak semua proyek open-source, nggak ada jaminan jangka panjang. MUGHU tetap rekomendasiin buat selalu backup data dan jangan jadiin satu alat sebagai single point of failure buat monitoring kamu.

Kalau suatu hari Beszel nggak lagi aktif dikembangkan, data kamu bisa di-export lewat API, dan setup bisa diganti dalam hitungan jam. Itu yang bikin MUGHU tenang pakai alat open-source dengan lisensi MIT—nggak ada vendor lock-in, nggak ada kontrak yang ngiket, dan data tetap milik kamu.

Perbandingan Singkat: Beszel vs Alternatif Lain

Teman-Teman, MUGHU tau banyak yang masih ragu antara pakai Beszel atau alat monitoring lain yang udah lebih dulu terkenal. Jadi MUGHU mau bikin perbandingan singkat biar kamu bisa ambil keputusan dengan lebih mantap.

Beszel vs Netdata

Netdata itu salah satu alat monitoring server yang paling populer di kalangan sysadmin. Kelebihannya? Grafik real-time yang super detail dan ribuan metrik yang kekoleksi otomatis. Tapi kekuatan itu juga jadi kelemahannya—Netdata makan resource yang lumayan gede, dan kalau kamu pasang di server kecil, bisa-bisa monitoring-nya sendiri yang bikin server berat.

Beszel ambil pendekatan yang beda. Resource yang dipakai jauh lebih kecil, dan fokusnya cuma di metrik yang memang penting: CPU, RAM, disk, jaringan, dan suhu. Buat mayoritas kebutuhan monitoring sehari-hari, itu udah cukup. Kamu nggak butuh 500 grafik kalau yang kamu lihat cuma 5 metrik utama.

Beszel vs Uptime Kuma

Uptime Kuma lebih ke arah uptime monitoring—cek apakah service kamu hidup atau mati, dari luar. Beszel lebih ke arah internal monitoring—apa yang terjadi di dalam server. Keduanya saling melengkapi, bukan saling nggantian. MUGHU sendiri pakai keduanya: Beszel buat pantau resource server, Uptime Kuma buat pantau apakah endpoint publik masih bisa diakses dari luar.

Kalau kamu cuma bisa pilih satu, pertanyaannya: kamu lebih peduli sama "server ini hidup tapi CPU-nya 95%" atau "service ini bisa diakses dari internet"? Jawaban itu yang nentuin alat mana yang lebih pas.

Baca juga Claude Opus 5: Fakta Terbaru, Bocoran, dan Cara Siapinnya

Beszel vs Prometheus + Grafana

Ini perbandingan yang sering banget muncul. Prometheus + Grafana itu standar industri buat monitoring. Fleksibel, kuat, dan bisa scale sampai ribuan server. Tapi setup-nya nggak simpel. Kamu harus konfigur Prometheus buat scrape metrik, bikin dashboard Grafana dari nol, atur alerting rules, dan maintain seluruh stack itu.

Buat yang udah terbiasa dengan ekosistem itu, sih fine-fine aja. Tapi buat kamu yang cuma butuh tahu "server saya sehat atau nggak" tanpa mau ribet konfigurasi, Beszel jauh lebih masuk akal. Setup 10 menit, langsung kelihatan datanya, nggak perlu bikin dashboard manual.

Satu hal yang MUGHU suka tekankan: pilih alat sesuai kebutuhan, bukan sesuai hype. Banyak orang langsung lompat ke Prometheus + Grafana karena denger "itu yang dipakai perusahaan gede", padahal kebutuhan mereka sebenarnya cuma pantau 5 VPS. Itu kayak beli truk kontainer buat nganterin sembako—overkill banget.

Biaya Operasional: Berapa Beszel Bikin Kamu Hemat

Teman-Teman, MUGHU mau ngomong soal uang. Bukan karena MUGHU pelit, tapi karena di Indonesia, tiap rupiah yang keluar buat infrastruktur itu perlu diperhitungin—apalagi kalau kamu freelancer atau jalanin bisnis kecil yang margin-nya nggak gede-gede amat.

Alat monitoring berbayar kayak Datadog atau New Relic emang bagus, tapi harganya bisa mulai dari $15-18 per server per bulan. Kalau kamu punya 10 server, itu berarti $150-180 per bulan—atau sekitar 2,3-2,8 juta rupiah cuma buat monitoring. Dalam setahun, kamu ngeluarin 27-34 juta. Buat tim kecil atau personal developer, angka itu gede banget.

Beszel? Gratis. Lisensi MIT, nggak ada biaya langganan, nggak ada tier berbayar, nggak ada batasan jumlah server di versi gratis. Yang kamu keluarin cuma biaya VPS buat nge-host hub-nya—dan kalau kamu udah punya server yang jalan, kamu bisa pasang hub di sana tanpa biaya tambahan.

Tapi MUGHU mau fair di sini. "Gratis" nggak berarti "tanpa biaya". Ada biaya waktu buat setup dan maintain. Ada biaya belajar—meskipun kecil karena Beszel cukup intuitif. Dan ada biaya opportunity: kalau Beszel nggak bisa sesuatu yang kamu butuh, kamu mungkin harus tambah alat lain buat nutupin gap itu. Tapi secara keseluruhan, biaya operasional Beszel jauh lebih rendah dibanding solusi berbayar, dan itu fakta yang nggak bisa dipungkiri.

Satu hal yang sering dilupakan: biaya resource server itu juga uang. VPS di penyedia cloud Indonesia atau DigitalOcean charge per RAM dan CPU yang kamu pakai. Kalau alat monitoring kamu makan 500MB RAM, itu berarti kamu butuh plan yang lebih gede—dan lebih mahal. Beszel yang ringan bikin kamu bisa tetap di plan paling kecil tanpa perlu upgrade cuma karena monitoring-nya boros.

Komunitas dan Ekosistem: Seberapa Sehat Proyek Ini?

Teman-Teman, satu indikator penting buat alat open-source itu komunitasnya. Alat yang bagus tapi komunitasnya mati bakal susah diandalin jangka panjang. MUGHU biasa cek beberapa hal: GitHub repo activity, issue response time, dan apakah ada kontributor selain maintainer utama.

Beszel di GitHub nunjukin aktivitas yang konsisten. Pengembang utama, henrygd, aktif merespon issue dan pull request. Ada kontribusi dari komunitas juga—meskipun belum sebanyak proyek-proyek yang udah mateng kayak Grafana, tapi buat proyek yang relatif baru, tingkat partisipasi komunitasnya sehat.

Discord server Beszel juga cukup aktif. Kamu bisa tanya langsung soal masalah setup, minta saran konfigurasi, atau sekadar ngobrol soal best practice monitoring. MUGHU beberapa kali nanya di sana dan selalu dapet jawaban—kadang dari henrygd langsung, kadang dari user lain yang udah pernah ngalamin hal serupa.

Hal yang MUGHU suka dari komunitas kecil kayak gini: kamu nggak hilang di tengah ribuan pesan kayak di komunitas proyek gede. Pertanyaan kamu keliatan, dan orang-orang yang ada di sana emang peduli. Itu nilai plus yang nggak bisa diukur dari angka stars di GitHub.

Kapan Kamu Harus Pertimbangkan Buat Pindah dari Beszel

MUGHU selalu bilang: nggak ada alat yang sempurna buat semua orang. Jadi kapan kamu harus mulai mikir buat pindah dari Beszel?

Pertama, kalau jumlah server kamu udah melebihi 100 dan kamu butuh alerting yang lebih kompleks—kayak alert berdasarkan kombinasi multi-server atau anomaly detection. Beszel belum support itu, dan kemungkinan nggak akan jadi prioritas karena fokus proyek ini memang kesederhanaan.

Kedua, kalau kamu butuh custom metrics—metrik spesifik dari aplikasi kamu yang nggak standar. Beszel pantau metrik sistem dan Docker, tapi kalau kamu butuh pantau metrik bisnis kayak "jumlah transaksi per menit" atau "latency API endpoint spesifik", kamu butuh sesuatu yang lebih fleksibel kayak Prometheus.

Ketiga, kalau tim kamu butuh dashboard yang bisa di-custom dengan bebas—bikin panel khusus, gabungin data dari multiple source, atau bikin visualisasi yang kompleks. Grafana di area ini emang juara dan sulit ditandingi.

Tapi ingat, "pindah" nggak harus berarti "buang". Banyak tim yang pakai Beszel sebagai monitoring harian buat cek cepat, sambil maintain Prometheus + Grafana di belakang buat analisis mendalam. Keduanya bisa coexist tanpa masalah. Beszel nggak marah kalau kamu pakai alat lain juga—dia cuma agent kecil yang ngumpulin data dan nampilinnya dengan rapi. Suka-suka kamu mau pakai apa lagi di sampingnya.

Kesimpulan

Beszel bukti nyata bahwa alat monitoring nggak harus berat dan rumit buat berguna. Dengan footprint yang nyaris nggak kepakuan di server kamu, dia ngasih visibilitas yang kamu butuhin—CPU, RAM, disk, network, sampe container Docker—tanpa maksa kamu upgrade plan VPS cuma buat jalanin alat monitoringnya. Buat solo developer, tim kecil, atau siapa pun yang manage antara 1 sampe sekian puluh server, ini equation yang susah ditolak: lebih sedikit resource buat monitoring, lebih banyak resource buat aplikasi yang sebenarnya jalan di atasnya.

Yang MUGHU pahami selama pakai Beszel itu, filosofi "cukup" ini punya nilai nyata. Nggak semua orang butuh Grafana dengan 47 panel dan alerting berlapis-lapis. Kadang yang kamu butuhin cuma jawaban cepat buat "server aku sehat nggak?" dan "kenapa CPU tiba-tiba naik jam 3 pagi?" Beszel jawab itu dalam hitungan detik, dari dashboard yang bersih dan gampang dibaca. Dan ketika kamu udah tumbuh sampe butuh sesuatu yang lebih—Prometheus, custom metrics, anomaly detection—Beszel nggak nghalangin. Dia bisa tetap ada sebagai lapisan pertama yang cepat, sementara alat yang lebih berat nangani analisis mendalam.

Satu hal yang patut kamu ingat: alat terbaik bukan yang paling lengkap, tapi yang paling cocok buat konteks kamu. Kalau kamu baru mulai bangun infrastruktur, atau udah muak dengan monitoring stack yang butuh satu server sendiri cuma buat jalan, coba aja Beszel. Install-nya cuma butuh beberapa menit, dan kamu langsung dapet akses ke dokumentasi resmi Beszel di GitHub buat eksplorasi lebih jauh. Baca, coba, lalu tentuin sendiri—apa kamu butuh kereta tempur, atau cukup sepeda motor yang lincah.

Baca juga Bonsai 27B: Model AI 27 Miliar Parameter Pertama di Ponsel

Referensi

Beszel. (2026). Simple, lightweight server monitoring.

GitHub. (2026). Lightweight server monitoring with historical data, Docker statistics, and alert functions.

Beszel. (2026). What is Beszel?

Virtualization Howto. (2026). I Replaced My Monitoring Stack and This Just Works in My Home Lab.

GitHub. (2026). Beszel readme.

YouTube. (2026). Beszel: The easiest monitoring solution you've probably never heard of.

XDA Developers. (2026). I finally replaced Grafana and Prometheus with Beszel.

DEV.co. (2026). Beszel: Lightweight self-hosted server monitoring.

Ivan Salloum. (2026). How to run Beszel for server monitoring.

XDA Developers. (2026). This free and open-source lightweight server monitor changed how I keep an eye on my home lab.