The standalone agent
The agent is a complete product on its own. Without a controller it reads its configuration from /etc/shieldlist and does everything it does when enrolled, except receive updates and share bans.
Install and watch
curl -fsSL https://repo.lrob.net/apt/shieldlist/shieldlist.gpg -o /usr/share/keyrings/shieldlist.gpg
echo "deb [signed-by=/usr/share/keyrings/shieldlist.gpg] https://repo.lrob.net/apt/shieldlist stable main" > /etc/apt/sources.list.d/shieldlist.list
apt update && apt install shieldlist-agent
stablecarries the releases. There is also adevsuite with our development builds: ahead of the releases, and expected to break.
The package writes a first configuration by itself, only on a first install: the rules it ships with, and an agent.yaml naming the logs this machine actually keeps — it knows where nginx, Apache and LiteSpeed put theirs, on Debian and Red Hat, and the per-site layouts of Plesk, cPanel, DirectAdmin, ISPConfig and CyberPanel.
If you ever need to do it again — after an upgrade brought new rules, or because you started from an empty directory:
shield init # never overwrites; adds what is new
Read what it wrote, add a free pack under /etc/shieldlist/ if you want more, and validate:
shieldlist-agent -t # every problem at once
shieldlist-agent -dry-run /var/log/auth.log # what the rules would have done to this file
shield status # what it would be holding
shield why 203.0.113.9 # the log lines behind one address
Arm it with state: on in agent.yaml and a restart. From then on shield bans, shield lift, shield exempt are the day-to-day; the full CLI is under Agent → Commands.
Later, enrol
Enrolment is not a migration: the same files, plus mode: enrolled and a controller address. The day you have two servers, install a controller and enrol this one — its local configuration is kept, and switching back is one line.