Introducing Jabali Sounder: one control plane for many Jabali Panels

Download

Pick your platform. Every link is the current release — no version to track.

Server one-liner

curl -fsSL https://raw.githubusercontent.com/shukiv/jabali-sounder/main/install.sh | sudo bash

Other formats

• Windows portable — jabali-sounder-windows-amd64-latest.exe
• macOS portable (Apple Silicon) — jabali-sounder-macos-arm64-latest
• Linux portable — jabali-sounder-linux-amd64-latest
• Android AAB — jabali-sounder-android-latest.aab
• checksums.txt — SHA-256 for every artifact
• Full release notes on GitHub

Jabali Panel manages one server. Jabali Sounder is what you use when you have more than one.

The one-boar problem

A single Jabali Panel install is deliberately opinionated — one panel, one server. That’s the right shape for a shared host, a personal box, or a small agency running a handful of sites. It’s the wrong shape when you have ten servers, twenty, a hundred.

Every previous approach to this problem ends up in the same place: SSH into each box, run the same command, tail the same log, drift between installs, forget which box has which cron. Ansible improves the ergonomics but you still don’t have a live UI for the fleet.

Sounder is the answer.

What Sounder is

Sounder is a central control plane for a fleet of Jabali Panel servers, driven entirely through the panel HTTP API.

That’s the important part. Sounder does not SSH into your managed servers. It doesn’t require sudo or root. It calls the same HTTP endpoints the panel’s own UI calls, over HTTPS, authenticated with a scoped HMAC automation credential you generate inside each panel.

The name is a small joke. A sounder is the collective noun for a group of wild boars. Jabalí is Spanish for boar. The panel is a single boar; the sounder is the herd.

Ships today

The current implementation ships with:

Admin login and JWT-protected API access. Standard bearer-token session with a per-admin JWT. All Sounder-side actions are session-authenticated.

Managed server enrollment with HMAC automation credentials. Add a panel by its URL. Paste the HMAC key that the panel generated on its automation-api screen. Sounder verifies the credential, health-checks the endpoint, and adds the server to the fleet.

Server health checks and dashboard status. Sounder polls each enrolled panel’s /health endpoint on a cadence and rolls the results up into fleet-level SLA figures on the dashboard. A single server marked “policy issues” surfaces to the top-level counter.

Cross-server domain and user inventory. One search box across the whole fleet. Find a domain regardless of which server it lives on. See all users grouped by server. Export the flat inventory as CSV or JSON.

Monitor tab with live metrics. CPU, RAM, IO, load average, and summary disk / account / domain data for every enrolled server. Live means live — Sounder subscribes to per-server status streams and updates the tiles without a page reload.

Mail tab. Mailboxes, forwarders, domain forwarders, groups, and autoresponders per server. This tab is ready on the Sounder side; it needs the corresponding automation mail endpoints to be available on the managed Jabali Panel, which is the current work in flight on the Panel side.

Standalone Wails desktop target. Windows, macOS, and Linux binaries. Local SQLite storage. First-run admin setup. A single operator can drive their fleet from their own machine without deploying a Sounder server anywhere.

Why HTTP API, not SSH

The obvious way to manage a fleet is to shell into each box and run scripts. That approach has three problems that get bigger with each server you add:

1. Attack surface. SSH keys have to live somewhere. Every operator machine, every CI runner, every jump box multiplies the exposure. HMAC credentials in Sounder are scoped per-panel, revokable per-panel, and never leave the panel-to-Sounder pair.
2. Reversibility. SSH gives you unbounded authority. HTTP endpoints only expose the actions the panel’s own admins can perform. The blast radius of a compromised Sounder is capped at what the panel’s normal admin UI can do.
3. Auditability. Panel HTTP calls are already logged, throttled, and versioned. Shell commands are none of those things.

What Sounder is not

It’s not a hypervisor. Sounder doesn’t manage VMs, containers, or the OS. It’s not a monitoring product — it exposes per-server metrics but it isn’t Prometheus. It’s not a config manager — it doesn’t push Nginx conf files or systemd units. Those are Panel’s job on each server. Sounder is the operator UI for coordinating panels; the panels do the coordinating with the OS.

Try it

Grab the desktop binary for your platform above, or run the server build. Enroll a panel by pasting its URL and an HMAC credential.

For a live look at the Panel side that Sounder drives, the Jabali Panel demo is open — sign in as admin and open the automation-api page to see the credential format.