A Note from Zima
Thank you, Jacko88888, for building tools that help ZimaOS users understand what is actually happening inside their systems. From evidence-first diagnostics with ZimaBrain CE, to controlled malware scanning with ClamAV, to endpoint monitoring with Wazuh, your projects keep turning complex system layers into things people can inspect, question, and act on more carefully.
We especially appreciate seeing these ideas develop through real troubleshooting, testing, and community feedback. They are a reminder that making a home server easier to use is not only about adding more features — sometimes it is about making the system easier to understand.
— Zima
Meet Jacko88888
Jacko88888 has been building and documenting practical tools around ZimaOS, with much of his work focused on one recurring question: how can a home-server user understand what is actually happening inside the system?
His public projects approach that question from several directions. ZimaBrain CE explores evidence-based local diagnostics. The ClamAV Security Dashboard makes malware scanning and quarantine easier to inspect and control. And Wazuh on ZimaOS brings endpoint monitoring, agent state, and security alerts into the picture.
They are different projects, but they point in a surprisingly consistent direction: diagnose what is happening, make security activity visible, and give the person running the server enough evidence to decide what to do next.
Building a Local Diagnostic Assistant for ZimaOS
One of Jacko88888's most ambitious ZimaOS projects is ZimaBrain CE, a local diagnostic assistant built around a simple principle: verify the evidence before suggesting what might be wrong.
Home-server problems rarely belong to just one layer. A storage warning can involve SMART data, filesystems, mount points, or hardware. An application that will not open might actually be running correctly while its port, firewall rule, or network exposure is the real problem. Docker state, failed services, disk health, and ZimaOS configuration can all overlap.
ZimaBrain CE was built to make that troubleshooting process more structured. Rather than starting from an assumption and immediately recommending a fix, it gathers evidence from the ZimaOS host and tries to establish what can actually be verified.
That means looking beyond simple top-level states. Disk diagnostics can consider SMART evidence such as pending or uncorrectable sectors, CRC counters, command timeouts, and NVMe unsafe shutdown information. Other diagnostic layers can inspect Docker state, published ports, firewall configuration, failed services, mount points, AppData paths, and other host signals.
Verified, Partially Verified, or Not Yet Proven
An important part of ZimaBrain CE is that it does not try to make every answer sound equally certain.
The project distinguishes between conclusions that can be verified from the available evidence, findings that are only partially verified, and guidance for situations where the system cannot safely prove enough yet.
That distinction matters when troubleshooting a self-hosted server. Advice involving disks, filesystems, containers, firewall rules, or system services can become destructive very quickly when the original diagnosis is wrong. A verifier-first approach deliberately puts evidence before action.
The project can also generate a redacted support report, giving users a way to share useful diagnostic information when asking for help without simply publishing every piece of raw system data.
Built Around the ZimaOS Host
ZimaBrain CE is designed to run locally as a ZimaOS Custom App. Its diagnostic role depends on being able to inspect selected information from the host, including system state and Docker information, rather than relying only on details manually entered by the user.
That makes the project different from a generic troubleshooting chatbot. The useful part is not simply producing an answer. It is connecting that answer to evidence from the ZimaOS system being diagnosed.
Growing Through Community Feedback
ZimaBrain CE also shows how community software can evolve through collaboration. Jacko credits Holger / Lintux for helping shape ideas around verifier-first diagnostics, evidence layers, security awareness, firewall checks, SMART interpretation, and safer diagnostic flows.
ZimaOS users have continued that process by testing the project on their own systems and reporting where an answer was useful, where it was still too technical, and where the verifier needed more evidence before drawing a conclusion.
That makes ZimaBrain CE more than another utility sitting on top of ZimaOS. It is an experiment in making home-server troubleshooting more explainable: show what the system can verify, say what remains uncertain, and avoid turning an uncertain diagnosis into an unsafe action.
Turning ClamAV into a ZimaOS Security Dashboard
With the ClamAV Security Dashboard, Jacko takes the ClamAV malware-scanning engine and builds a more deliberate ZimaOS workflow around it.
The project starts with storage rather than a command line. It discovers ZimaOS disks and folders, lets the user explicitly approve which locations should be scanned, and keeps sensitive application and system locations away from casual scanning.
Once a scan begins, the dashboard makes the process visible. Instead of simply waiting for a background task to finish, the user can follow information such as the current file, the amount of data already scanned, remaining data, scan speed, elapsed time, and estimated time remaining.
That visibility matters much more on a NAS than it might on a small local folder. A home server may contain photos, backups, downloads, media libraries, application data, and terabytes of other files. Knowing what is being scanned — and what is not — becomes part of understanding the security state of the system.
Keeping Detection Separate from Remediation
One of the more thoughtful parts of Jacko's ClamAV workflow is what the scanner does not do automatically. A normal scan does not modify files, and detecting a suspicious file does not immediately delete it.
Instead, detection and remediation remain separate actions. When ClamAV identifies a threat, the dashboard can expose its file path and detection signature. Moving that file into quarantine requires another confirmed action from the user.
Once a file is quarantined, the application records information including its original location, file size, malware signature, and SHA-256 digest. If the file is later restored, the stored information can be checked before it is returned to its original location.
Permanent deletion remains a separate decision again. The result is a security workflow where scanning, reviewing, quarantining, restoring, and deleting remain visible actions rather than becoming one irreversible automated chain.
Testing the Entire Threat Lifecycle
Jacko also documented an end-to-end validation of the workflow using the harmless EICAR antivirus test file.
The test followed the lifecycle from detection through quarantine, recording the file's original path and SHA-256 digest, restoring it, quarantining it again, and finally permanently deleting it.
The interesting part is not simply that ClamAV detected the test file. Jacko also considered what happens before and after detection — the part of antivirus management that matters when the files being protected actually belong to you.
Bringing Wazuh Security Monitoring to ZimaOS
Jacko's Wazuh on ZimaOS work approaches security from another direction. Instead of focusing on individual files, it documents how to bring Wazuh's endpoint monitoring model into a ZimaOS Docker environment.
The project follows the practical edges of getting that environment to work: checking the Wazuh manager, troubleshooting enrollment through 1515/TCP, connecting the agent to the manager's Docker network, enrolling a dedicated zimaos-docker-agent, and maintaining the ongoing agent-to-manager communication channel through 1514/TCP.
Just as with the ClamAV project, the final goal is not merely to have another container running. The state of the security system should be visible. A working agent can be confirmed in the Wazuh interface, and the security events associated with that monitored endpoint can then be reviewed from the dashboard.
Making the System Easier to Understand
ZimaBrain CE, the ClamAV Security Dashboard, and Wazuh solve very different problems, but the way Jacko approaches them has a common thread.
ZimaBrain asks what can actually be verified before presenting a diagnostic conclusion. ClamAV turns malware scanning and remediation into a visible sequence of decisions. Wazuh makes agent state and security events something that can be checked rather than assumed.
That pattern matters in self-hosting because the person storing the files is often the same person running the containers, maintaining the network, checking disk health, reading alerts, and deciding whether a proposed fix is safe.
In that environment, a tool becomes more useful when it does more than perform a task. It should also help the person running the server understand what the system knows, what it does not know, and what is happening next.
Different Tools, the Same Direction
Seen together, Jacko's projects operate at three different moments in the life of a self-hosted system.
ZimaBrain CE helps diagnose. It works from local evidence to help explain system problems and uncertainty.
ClamAV Security Dashboard helps scan and respond. It makes malware detection, quarantine, restoration, and deletion more visible and deliberate.
Wazuh on ZimaOS helps monitor. It brings endpoint state and security alerts into an interface where they can be reviewed over time.
Diagnose, scan, monitor — different layers of the same larger goal: giving the person running a home server more visibility into what is actually happening.
The Story Is Still Being Written
Jacko88888 and Zima's story is still being written. ZimaBrain CE, the ClamAV Security Dashboard, and Wazuh on ZimaOS already approach three different parts of operating a self-hosted system, but together they point toward the same idea: systems become easier to manage when diagnostics, security activity, and the evidence behind them are easier to see.
As these projects continue to develop — and new experiments appear — this page can continue to grow with them. If you want to see what Jacko builds next, follow Jacko88888's ongoing work on GitHub.
