# fail2ban vs CrowdSec

> fail2ban vs CrowdSec compared: architecture, community blocklist, privacy, resources, Docker, Traefik and Kubernetes, licensing, and running both on one server.
>
> Source: https://fail2ban.dev/alternatives/crowdsec/ · Updated 2026-10-25 · Checked against fail2ban 1.1.1
> fail2ban.dev is an independent guide, not the official fail2ban project.

**Pick fail2ban** if you protect one or a few Linux servers and want a local, file-configured tool with ready-made filters for almost every service. **Pick CrowdSec** if you want a community blocklist that stops known attackers before they try, one detection engine feeding many enforcement points (firewall, Nginx, Traefik, Cloudflare), a web dashboard, or native Kubernetes support. Both are free and open source, and they can run side by side.

The core difference is architecture. fail2ban is one daemon that reads logs and runs a ban command on the same machine. CrowdSec splits the job: a detection engine produces *decisions*, a local API stores them, and separate *remediation components* (still widely called bouncers) enforce them wherever you install one. That split is what makes CrowdSec good at sharing — and what makes it more to set up.

## fail2ban vs CrowdSec at a glance

| Feature | fail2ban | CrowdSec |
|---|---|---|
| Detection source | Log files and the systemd journal | Log files, journal, Docker, Kubernetes, cloud sources; HTTP requests via its AppSec WAF |
| Detection logic | Regex `failregex` filters + `maxretry` within `findtime` | Parsers + YAML "leaky bucket" scenarios from the Hub |
| Response | Actions on the same host: nftables, iptables, firewalld, ufw, pf, Cloudflare API, mail, AbuseIPDB… | Decisions sent to bouncers: host firewall, Nginx, Traefik, HAProxy, Cloudflare, Kubernetes ingress… |
| Scope | Single host (can *report* to AbuseIPDB/blocklist.de) | Multi-host via one Local API; optional community blocklist from all users |
| Config style | INI files (`jail.local`, `filter.d`, `action.d`) | YAML files + `cscli` command line + optional web Console |
| Language / resources | Python 3; cost grows with log volume and regex count | Go; separate engine and bouncer processes |
| IPv6 | Yes (since 0.10) | Yes |
| Docker / Kubernetes | Docker images exist; Kubernetes is awkward | Official Docker image, Helm chart, Kubernetes data source |
| Default ban | `bantime = 10m` (`jail.conf`) | `duration: 4h` (`profiles.yaml`) |
| License | GPL-2.0-or-later | MIT (Security Engine); blocklists are a service with usage terms |
| Maintenance | Active, 1.1.1 (Aug 2026) | Active, 1.8.x (2026) |
| Cost | Free | Free engine; paid Console tiers and premium blocklists |

## How fail2ban works

fail2ban tails the logs you point it at. Each **jail** pairs a filter (regular expressions that find failed logins and pull out the IP) with one or more actions. When an address matches `maxretry` times within `findtime`, fail2ban runs the action — usually adding the IP to an nftables or iptables set — and removes it after `bantime`. Everything happens on the local machine, configured in plain INI files, with no external service involved. The full walk-through is on [how fail2ban works](/how-it-works/).

```ini
[sshd]
enabled  = true
maxretry = 5
findtime = 10m
bantime  = 1h
```

## How CrowdSec works

CrowdSec is made of several pieces:

