WGCLOUD: A SpringBoot Host Monitoring Stack With an Open Core Boundary

What WGCLOUD Collects, and the Audience It Targets

WGCLOUD is a host and service monitoring system for Linux, Windows, macOS and Unix fleets. The README lists the collection surface explicitly: CPU usage and temperature, memory usage, disk capacity, disk IO read and write rates, disk IOPS, disk SMART health, system load, MAC address, connection counts, NIC traffic, hardware and BIOS and motherboard and PCI information, GPU, firewall state, crontab, recent login records, Windows service lists, running processes, listening ports, and IPMI. On top of host metrics it monitors processes, file integrity, ports, logs, Docker containers, databases and tables, service APIs, and network devices such as switches, routers and printers.

The intended user is an operations team that wants a web console rather than a metrics pipeline. The README frames the design as a minimal monitoring system with fast deployment, no templates and no scripts, and describes the collection component as fully automatic. That framing matters because it sets the product's centre of gravity: breadth of built-in checks and a UI, not composability. If your monitoring strategy is to assemble exporters and dashboards yourself, most of what WGCLOUD ships is already solved elsewhere, and the parts that are not (web SSH, batch command dispatch, asset records, password storage) are the parts you would actually be buying.

Server, Agent, and a Two Minute Reporting Interval

The architecture is a server and agent pair. The server receives data, processes it, and generates charts for display. Each agent reports host metrics on a default interval of two minutes, and the README states that interval is adjustable. The README also claims the pair supports several thousand hosts online simultaneously, which is a design target rather than something this article can confirm.

A significant change landed in v2.3.7: the project abandoned sigar for host metric collection and moved to OSHI. That is worth noting beyond a changelog entry, because OSHI is a JVM library, so the agent inherits JVM behaviour on every monitored host. It also explains the platform list, which spans Debian, RedHat, CentOS, Ubuntu, Fedora, SUSE, Kylin, UOS, Loongson mips, Windows Server 2008 R2 through 2025, Windows 7 through 11, Solaris, FreeBSD, OpenBSD, macOS on amd64 and arm64, plus ARM, Android, riscv64, s390x, Raspberry Pi and AIX. That breadth comes from OSHI's platform coverage rather than from per-platform shell scripts.

The stack is SpringBoot with Bootstrap on the front end. The README describes the communication diagram as HTTP. In practice that means the agent initiates outbound HTTP to the server, which simplifies firewall rules in one direction: monitored hosts need egress to the server, and the server does not need to reach into each host. The trade-off is that the agent is a Java process resident on every machine. On a small fleet that is unremarkable. On hosts where you already fight for memory, a JVM agent reporting every two minutes is a real line item, and the interval is the knob that controls it.

Building the Server and Agent From master

The README gives source instructions that assume an IDE rather than a scripted build. With IntelliJ IDEA, which the README recommends, open the wgcloud-server and wgcloud-agent modules directly. With Eclipse, import them as Maven projects. Both paths require JDK 1.8 or JDK 11.

The database step is explicit. WGCLOUD uses MySQL, and the SQL scripts live in the sql folder. The README instructs you to create a database named wgcloud in MySQL and import wgcloud.sql into it. The stated database support is MySQL 5.5 and above, MariaDB, PostgreSQL and Oracle, so the MySQL path is the documented default and the others are listed as supported rather than demonstrated in the README.

For running rather than developing, the bin directory holds start and stop scripts for both server and agent on Linux and Windows. The README notes that these scripts should sit in the same directory as the packaged wgcloud-server-release.jar. That is the whole deployment story in the README: one jar, one script directory, one database. There is no Helm chart, no Docker Compose file and no systemd unit documented in the material provided, which is a gap if you expect to deploy this the way you deploy other SpringBoot services. The README also states that master is the branch to pull for secondary development, and that the repository is the open source edition.

The Open Core Boundary Is Documented in the README

The README is unusually direct about this. It states that the commercial edition is downloaded from the official site, that the commercial edition can be used free of charge but is not open source, and that production environments are advised to deploy the commercial version because it has more features, better performance, better security, more stability, more active version updates and better support. The repository itself is described as the open source edition.

Read that as a product statement rather than marketing noise, because it changes how you evaluate the code. The open repository is positioned as a learning and secondary-development base. The feature list in the README, which includes AI analysis, inspection reports, big screen visualisation, topology generation and asset management, is the product's feature list, not necessarily a verified inventory of what the open source build contains. Anyone planning to run this in production on the open edition should map each feature they depend on against the actual repository contents before committing, and treat the README's own recommendation as a signal about where effort is invested.

