Repository navigation
feat: Caddy Defender #1843
Description
include a new security module for Caddy Defender
https://defender.jasoncameron.dev/installation/#using-xcaddy
Discussion: should settings be set globally? Would that be too "general"? Allow users to turn on and off the module within Cerberus, but control settings per host within the host setup / edit page? Similar to ACL.
Option 1, in the Caddy Defender "config" page, a user can create "presets" as to which IP ranges are assigned and then within the proxy host page the user can assign that preset to the host in a drop down.
Option 2, Just provide the ability to enable / disable the module in Cerberus and provide a section within within the host page to select the desired IP ranges that are active on the host.
Option 1 hides the config area, option 2 clutters the host form. Will need to research more into the Caddy Defenfer module to see what is best for UX and what the code setup is like before final decision.
I'd hate to reinvent the wheel but option 3 would be build our own bot blocker. UX comes first.
Metadata
Metadata
Assignees
Projects
- Status
Activity
Wikid82 commentedon Nov 5, 2026
Shape: it fits as a new Cerberus module like ACL or WAF. It's a plugin, so it means a custom xcaddy build. That is a supply-chain and image-size cost, and the plugin's maintenance and Caddy version pinning would need checking.
UX: Option 1, presets of IP ranges (cloud providers, AI crawlers, VPNs) assigned per host from a dropdown, as ACL already does. The module has its own Caddy handler, so the per-host config is just the preset's ranges plus a response action.
Overlap: it overlaps with CrowdSec bot detection and ACL IP lists. Its niche is blocking by provider range. Look at whether a built-in preset of ranges on top of the existing ACL machinery gets 80% of it with no new dependency. That is option 3, and it might be cheaper than it sounds.