- **Security Engine / Log Processor** (the "agent"): reads logs through *acquisition* configs (`/etc/crowdsec/acquis.yaml` and `acquis.d/`), normalizes them with **parsers**, and feeds events into **scenarios**.
- **Scenarios**: YAML behaviour rules, mostly "leaky buckets". The Hub's `crowdsecurity/ssh-bf` scenario, for example, groups events by source IP with `capacity: 5` and `leakspeed: 10s` — roughly "more than five failures faster than one every ten seconds".
- **Local API (LAPI)**: stores alerts and decisions, and is what bouncers poll. Several engines on several hosts can share one LAPI.
- **Remediation components (bouncers)**: enforce decisions. The firewall bouncer adds IPs to nftables or iptables sets; others plug into Nginx, Traefik, HAProxy, Cloudflare and more.
- **Hub**: the catalogue of parsers, scenarios, *collections* (bundles per service, such as `crowdsecurity/sshd` or `crowdsecurity/nginx`) and bouncers, installed with `cscli`.
- **Central API and blocklists**: if you enroll, your engine shares signals and receives a **community blocklist** of addresses other users have caught.
- **Console**: an optional web dashboard (app.crowdsec.net) for alerts, multiple engines and extra blocklists. A free tier exists; more features are paid.
- **AppSec**: a built-in WAF component (based on Coraza, compatible with ModSecurity rules and the OWASP Core Rule Set) that inspects HTTP requests passed to it by a supported bouncer.

On Debian or Ubuntu, a minimal install is the CrowdSec repository, the engine and a firewall bouncer:

```bash
sudo apt install crowdsec crowdsec-firewall-bouncer-nftables
```

```bash
sudo cscli decisions delete --ip 203.0.113.42   # unban
sudo cscli collections install crowdsecurity/nginx
sudo cscli metrics                              # what is being parsed
```

The community blocklist is CrowdSec's main selling point: an IP that brute-forces another user's server can be blocked on yours before it ever connects. According to CrowdSec's documentation (checked October 2026):

- Free users who regularly share signals receive the **Community** blocklist (about 15,000 IPs, tailored to the behaviours you report).
- Free users who don't contribute get a **Lite** list capped at 3,000 IPs.
- Paying users get **Premium** lists of up to 60,000 IPs.
- Only signals from official, unmodified Hub scenarios count as contributions. Custom or edited scenarios don't.

**Privacy:** CrowdSec says each signal contains the attacking IP, the scenario that triggered and a timestamp — not your log lines. That is still data about third parties leaving your server, so if you operate under GDPR or a strict internal policy, read CrowdSec's privacy terms and decide before enrolling. You can run CrowdSec without sharing; you then lose the full community list. fail2ban, by contrast, sends nothing anywhere unless you configure a reporting action.

## Resource use

There is no fair universal benchmark, and we won't invent one. What is true structurally:

- fail2ban is Python. Its CPU use scales with the number of log lines and the number of regexes tried on each line. On quiet servers it is negligible; on busy web logs with many jails it can become noticeable — see [fail2ban high CPU](/troubleshooting/high-cpu/) for the usual fixes (journal matches, fewer jails per file, `mode = normal`).
- CrowdSec is a Go binary plus at least one bouncer process. Its baseline footprint is higher than an idle fail2ban, but parsing is compiled code and scales well. The community blocklist adds tens of thousands of firewall set entries, which nftables and ipset handle efficiently.

If memory is tight (a 512 MB VPS or a Raspberry Pi Zero), measure both on your own workload.

## Docker, Traefik and Kubernetes

**Docker.** Both run in containers. fail2ban needs host networking and `NET_ADMIN`, read access to the logs, and bans in the `DOCKER-USER` chain so they apply to published container ports — covered in [fail2ban with Docker](/guides/docker/). CrowdSec ships an official image, can read container logs straight from the Docker socket, and its firewall bouncer runs on the host.

**Traefik.** This is where many "traefik fail2ban vs crowdsec" threads end up favouring CrowdSec. A Traefik middleware plugin listed on the CrowdSec Hub checks every request against the LAPI and blocks at the proxy, which also works when Traefik sits behind Cloudflare and the firewall only ever sees Cloudflare's IPs. fail2ban can protect Traefik too — read the access log with a filter and ban through the firewall or the Cloudflare API — but you have to get the real client IP into the log first. See the [fail2ban Traefik guide](/guides/traefik/).

**Kubernetes.** CrowdSec has a Helm chart, a Kubernetes data source (added in 1.8.0) and bouncers for ingress controllers. fail2ban was not designed for pods that move between nodes; if you live in Kubernetes, CrowdSec is the more natural fit.

