Log-driven detection in Go, with bans enforced by bouncers
CrowdSec is a detection engine written in Go. It reads logs, from SSH or NGINX for instance, and matches them against scenarios that describe attacker behavior, such as brute force. A scenario that fires produces a decision, usually an IP ban, and remediation components called bouncers enforce it in the firewall or the reverse proxy. The AppSec component adds a WAF on top. Every engine that reports its alerts gets a community blocklist of malicious IPs back.
The README sets CrowdSec apart from fail2ban on two points: detection and blocking can run on different machines, and an IP reported by one user gets blocked for everyone else. BunkerWeb takes the reverse proxy's place and filters with ModSecurity and the OWASP CRS; its CrowdSec plugin makes it one more bouncer. open-appsec plugs into NGINX, Kong, APISIX or Envoy and scores requests with machine learning.
The open source WAF comparison weighs this shared reputation against OWASP rules and trained models.
Split detection and blocking; ModSecurity rules load unchanged
- Detection and blocking live apart: the local API holds the decisions, each bouncer enforces them wherever it runs, and several machines can ship their logs to the same instance.
- Your ModSecurity rules, as they are: AppSec is built on Coraza and loads SecLang rules and the OWASP Core Rule Set without conversion.
- A blocklist shaped by what you watch: the community list follows your installed scenarios, so a WordPress server also gets the IPs that go after WordPress.
- Setup starts from what's running: CrowdSec tries to detect the services on the host and installs the matching Hub rules.
Alert metadata leaves the host; contributors get a larger blocklist
Instances send metadata, not logs. For each alert, the engine sends CrowdSec's central API the scenario name, hash and version, a timestamp, the machine ID and the offending IP, geolocated when possible. Only unmodified Hub scenarios are covered; an instance enrolled in the console also sends custom scenarios and manual decisions. Commenting out the online_client section of the config stops the exchange, and the blocklist with it.
Blocklist size depends on what you share. A free instance that reports signals regularly gets 15,000 IPs; the rest get the Lite version, capped at 3,000. A scenario you wrote or tweaked yourself doesn't count. The docs name two reasons an engine lands on Lite: self-hosted services used by a small circle, and setups already locked behind a VPN, geoblocking or OAuth. Paying customers get up to 60,000 IPs whether they contribute or not.
The free console has quotas. The web console is optional and hosted by CrowdSec. On the Community plan it shows 500 alerts a month over two months of history, for one user and three blocklist subscriptions. Past that, new alerts stay hidden in the console until the 1st of the month.
Premium is billed per enrolled engine, with no published price. It adds decision sync across instances, centralized allowlists, console API access, filtering of internet background noise, a blocklist built from your organization's own signals, and up to a year of history. The engine, the Hub and the official firewall, NGINX and HAProxy bouncers are MIT licensed.
The engine alone blocks nothing. You need at least one bouncer, and for the WAF one that forwards requests to it: NGINX, OpenResty, Traefik, HAProxy or Envoy. SQLite is the default database; the docs recommend MySQL, MariaDB or PostgreSQL for a busy local API.
Bot detection is alpha. Added in v1.8.0, it needs visitors to run JavaScript and accept cookies, and an arm64 host, or amd64 with SSE4.1, that allows executable memory. Otherwise CrowdSec won't start.
Six stable releases in 2026. Eleven shipped in 2025. The latest, v1.8.1, came out on September 3, 2026, three days after a v1.8.0 that fixed two denial-of-service vulnerabilities.