Protecting CAPI reliability: Introducing rate limiting on CrowdSec’s Central API
CrowdSec’s Central API (CAPI) is a shared service used by CrowdSec Security Engines to authenticate, exchange data, and keep your deployments up to date with the latest threat intelligence. As our community and customer footprint continues to grow, we need to ensure CAPI remains reliable and responsive for everyone, from a single homelab instance to large production fleets.
To support that goal, we have deployed rate limiting on CAPI. This change is designed to reduce the impact of misconfigured or broken setups that unintentionally generate excessive traffic and consume disproportionate shared resources.
Why we are doing this
In the vast majority of cases, high request volume to CAPI is not malicious. It is typically caused by:
- Instances stuck in restart loops (for example, a container that repeatedly fails health checks and restarts)
- Misconfigured deployments that retry too aggressively on errors
- Credentials being reused across large fleets, causing many engines to behave like one “super client” from the API’s perspective
Even when unintentional, these patterns create unnecessary load, degrade performance, and increase cloud resource consumption. Rate limiting is a practical safeguard to ensure continuity of service and responsible use of infrastructure and environmental footprint.
Who should expect to be impacted
For normal deployments, including large and well managed ones, you should not notice any change.
This rate limiting primarily targets outlier behaviour, typically stemming from:
- Broken instances repeatedly trying to authenticate or fetch resources
- Large numbers of engines using shared credentials in a way that creates excessive repeated calls
How the rate limiting works
We have implemented multiple thresholds for free Security Engines. The exact thresholds depend on how the engine is configured and used, including:
- Whether the engine shares signals
- Whether the engine is enrolled
- Whether multiple engines appear to be using the same credentials
The objective is to keep legitimate usage unaffected while preventing misconfigurations from consuming an unfair share of capacity.
What happens if you cross a threshold
If a threshold is exceeded, the offending source IP may be temporarily banned from our service for several hours.
This is intentional: when a system is stuck in a tight retry loop, a short ban window is often the fastest way to stop the runaway traffic and give operators time to correct the underlying issue.
We are actively monitoring these thresholds and adjusting them based on real world behaviour and community feedback.
What to do if you are affected
If you suspect your setup has been rate limited, the right next step is to treat it as a signal to check for excessive retry behaviour. Common remediation steps include:
1) Check for restart loops and repeated failures
Look at your service manager or container runtime logs (systemd, Docker, Kubernetes) and confirm whether the engine is repeatedly restarting or failing to authenticate.
2) Validate credentials and identity usage
If you operate a fleet, ensure you are not unintentionally sharing the same credentials across a large number of engines in a way that causes excessive repeated calls.
3) Ensure your deployment uses sensible retry and backoff behaviour
If you have custom automation around CAPI, confirm it uses exponential backoff on failures rather than retrying immediately in a tight loop.
4) Confirm your engine is configured as intended
Misconfigurations are often small (a missing token, a wrong environment variable, a stale secret), but the resulting behaviour can create constant retries.
If you believe you were wrongfully impacted
If you believe your deployment has been incorrectly rate limited, contact us at: security at crowdsec dot net
Please include the approximate time of impact, your source IP, and any relevant logs or error messages. This will help us verify what happened and adjust thresholds where needed.
Closing note
This change is about keeping CAPI dependable for everyone. Rate limiting allows us to protect service quality, reduce operational waste, and ensure fair access to shared resources across the CrowdSec ecosystem.
As always, we appreciate your feedback and will continue tuning these protections based on what we observe in the field.