## Configuration side by side

The same SSH protection in both tools:

```ini
[sshd]
enabled  = true
backend  = systemd
maxretry = 5
findtime = 10m
bantime  = 4h
```
# CrowdSec: install the collection; the firewall bouncer enforces
sudo cscli collections install crowdsecurity/sshd
sudo systemctl reload crowdsec
```

## When fail2ban is the better choice

- One server, or a handful, with SSH, mail, a web app or a game server to protect.
- You need a filter for something niche — fail2ban ships 96 filters, from Asterisk to Vaultwarden.
- You want zero external dependencies: no enrollment, no API, no data leaving the host.
- You're on an older or minimal distribution where fail2ban is already packaged.
- You want behaviour you can read in one INI file.

## When CrowdSec is the better choice

- You want pre-emptive blocking from a community list, not only reactive bans.
- You run many hosts and want one decision store and one dashboard.
- You need enforcement in places fail2ban can't easily reach: a Traefik or Nginx middleware, a Kubernetes ingress, a CDN.
- You also want a WAF layer from the same vendor (AppSec).

## Can you run fail2ban and CrowdSec together?

Yes, and it is a common migration path. Both read logs without modifying them, and their firewall rules live in separate nftables tables or iptables chains. A few rules keep it sane:


1. Decide which tool owns each service. Duplicated SSH bans are harmless but make troubleshooting harder; many people keep fail2ban for niche services and let CrowdSec handle SSH and HTTP.
2. Whitelist your own addresses in both: `ignoreip` in fail2ban ([how to whitelist](/config/whitelist/)) and a whitelist parser or allowlist in CrowdSec.
3. When a user is blocked, check both: `sudo fail2ban-client banned 203.0.113.42` and `sudo cscli decisions list --ip 203.0.113.42`.
4. Once CrowdSec covers a service, disable that jail in `jail.local` and reload fail2ban.

> **Don't double-manage one firewall set**
Point each tool at its own table, chain or ipset. If fail2ban's ban action and a CrowdSec bouncer both write to the same set, an unban from one tool can remove the other tool's ban.

## FAQ

### Is CrowdSec better than fail2ban?

Not universally. CrowdSec is better if you want a shared community blocklist, many hosts managed from one place, or enforcement in a reverse proxy or Kubernetes. fail2ban is better for simple, fully local protection of a few servers and has more ready-made filters. Many single-server admins stay with fail2ban and add nothing else.

### Does CrowdSec replace fail2ban?

It can. CrowdSec detects brute-force attacks from logs and bans through its firewall bouncer, so it covers fail2ban's main use. Check that the Hub has collections for every service you protect today; for anything it lacks you'd write a parser and scenario, or keep fail2ban for that service.

### Does CrowdSec send my logs to the cloud?

No. According to CrowdSec, enrolled engines share signals made of the attacker IP, the triggered scenario and a timestamp, not raw log lines. Sharing is what earns the full community blocklist; you can run CrowdSec without it and get a much smaller list. fail2ban sends nothing unless you add a reporting action.

### Can I use fail2ban and CrowdSec at the same time?

Yes. They read the same logs independently and can each manage their own nftables table or iptables chain. Give each tool its own firewall set, whitelist your IPs in both, and check both when someone reports being blocked. Many people run both during a migration.

### Which is lighter on resources, fail2ban or CrowdSec?

An idle fail2ban uses less memory because it is one process, while CrowdSec runs an engine plus bouncers. Under heavy log volume CrowdSec's compiled parsing scales well and fail2ban's regex matching can use more CPU. There is no fair universal benchmark; measure both on your own workload.

### Should I use fail2ban or CrowdSec with Traefik?

CrowdSec's Traefik middleware blocks at the proxy and works even behind Cloudflare, which is why many Traefik users choose it. fail2ban works too: log the real client IP in Traefik's access log, add a filter, and ban through the host firewall or the Cloudflare action.