This is the single most important thing to understand about WGCLOUD. It is not a case where an open core exists alongside a hosted service. It is a case where the vendor explicitly recommends the closed build for the use case most readers have in mind.

Where WGCLOUD Is the Wrong Tool

The two-minute default interval is the first constraint. A monitoring system that samples every 120 seconds cannot describe a spike that lasts thirty seconds. If your incident review depends on sub-minute resolution, or on histogram and percentile queries over raw samples, this interval is a floor you would have to lower, at the cost of more agent CPU and more server-side write volume. The README does not document retention, downsampling or storage sizing, so capacity planning for a large fleet has to come from your own measurements.

The second constraint is the MySQL dependency. The server writes to a relational database. Long-term metric storage in MySQL is workable at moderate scale and awkward at large scale, and the README offers no guidance on partitioning, archival or what happens when the metrics tables grow. Teams used to time-series databases with retention policies will find this a different operational shape.

The third is the agent model itself. A JVM process on every monitored host is a different proposition from a single static binary or a push-only script. It also means the agent is a privileged local process with a network path to a central server, and the README's own recommendation of the commercial edition for security reasons is worth weighing rather than dismissing. If you need to monitor an environment where installing a persistent Java agent is prohibited, this design does not fit.

WGCLOUD Against Prometheus and Zabbix

The README's own topic list names prometheus, zabbix, nagios, grafana-dashboard and snmp-agent, so the project places itself in that company. The comparison is worth making concretely, because the difference is architectural rather than a feature checklist.

Prometheus pulls. It scrapes HTTP endpoints on a schedule you configure, stores samples in its own time-series database, and leaves alerting to Alertmanager and visualisation to Grafana. Adding a new metric source means running an exporter. WGCLOUD pushes. The agent sends to the server, the server owns the database and renders the charts, and there is no separate query language or dashboard tool to learn. That is the trade: Prometheus gives you a query language, composable exporters and a storage engine built for time-series data; WGCLOUD gives you a working console and a fixed set of checks with nothing to assemble.

Zabbix is closer in shape, with agents and a server and a web front end, but Zabbix's model is built around templates and items that you configure. WGCLOUD's stated design goal is the opposite: no templates, no scripts, automatic collection. If you have ever spent a week writing Zabbix templates for a heterogeneous fleet, that pitch lands. If you need per-item control over what is collected and how, the absence of a template system is a limitation rather than a feature.

There is also the question of what WGCLOUD bundles that the others do not. Web SSH, batch command dispatch, password management and work notes are operations-console features, not monitoring features. They are the reason someone picks this over a metrics stack, and they are also the features most likely to differ between the open and commercial editions.

Licence, Maintenance, and What to Check First

The licence is Apache-2.0. That permits commercial use, modification and redistribution under the terms of that licence, and it is a permissive choice rather than a copyleft one. It applies to the code in this repository. The commercial edition is a separate product under separate terms, and the README states plainly that it is not open source. Nothing here is legal advice; if you plan to redistribute a modified build or embed it in a product, read the licence text and confirm which artefacts it covers.

Maintenance cadence is visible from the release history. v3.7.0 arrived on 2026-09-03, v3.6.9 on 2026-08-01, and v3.6.8 on 2026-05-31, with the last push to the repository on 2026-09-04. That is a roughly monthly rhythm across the three most recent releases, with a longer gap before v3.6.8. The README does not describe an upgrade procedure, a database migration path between versions, or a compatibility policy for agents and servers running different versions. That absence is the practical cost: with a MySQL schema in the sql folder and a server that owns the data model, version upgrades are the operation you should rehearse on a copy before touching anything you depend on.

One inconsistency is worth flagging because it affects which code you get. The README describes the repository as the open source edition at v2.3.7, while the release list shows v3.7.0 as the most recent tag. The README text appears not to have been updated in step with the releases. Confirm the version of the code you actually pull from master rather than trusting the README's version string.

Editorial conclusion

Adopt WGCLOUD if you want one SpringBoot process plus a small agent per host, a web UI, and you accept that the README steers production deployments toward the closed commercial edition. Do not adopt it if you need to read the whole thing, or if you already run Prometheus and only want metrics. Before committing, verify three things: which features exist in the open repository rather than only in the commercial build, whether the agent can reach the server over your network, and whether the MySQL schema in the sql folder matches the server version you build from master.

Official sources

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