WGCLOUD pairs a SpringBoot server with a two minute polling agent

One agent per host, one report every two minutes

Monitoring here runs on a timer. WGCLOUD splits into a server that accepts data, processes it and renders the charts, and an agent that runs on each monitored host. That agent reports host metrics every two minutes by default, and the interval is adjustable. The design goal stated in the project is a minimal monitoring system that deploys quickly, runs without templates or scripts, and lowers the learning curve for operations staff. It is built on SpringBoot with Bootstrap, described as a lightweight distributed system on a microservices architecture. The scale claim is thousands of hosts online at the same time, with no sizing notes, memory settings or database tuning guidance next to it. The number to hold on to is therefore the cadence rather than the scale.

v2.3.7 swapped sigar for OSHI inside the agent

Collection used to depend on sigar. Version v2.3.7 dropped that approach and moved to the OSHI component to gather host metrics, which is the most consequential line in the README for anyone maintaining a fork: the collection layer is a Java library choice, and it lives in the agent rather than the server. What the agent is expected to return covers a wide surface. CPU usage and CPU temperature, memory usage, disk capacity, disk IO read and write rate, IOPS, SMART health state, system load, MAC address, connection counts, network interface traffic, hardware and BIOS information, motherboard information, PCI devices, GPU state, firewall status, crontab, recent login records for system users, Windows service lists, running processes, listening ports, and server IPMI monitoring. That list is a statement of coverage, not a promise of accuracy on any particular disk or chassis.

Building means two Maven modules and one imported schema

There is no install command anywhere in the repository, so deployment starts from source. In IDEA, which the README recommends, you open the two modules directly; in Eclipse you import wgcloud-server and wgcloud-agent as Maven projects. Both paths assume JDK 1.8 or JDK 11. Next you create a database named wgcloud in MySQL and import wgcloud.sql from the sql folder, then keep the start and stop scripts from bin in the same directory as the packaged wgcloud-server-release.jar. The repository root shows what you are assembling:

bin/
sql/
wgcloud-server/
wgcloud-agent/
docker/
k8s/

The runtime matrix is wider than the build instructions: MySQL 5.5 or newer, MariaDB, PostgreSQL and Oracle are all named as supported databases, yet the only schema walkthrough is written for MySQL.

The open branch says v2.3.7 while the tags reach v3.7.0

Two version lines are visible and they do not match. The README calls this repository the open source edition at v2.3.7 and points secondary developers at the master branch, which is the default branch. The release tags tell a different story: v4.0.1 was published 2026-10-25, v3.7.0 on 2026-09-03 and v3.6.9 on 2026-08-01, with the last push on 2026-10-25. Nothing states which of those the open tree contains, so a reader who unpacks a release and a reader who clones master may not be running the same code. Settle that first, before judging anything else. A smaller signal in the same paragraph: the project advertises itself as needing no templates and no scripts to run, and then ships start and stop scripts for Linux and Windows in bin. Both can be true, and together they tell you how much assembly the operator is left with.

Docs, downloads and the feature list live on a separate site

The documentation is not in the repository. The README routes readers to www.wgstart.com for online documentation and downloads, to a different page for the online demo, another for the feature list, another for small online tools, and further pages for contact and sponsorship. Nothing in the tree is documentation: there is no docs directory, no operations guide, and no schema description beyond the SQL file itself. The questions that decide an adoption, such as how authentication works, how alerts reach email, DingTalk, WeChat or SMS, and what the automatic analysis actually produces, can only be answered off that site. Apache-2.0 covers the open edition, and that licence says nothing about the commercial edition the project recommends for production. Read the licence and the feature list as two separate documents, because only one of them is in the repository.

Web SSH and dispatched commands make the agent a control surface

The feature list reaches well past observation. It includes web SSH described as a bastion host, batch command dispatch, file anti-tamper checking, scheduled tasks, automatic device discovery, automatic network topology generation, a large screen view, inspection reports, asset management, middleware monitoring and automatic analysis. Installing something like that is a decision about remote access, not only about dashboards. An agent that can be reached over web SSH, that executes commands sent from the server, and that watches files for changes holds meaningful authority on every machine it runs on. The project itself recommends the commercial edition for production because it has more features, better performance, better security, more stability and more active releases. The open repository documents neither the authentication model behind those features nor any audit trail for dispatched commands, which is the part to settle in your own environment.

Platform support is a name list, not a list of artifacts

Agents are said to run on Linux distributions including Debian, RedHat, CentOS, Ubuntu, Fedora, SUSE, Kylin and UOS, plus Loongson on mips; on Windows Server 2008 R2 through Windows 2022 and Windows 2025, and Windows 7 through 11; on Solaris, FreeBSD and OpenBSD; on macOS for both amd64 and arm64; and on ARM, Android, riscv64, s390x, Raspberry Pi and AIX. Nothing in the repository maps those names to build outputs, packages or images, so the work of supporting an unusual platform, an arm64 or mips host for instance, begins before you hold a binary. The docker directory and the per topic folders in the tree, crontab, daping, demo, firewall, k8s, log, nginx, process, redis, shell and GPU, hint at the shape of the code. The packaging story is left to the website.

Editorial conclusion

WGCLOUD fits teams that want a self hosted dashboard and are willing to compile a SpringBoot server and run an agent on every host. It does not fit a team that wants a documented install from a repository, because the repo carries no install command and points at a separate site for docs and downloads, and it does not fit a production buyer who needs what the commercial edition advertises. Before you commit, settle which version you are actually getting, since the open branch calls itself v2.3.7 while the release tags reach v4.0.1 from 2026-10-25.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. tianshiyeben/wgcloud on GitHub