SysWarden.
More than a destination.
A journey.

CHAPTER 01

It began with a list of addresses.

Before there was a roadmap, there was a practical question. I was maintaining Data-Shield IPv4 blocklists, and I wanted those lists to become useful as close as possible to the place where Linux handles network traffic. Could I bring that intelligence directly into the kernel's filtering layer, with a tool I could understand, operate and improve myself? That question became SysWarden.

The first commit in the public repository is dated February 9, 2026. Looking back at it now, I see the beginning of a conversation between an idea and reality. A list can tell you which addresses deserve attention. Turning it into dependable protection raises other questions: how to update it, how to preserve access, and what to do when an input is wrong.

CHAPTER 02

A direction of my own.

I did not start SysWarden to compete with CrowdSec, or to prove that another security project should not exist. My motivation was more personal: technological independence and the freedom to build a defense whose behavior I could inspect and explain.

For me, that freedom is practical. It means readable source code, visible decisions and an operator who remains in control. It means being able to understand why an address was blocked, to question that decision, and to choose how a system is run. Open source makes that possible, but publishing code is only the beginning. Documentation, predictable upgrades and honest boundaries are what make that freedom usable by someone else.

CHAPTER 03

Then the tool started asking more of me.

The repository's history tells the story in small steps. Installation and updates needed attention. A command that worked on my machine had to make sense on another distribution, under another firewall frontend, with another operator at the keyboard. Each version brought the project closer to real installations, and each installation brought questions that a blocklist alone could never answer.

SysWarden grew into a chain: observe signals, decide what they mean, apply a policy through Linux firewall mechanisms, and keep evidence of the result. Host logs and application events joined threat feeds. Operator interfaces and reporting became part of the work. That growth did not erase the original idea. It gave it responsibilities. Once software can change a firewall, correctness includes knowing when to leave it alone.

CHAPTER 04

The moment other people joined the story.

Some of the most useful steps forward began with a message rather than a feature proposal. A user needed monitoring pings without a stream of Discord notifications. Another wanted personal IPv4 and IPv6 blocklists to complement the existing feeds. Those requests were reminders that a security tool lives inside someone else's habits, constraints and working day.

Stephane Robert went further: he replayed installations in disposable laboratories and documented what he observed. His Debian SSH tests separated two parsing differences, the timestamp format and the process name. A line that looked obvious to a human could pass unnoticed by a detector expecting another form. His feedback also exposed the cost of documentation that describes a future version without saying so clearly. A reproducible report gives us something precise to fix.

This is the community I want around SysWarden: people who try it, question it and bring evidence. An operator who can explain what happened matters.

CHAPTER 05

Meeting BunkerWeb, without losing the thread.

The work with BunkerWeb opened another chapter. Here were two French open-source projects approaching protection from different positions. BunkerWeb sits in the request path, where a web application firewall can inspect traffic before it reaches an application. SysWarden works out of band, observing signals and making host-level decisions without becoming another mandatory proxy in that path.

Connecting those perspectives is a way to build defense in depth. An application-facing layer and a host-facing layer can contribute different evidence and actions, provided their responsibilities stay clear. Independence does not mean isolation. We can keep our own design choices and still build useful bridges with other maintainers. Our previous article tells that story.

CHAPTER 06

Why the next release takes more than a version number.

As I write this on September 23, v4.04.3 is the qualified stable release. The v4.10.0 source is available, but qualification of its public release is still in progress. That distinction matters. A commit, a signed package and a fully qualified release are different milestones; I do not want readers to mistake one for another.

The v4.10.0 work brings authenticated high availability, richer evidence and reporting, and native packaging across several Linux families into the same release effort. Other commits show less glamorous work: correcting log discovery, reducing repeated validation costs, and recovering verifiable signing evidence when an earlier archive expired. These changes are part of delivering software that can be operated, upgraded and investigated.

The difficult part is asking the whole system to prove itself. Does a migration preserve configuration? Can an operator recover after a failed step? Does a block really reach the kernel, and does its expiry remain visible in the record? Performance belongs in those questions too. We have kept the agreed 10 percent regression ceiling instead of changing it to make a candidate pass. When a measurement fails, the next step is a correction and another measurement, not a more convenient description of the result.

CHAPTER 07

The next chapter already has a shape.

The v5.00.0 roadmap takes that experience further. Its proposed sequence is simple to read and demanding to implement: detect, explain, contain, prove and roll back. The planned work includes file integrity, deterministic incident correlation, reversible responses with signed evidence, and a clearer interface for several nodes. Human approval remains central to the response model.

Community requests are part of that plan too: custom feeds alongside Data-Shield, SHA-256 sidecar support, and systematic coverage of bundled signatures. A maintenance and LTS policy also needs an explicit support model, rather than a label added to a release name. These are planned work packages, not features I am claiming to have delivered. The public roadmap makes the scope discussable and gives contributors and potential funders a concrete place to start.

CHAPTER 08

Keeping the journey possible.

There is a human cost behind every green check. Someone has to reproduce the report, write the fix, run the laboratory, review the evidence and explain the result. Infrastructure and tools have a cost too. Financial support gives me room to spend time on that work, including the unremarkable checks that rarely appear in a release announcement but make the release worth trusting.

If SysWarden is useful to you, a donation through PayPal helps sustain that effort. It supports time for maintenance, testing and documentation, as well as the next chapters of the project. It does not buy a shortcut through qualification or a promise that every roadmap item will arrive on a particular date. Sharing a careful bug report, improving a guide or helping another operator also moves the project forward.

I began by wanting to put my blocklists to work in the Linux kernel. Today, I am building something larger with people who care enough to test it and tell me the truth. A release is an important destination. The journey is how we make it worth reaching.