CrowdSec Web UI: The Dashboard CrowdSec Should Have Shipped With

When I first deployed CrowdSec, I had the same experience many self-hosters do. The logs showed some activity, the bouncer was blocking IPs! cscli metrics looked healthy. But I still found myself asking:

Is CrowdSec actually doing anything?

CrowdSec Installed but Showing No Decisions? Here’s Why That’s Normal

Installed CrowdSec but see empty logs? Don’t panic. Learn how to verify your “invisible shield,” investigate attacker logs, and whitelist your own IP.

Core LabCore Lab Joe

There is a specific kind of satisfaction that comes from watching your local logs go quiet because your firewall is doing its job. But in the Scrap Lab, "quiet" can sometimes feel like "empty."

But then, I decided to flip the switch on the CAPI (Central API) feed.

Sure, I could dig through command-line output and query the Local API directly, but neither gave me a quick, visual overview of what was happening across my environment.

That's where CrowdSec Web UI comes in.

📋 TL;DR Summary: CrowdSec Web UI for Observability

Built by TheDuffman85, CrowdSec Web UI is a lightweight, self-hosted dashboard that connects directly to your CrowdSec Local API (LAPI) and turns raw security events into something you can actually understand at a literal glance.

This is part of the my Homelab Observability Series:

Installing CrowdSec WebUI

Prerequisites

1. [Mandatory] Running instance of CrowdSec somewhere, can be in OPNsense, a docker, doesn't matter.
2. [Optional] - If you want the map to populate, you need your logs geo-enriched. Since I am using SWAG, I simply added & setup the SWAG docker mod linuxserver/mods:swag-maxmind which you can find here.

Step 1: Add the CrowdSec WebUI to your Compose Stack

  crowdsec-web-ui:
    image: ghcr.io/theduffman85/crowdsec-web-ui:latest
    container_name: crowdsec_web_ui
#    networks:
#      your_network:
#        ipv4_address: 192.168.x.x
    ports:
      - "3000:3000"
    environment:
      - CROWDSEC_URL=http://URL-you-will-use:8080
      - CROWDSEC_USER=crowdsec-web-ui
      - CROWDSEC_PASSWORD=GETYOUR_OWNLONG_SECURE_PASSWORD #Hashed!
      - CROWDSEC_ALERT_INCLUDE_CAPI=false # OPTIONAL - Enables seeing the global community blocklists being hit!
    volumes:
      - /brain/DOCKERS/crowdsec_webui/data:/app/data
    restart: unless-stopped

Step 2: Generate a Secure Watcher Password

You need to generate a 'watcher' user that the WebUI can use to talk to your pre-existing instance of CrowdSec with. This hashed password will go into the compose above on the variable CROWDSEC_PASSWORD= with a big string like f44vt4t4535yji5lyj54jyv45s968yu6540yu4 but more and better randomization then that.

1. Watcher password auth Generate a secure password:

openssl rand -hex 32 It will look like:

root@codex:/home/joe# openssl rand -hex 32
220166d151ed819fa0db669f8a0f5b316ec1abdadf619850dce3a81f8edf8869

You copy that long string there ☝️and save it for now, then go put it up in your docker compose above.

2. Create the 'machine' allowed to talk to your existing crowdsec:

docker exec crowdsec cscli machines add crowdsec-web-ui --password <generated_password> -f /dev/null

Note: The -f /dev/null flag is crucial. It tells cscli not to overwrite the existing credentials file of the CrowdSec container. We only want to register the machine in the database, not change the container's local config.

Step 3: Launch and Verify

Simply run docker compose up -d and simply browse to http://serverIPaddress:3000 and voila - dashboard already ingesting logs!

If you check the logs while it's running with docker logs -f crowdsec_web_ui you should see it scanning your CrowdSec instance every 5 minutes by default.

What CrowdSec Web UI Adds (Beyond the CLI)

The project provides a modern interface for:

• Viewing alerts and attack activity
• Reviewing active decisions and bans
• Investigating attacker IPs
• Viewing geographic attack origins
• Manually banning or unbanning addresses
• Monitoring CrowdSec health and activity
• Receiving notifications when new activity spikes occur

Unlike CrowdSec Console, everything remains local and under your control.⚡ For homelab users and small self-hosted environments, that's a huge advantage and a privacy win.

My Deployment (Local LAN + VPN Access)

In my environment, CrowdSec monitors logs from:

• OPNsense
• SWAG
• Docker containers
• Internet-facing services

I view the dashboard it from my VPN or LAN only, but I could serve Web UI behind Authelia and my reverse proxy, giving me a secure dashboard where I can quickly investigate security events.

You should never expose it directly to the internet. Instead, place it behind an authentication layer such as Authelia, Authentik, or another identity provider.

Notifications - Get Pinged Without Watching the Dashboard

Another fantastic feature of CrowdSec WebUI is notifications. Did you want to know whenever a decision is made and something is blocked? Here's where you set this automation up and can be kept up to speed without "eyes-on-glass" always staring at your system.

Step 1 - Set Up a Destination

To set this up, simply head to the Notifications tab on the left of the sidebar navigation screen.

Step 2 - Set Up a Trigger Rule

