When I first wrote about securing my self-hosted Coolify server with CrowdSec, I focused on getting the protection working. After revisiting the setup and updating my production-tested guide in September 2026, there's an important distinction worth explaining.
Protecting your server and protecting the websites running on it are two different jobs. CrowdSec can help with both, but only when the relevant detection and enforcement components are configured correctly.
1. Host-level protection with nftables
I run CrowdSec on my Ubuntu host and use the crowdsec-firewall-bouncer-nftables package to enforce blocking decisions at network level.
CrowdSec analyses the logs it has been configured to collect and identifies suspicious behaviour. The firewall bouncer then acts on CrowdSec decisions.
This layer matters for SSH and other exposed server ports, not just websites running behind Traefik.
The distinction is important: installing a Traefik plugin alone does not give you this broader host-level protection.
2. Website protection through Traefik
Coolify uses Traefik to route HTTP and HTTPS traffic to deployed applications.
My setup also connects Traefik access logs to CrowdSec and applies a CrowdSec bouncer middleware globally to the relevant HTTP and HTTPS entrypoints.
That means websites behind those entrypoints can share the same enforcement layer without adding individual middleware labels to every application.
But getting the connection right matters.
Traefik needs access to the CrowdSec Local API (LAPI), while that API must remain protected from public Internet access. If Cloudflare is proxying traffic, trusted forwarded headers also need careful configuration so decisions use the correct client IP.
3. CrowdSec isn't automatically a WAF
This is the clarification I consider most important.
The basic CrowdSec setup detects suspicious behaviour and blocks IPs associated with active decisions. That is useful for brute-force attempts, probing and repeated abusive traffic.
But it doesn't automatically inspect every request for SQL injection, cross-site scripting or application vulnerabilities.
For request-level inspection and virtual patching, CrowdSec offers an additional AppSec component. It needs separate configuration and testing.
A behaviour-based blocking setup shouldn't be described as complete application-layer protection.
4. What I check after updating
The September 2026 version of my guide documents the stack I tested, including Coolify 4.3.18, CrowdSec 1.8.1 and Traefik 3.7.13. Those are tested versions, not necessarily the latest releases.
Before upgrading, I preserve backups and configuration. Afterwards, I verify the services, CrowdSec bouncers, Traefik logs, website accessibility and SSH connectivity.
I also check that the CrowdSec LAPI port isn't publicly exposed.
The goal isn't to install more security tools. It's to understand which layer protects which traffic, confirm the integration works and avoid accidentally exposing something sensitive.
I've documented the architecture, configuration and validation steps in my updated Coolify + CrowdSec guide.
Top comments (0)