CrowdSec: The Crowd-Powered IPS That Replaced Fail2ban on My Servers

I ran Fail2ban for almost three years. It worked — sort of. SSH brute-forces got blocked, bots hitting my Nginx got their IPs banned, and I could sleep reasonably well at night.

But there was always this nagging feeling. Fail2ban is reactive. It waits for someone to try kicking your door, counts to five, then maybe slams it shut. And that’s assuming the attacker doesn’t just rotate IPs faster than you can ban them.

Then I found CrowdSec. A year later, I’ve migrated every single server I manage — and I’m never going back.

What Makes CrowdSec Different?

CrowdSec is like Fail2ban if Fail2ban had a brain and 100,000 friends watching your back.

Here’s the core difference: CrowdSec shares threat intelligence across the entire network. When someone attacks my server, that attacker’s IP gets flagged globally. When someone attacks your server tomorrow, I’ve already seen that IP yesterday. We’re all helping each other.

Instead of parsing log files with clunky regex rules, CrowdSec uses scenarios — YAML-based detection rules that describe attack patterns. It’s cleaner, faster, and way more maintainable than Fail2ban’s jail system.

And the ban enforcement? It handles that too. Nginx, SSH, Cloudflare, your firewall — CrowdSec has bouncers for all of them.

Before vs After: What Changed for Me

Before CrowdSec: Every other day I’d check my Fail2ban logs and see 20 banned IPs. All manual, all isolated to my single server. If that same IP hit my buddy’s server five minutes later? Free pass.

After CrowdSec: I see alerts grouped by attack type — SSH scans, HTTP probes, brute-forces. The CrowdSec Community Blocklist automatically updates from 100,000+ participants worldwide. IPs that attacked someone else never even get to touch my server. It’s proactive, not reactive.

The killer feature? The dashboard. CrowdSec comes with a beautiful Metabase-based console where you can visualize all your alerts, top attackers, and ban trends. I check it once a week and it tells me everything I need to know.

How I Set Up CrowdSec in Docker

The cleanest deployment is Docker. Here’s the exact setup running on my VPS right now.

Step 1: Start the CrowdSec Container

# docker-compose.yml
services:
  crowdsec:
    image: crowdsecurity/crowdsec:latest
    container_name: crowdsec
    restart: unless-stopped
    environment:
      - COLLECTIONS=crowdsecurity/linux crowdsecurity/nginx crowdsecurity/http-cve
      - GID=1000
      - UID=1000
    volumes:
      - ./crowdsec/config:/etc/crowdsec
      - ./crowdsec/data:/var/lib/crowdsec/data
      - /var/log/nginx:/var/log/nginx:ro
      - /var/log/auth.log:/var/log/auth.log:ro
    ports:
      - "8080:8080"

  crowdsec-dashboard:
    image: crowdsecurity/metabase:latest
    container_name: crowdsec-dashboard
    restart: unless-stopped
    ports:
      - "3000:3000"
    environment:
      - MB_DB_FILE=/metabase-data/metabase.db
    volumes:
      - ./crowdsec/metabase-data:/metabase-data
    depends_on:
      - crowdsec

This sets up CrowdSec with three key collections: Linux system events, Nginx logs, and HTTP CVE patterns. That covers SSH, web attacks, and common exploit attempts right out of the box.

Step 2: Configure Bouncers

A CrowdSec instance without bouncers is like a security camera nobody watches. You need something that enforces the bans.

For my setup, I use the Nginx bouncer and the Firewall bouncer (which wraps iptables):

  bouncer-nginx:
    image: crowdsecurity/firewall-bouncer:latest
    container_name: crowdsec-bouncer-nginx
    restart: unless-stopped
    environment:
      - API_URL=http://crowdsec:8080
      - API_KEY=yourapikeyhere
    cap_add:
      - NET_ADMIN

  bouncer-firewall:
    image: crowdsecurity/firewall-bouncer:latest
    container_name: crowdsec-bouncer-firewall
    restart: unless-stopped
    environment:
      - API_URL=http://crowdsec:8080
      - API_KEY=yourapikeyhere
    cap_add:
      - NET_ADMIN
      - NET_RAW

Get the API key by running docker exec crowdsec cscli bouncers add my-bouncer. That’ll output a key you plug into the API_KEY fields.

Step 3: The Dashboard

Once running, head to http://your-server:3000. The Metabase dashboard shows:

• Active alerts — what’s happening right now
• Top 10 attackers — the IPs hitting you most
• Ban timeline — when bans were triggered
• Scenario breakdown — which attack types are most common

I honestly look at it more for curiosity than necessity. After the first week, CrowdSec just quietly does its job. I rarely get a breach notification anymore because the IPs are already blocked before they can try.

What I Wish I’d Known from Day One

A few lessons from running CrowdSec for a year:

Don’t enable every collection. The default recommendations are solid, but I went trigger-happy and enabled every CVE scenario. My logs filled with false positives — actual visitors getting blocked because their ISP’s IP range had been flagged. Stick to the basics first, then add attack-specific scenarios only if you’re seeing those attack patterns.

The community blocklist is worth it alone. Even if you never configure custom scenarios, enabling the Community Blocklist blocks IPs that have attacked any CrowdSec participant in the last 24 hours. That’s roughly 100,000+ nodes contributing. My ban rate doubled overnight.

Use the Nginx bouncer over the firewall bouncer for web services. The firewall bouncer drops packets at the kernel level, which is lightning fast. But it makes debugging a nightmare when you accidentally ban yourself. The Nginx bouncer returns a 403, which is easier to diagnose. I use firewall bouncer for SSH and Nginx bouncer for web traffic.

CrowdSec replaces Fail2ban, not your firewall. You still want UFW or iptables for basic access control. CrowdSec handles behavioral threats — think of it as an additional layer, not a replacement for the fundamentals.

Why You Should Switch Today

I ran Fail2ban for years because it worked and I was lazy. Switching to CrowdSec took one evening and the improvement was immediate — better detection, global threat intelligence, and a dashboard I actually enjoy looking at.

If you’re running Fail2ban, you’re blocking attackers in isolation. CrowdSec blocks them for everyone. That’s not just better for you — it’s better for the entire self-hosting community.

And here’s the thing: a compromised VPS is a nightmare. Cryptominers eating your CPU, your IP blacklisted on spam lists, your data leaked. A solid intrusion prevention system is one of those things you never appreciate until you really need it.

Pair CrowdSec with a VPN for traffic routing, and you’ve got a seriously hardened server. CrowdSec handles inbound threats, a VPN protects outbound connections and masks your server’s IP from direct exposure.

What’s Next

Migrating from Fail2ban is simple enough — stop the Fail2ban service, start the CrowdSec stack, and watch your alerts page light up. You’ll see all the attacks Fail2ban was silently dropping, now visualized and shared with the community.

Spin up the Docker stack above, generate a bouncer API key, and give it a week. By day three you’ll wonder why you didn’t switch sooner.