Once you've setup a destination, you create a rule to trigger, and select it as shown in the 2nd picture (on the right) below.

Be forwarned - depending on what type of alerts you setup, and the rules, you could basically SPAM yourself.

Historical Alert Retention (The Sleeper Feature)

One limitation of CrowdSec itself is that the LAPI only retains a limited number of alerts. CrowdSec Web UI solves this by maintaining its own local SQLite database and preserving alert history across restarts.

This means:

• Long-term trend visibility
• Historical investigations
• Better insight into attack patterns
• Easier troubleshooting

It's just interesting to me to see when attacks ramp up, and I can play detective and investigate why 🕵️. The only correlation I have seen is sometimes waves of attacks happen when new CVE's come out, specifically new ones for web-facing appliances/software.

The nice thing, is that you can click the little buttons under Actions and actually clear alerts & blocks right from the GUI!

The Global Threat Feed (Enabling CAPI)

By default, CrowdSec Web UI shows alerts generated by your local CrowdSec deployment only. That's useful but CrowdSec is also part of a larger threat intelligence network globally, which is actually kind of it's true dark magic power. With a single environment variable, you can choose to include alerts originating from CrowdSec's Central API (CAPI).

environment:
  - CROWDSEC_ALERT_INCLUDE_CAPI=true

You then restart this container (via docker compose restart crowdsec-webui) and voila! The dashboard transforms a bit and you get likely, a bit of alert overload!

Instead of seeing only attacks against your own infrastructure, you gain visibility into malicious activity being reported by the broader CrowdSec community.

Seems like a lot of threats coming out of French datacentre's today! 43% of all detected & blocked attacks are from France at this particular juncture.

You'll notice this dashboard differs in comparison to my previous pictures, specifically in the number of Active Decisions which skyrocketed as it's now counting globally. Also the activity history metric jumps off the page too. As you leave global enabled for several days you'll get to see the trends better.

Why I Leave Global CAPI Enabled

Some administrators prefer to focus exclusively on local alerts. I get that. But I actually enjoy seeing the bigger picture.

The world map becomes a living view of current attack activity. The alerts page fills with data from across the CrowdSec network which can give you an idea of what's going on in the world. Perhaps most importantly, it serves as a reminder that the internet is a far more hostile place than our quiet homelabs sometimes suggest and we're part of a quiet yet larger online battle.

Every red marker on that map represents a real attack that another CrowdSec user has already encountered. Those aren't hypothetical threats. Someone wants to turn your homelab gear into a coin-mining-operation for themselves, or add your hardware to their fleet of botnet devices for their next distributed denial of service attack.

You'll have to decide what's best for you on this front, seeing it all or your slice of the internet 😉

The Trade-off: Signal vs. Noise

The database (crowdsec.db) grows faster, and the "Signal vs. Noise" ratio shifts. But for a technical lead or a homelab enthusiast, that "noise" is actually intelligence. It’s the difference between staring at a closed door and having a radar system that shows you the storm brewing five miles out!

Final Thoughts

CrowdSec itself is one of my favorite security tools for self-hosted environments. CrowdSec Web UI makes it dramatically easier to understand what CrowdSec itself, is actually doing.

Overall I really love this simplistic dashboard, paired with the SWAG dashboard, it gives you a very good quick look at what's going on at the perimeter of your network.

If you've ever installed CrowdSec, seen a few bans in the logs, and wondered whether it's working properly, this dashboard fills that gap perfectly.

For me, it has become one of those rare tools that immediately earned a permanent place in my stack and I regularly check throughout the day/week to ensure things are running smoothly, and being blocked!

📑 FAQ: CrowdSec Web UI

Q: Is CrowdSec Web UI safe to expose to the internet?
A: No. The developer explicitly built it without authentication, so it should only ever run on your LAN or behind a VPN. If you want remote access, put it behind a reverse proxy with an identity provider like Authelia, Authentik, or Keycloak handling the login — never expose port 3000 directly.

Q: Does CrowdSec Web UI replace the cscli command line tool?
A: Not really - think of it as a visual companion, not a replacement. You'll still use cscli for some local debugging and config work, but day-to-day monitoring, alert review, and ban management are far faster through the dashboard once it's running.

Q: What happens to my data if I disable the CAPI (global) feed later?
A: Your local alert history stays intact, since CrowdSec Web UI stores everything in its own SQLite database. Turning CROWDSEC_ALERT_INCLUDE_CAPI back to false just stops new global community alerts from populating the dashboard going forward — it doesn't purge what's already there.

Q: Will enabling the global CAPI feed slow down my dashboard or fill up storage?
A: It will grow your crowdsec.db noticeably faster, since you're now ingesting community-wide attack data instead of just your own. For a typical homelab this is still a small SQLite file, but if you're tight on disk or just want a cleaner signal-to-noise ratio, leaving CAPI disabled and sticking to local alerts is a perfectly reasonable choice.

Q: Can I get notified without staring at the dashboard all day?
A: Yes - the Notifications tab lets you configure a destination plus a trigger rule, so you get pinged when new decisions or alert spikes occur. Just scope your rules carefully (e.g. filter by your own domain) if you have global CAPI enabled, or you'll bury yourself in alerts for attacks that have nothing to do with your infrastructure.