DPTCloud
Back to articles
Technology Insight

Architecting a Multi-Server CrowdSec Topology for Real-Time Threat Intelligence Sharing

May 29, 2026

Introduction: The Evolution of Distributed Infrastructure and Defensive Security

In contemporary enterprise infrastructure, running isolated, perimeter-focused protection mechanisms on individual virtual machines or cloud instances is rapidly becoming a security liability. Legacy log-parsing security applications, while highly performant on a micro-scale, struggle under the weight of modern, distributed botnet campaigns. If an adversarial IP executes a brute-force or application-layer attack against one node within an enterprise cluster, that specific node might eventually detect and mitigate the threat locally. However, the remaining node infrastructure remains blind and completely exposed to the exact same threat vector until they, too, process identical logs and reach the same conclusions independently.

To overcome this asymmetrical operational disadvantage, modern systems engineers leverage CrowdSec. Designed with a modular, highly decoupled architecture natively structured for distributed communication, CrowdSec splits processing logic from API state management. By utilizing a Multi-Server (Centralized LAPI) topology, security professionals can coordinate threat response metrics across multiple disparate application servers simultaneously. This guide provides an architectural blueprint and configuration workflow to seamlessly implement a centralized CrowdSec architecture, ensuring that a malicious IP blocked by any single application node is instantaneously barred from accessing the entire infrastructure pool in real time.

---

Architectural Overview: Decoupling LAPI from the Log Processors

To successfully implement a multi-server CrowdSec topology, it is imperative to understand the fundamental responsibilities of its core architectural components:

  • The Log Processor (Security Engine/Agent): Responsible for tailing server logs (such as Nginx, SSH, or systemd journals), normalising lines into structured events via parsers, and matching those events against behavioral patterns defined in YAML scenarios. The Log Processor does not store global state; it transmits alerts to the Local API.
  • The Local API (LAPI): The centralized state controller and command hub. It ingests alerts generated by the distributed Log Processors, translates those alerts into actionable decisions (e.g., a 4-hour ban), writes them to a persistent database back-end, and aggregates blocklists pulled from the CrowdSec Central API (CAPI).
  • The Remediation Component (Bouncer): The tactical enforcement layer running on each local server. It queries LAPI at regular intervals to ingest new blocking decisions and programs them directly into the system's network stack (via nftables, iptables, or cloud-native ingress systems).

In a default single-server installation, all three components run collocated on the exact same host, communicating over a local UNIX socket or loopback interface. In our enterprise multi-server architecture, we explicitly break this coupling. We designate one hardened instance to run a dedicated, accessible LAPI node, while the client application instances host only the lightweight Log Processors and Remediation Components, transmitting state updates across the network layer over a secure TCP port.

---

Step 1: Preparing and Hardening the Centralized LAPI Node

The centralized LAPI instance must be equipped to handle concurrent telemetry from across your network infrastructure. By default, CrowdSec uses SQLite, which is highly efficient for single-host deployments but sub-optimal under concurrent multi-agent write locks. For enterprise multi-server workloads, migrating LAPI's persistent store to a robust database engine like PostgreSQL or MySQL is strongly recommended.

1.1 Configuring Database and Networking Bounds

Log into your designated central management server and open the main CrowdSec configuration manifest located at /etc/crowdsec/config.yaml. To allow external agents to interface with the LAPI listener, update the default loopback URI binding to listen across all network interfaces or your specific private internal network interface:

api:
  server:
    listen_uri: 0.0.0.0:8080

Security Warning: Exposing LAPI to 0.0.0.0 makes it reachable over any interface. Ensure that strict network-level firewall policies (e.g., AWS Security Groups or ufw/nftables rules) are instantly applied to permit incoming TCP traffic on port 8080 only from the explicit IP addresses of your client application nodes.

1.2 Enabling Secure Agent Auto-Registration

To scale out client application nodes dynamically without manually generating credentials on the LAPI machine for every single VM instance, enable the auto-registration mechanism within the same config.yaml file:

api:
  server:
    auto_registration:
      enabled: true
      token: "your_secure_random_32_character_token_here"
      allowed_ranges:
        - "10.0.0.0/24"
        - "192.168.10.0/24"

Define a cryptographically secure token and restrict the allowed_ranges block explicitly to your trusted internal VPC subnets. Save the file and execute a service restart to initialize the listener topology:sudo systemctl restart crowdsec

---

Step 2: Provisioning Distributed Log Processors on Client Nodes

With the central command instance actively listening for connections, you can proceed to initialize your remote application servers as specialized Log Processors completely stripped of localized API management duties.

2.1 Disabling the Local API Daemon

Once CrowdSec is freshly installed on a client node via the official distribution repositories, access its local /etc/crowdsec/config.yaml. Because this host must offload all decision-making capabilities to the central node, locate the api: server: block and completely remove or comment out the entire section. This step ensures that the client machine does not consume CPU and memory cycles running an unnecessary local API daemon or an independent SQLite database.

2.2 Registering the Node to the Central LAPI

Execute the registration utility provided by the CrowdSec CLI tool (cscli). Pass the configuration details mapping to your central management infrastructure:

sudo cscli lapi register --machine $(hostname) --url http://:8080 --token your_secure_random_32_character_token_here

The CLI will transmit the auto-registration request, pull down a uniquely generated set of local credentials, and automatically write them out directly into /etc/crowdsec/local_api_credentials.yaml. To apply this operational state shift, instruct the system initialization daemon to re-read and restart the underlying engine process:

sudo systemctl restart crowdsec

To verify that the link has been verified and registered on your central LAPI machine, execute the following diagnostic command on the Central LAPI Server:

sudo cscli machines list

You should immediately observe the newly provisioned machine listed with a validated status flag, confirming that log parsing telemetry is actively synchronized.

---

Step 3: Deploying and Pointing Remediation Components

Log processing and threat validation are merely diagnostic exercises unless enforcement actions are executed uniformly. To guarantee real-time mitigation across all servers, you must install remediation components (Bouncers) on every machine and point them directly to the central LAPI.

3.1 Generating Bouncer Authentication tokens

Since CrowdSec v1.6.4+, multiple bouncers operating across distinct hosts can securely share a single API token if required by massive scale-out patterns, though individual keys offer cleaner audit logs. Generate a token on the Central LAPI Server by entering:

sudo cscli bouncers add web-cluster-bouncer

Copy the returned alphanumeric key carefully; for security reasons, it cannot be retrieved or decoded from the database at a later stage.

3.2 Configuring the Firewall Bouncer on Client Hosts

On the respective target application hosts, install your preferred remediation package (e.g., the standard crowdsec-firewall-bouncer-iptables). Open its configuration file at /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml and alter the standard values to map directly to your central infrastructure endpoint:

api_url: http://:8080/
api_key:

Save the parameters and restart the firewall service daemon:

sudo systemctl restart crowdsec-firewall-bouncer

---

Conclusion: Embracing Collective Infrastructure Immunity

By restructuring your security architecture into a unified multi-server paradigm, you establish an automated internal web of immunity. When an attacking bot executing an aggressive vulnerability probe hits Server A, its log patterns trigger a local scenario match. That alert is piped instantly to the centralized LAPI, which registers an architectural-wide block decision.

Within seconds, Server B, Server C, and all adjacent staging or production zones download the updated blocklist, systematically neutralizing the malicious actor before they even attempt their first connection string on your broader ecosystem. This collaborative architectural pattern effectively transforms individual, isolated logs into global corporate threat intelligence, delivering robust and resilient defensive engineering at scale.

Architecting a Multi-Server CrowdSec Topology for Real-Time Threat Intelligence Sharing | DPTCloud