When the free CrowdSec plan is enough and when a paid plan is needed
The free Community plan is enough for a team that runs self-hosted CrowdSec to stop brute force and scanning on servers it already owns, and that is satisfied with the community blocklist and public Hub rules. The Security Engine, the Local API and the bouncers that enforce decisions are MIT licensed, and the detection rules on the CrowdSec Hub are MIT licensed too. Through the Central API, your installation shares the attacks it detects and downloads the curated community blocklist of validated attackers. That covers the common case: a few Linux servers or a reverse proxy, logs parsed on site, and bans enforced at your own firewall. Confirm the release you standardize on, for example 1.8.1, published on September 3, 2026.
Paid plans change the outcome under specific conditions. Console Premium is billed per Security Engine, so the first number to establish is how many engines you run. A small fleet keeps that cost contained, while a large one multiplies it, so model the count before comparing plans. Consider Platinum Blocklists when the community list does not meet your policy or your false-positive tolerance is low and you need a curated feed. Ask CrowdSec what Platinum contains, how entries are validated and how often it updates. The CTI API matters when you want CrowdSec threat intelligence inside your own SIEM, SOAR or ticketing tools. Confirm rate limits, terms of use and whether it fits your data handling rules. Check the CrowdSec pricing page for current plan contents, because this page does not state prices.
Before you decide, run three checks. First, count your Security Engines and remediation points so you know whether per-engine billing applies to one host or many. Second, test the community blocklist against your own traffic in staging and record any legitimate IPs it would block, such as partners or monitoring services. That evidence shows whether a curated feed is worth paying for. Third, get plan terms in writing from CrowdSec, since licensing details can change and procurement should not depend on this page. DeployOpen plans and implements CrowdSec deployments under a written scope, so the free-or-paid decision can be costed inside that scope.
Which CrowdSec capabilities sit in the free plan and which are paid
This table sets the free Community plan against Console Premium, Platinum Blocklists and the CTI API. Where the repository or documentation confirms a capability, the cell says so. Where only the pricing page's plan split applies, the cell tells you what to confirm with CrowdSec before you buy.
| Capability | Community plan (free) | Console Premium and paid blocklists |
|---|---|---|
| Detection engine and scenarios | Security Engine and Log Processor are MIT licensed and self-hosted | Confirm with CrowdSec whether any engine feature changes on a paid plan |
| Hub detection rules | Hub rules are MIT licensed and installable from the Hub | Confirm which Hub content, if any, is limited to paid plans |
| Community blocklist | Participating installations share attacks and download the curated community blocklist | Confirm whether paid plans add blocklist depth or only a different delivery method |
| Platinum Blocklists | Confirm on the pricing page whether any Platinum Blocklist is included | Platinum Blocklists are a paid add-on, billed separately; confirm contents and update frequency |
| Central management in the Console | Confirm which Console views, if any, are available without a paid plan | Console Premium is billed per Security Engine; confirm which central management features it adds |
| Threat intelligence access (CTI API) | Confirm whether any CTI API access is included | CTI API access is a paid add-on; confirm rate limits, data scope and licensing terms |
License, support and update terms for each CrowdSec plan
The engine and the Hub detection rules are MIT licensed, so the open-source core does not depend on which paid plan a team buys. The terms that do vary by plan, such as support, update channels and blocklist access, are published on the pricing page and must be confirmed in writing before a purchase.
MIT license for the engine
CrowdSec itself is licensed under the MIT license, so a self-hosted Security Engine can be run, modified and redistributed under those terms without a paid plan. This is the baseline for any comparison. Confirm with your legal team that MIT satisfies your internal policy for every host where the engine will run, including container images you build yourself.
MIT license for Hub rules
The detection scenarios, parsers and other content published on the CrowdSec Hub are also MIT licensed. Teams that write custom scenarios or fork Hub content can keep those files under the same terms. Check whether any content your team depends on is published by a third party with different terms, and record the source of each collection you install.
What paid plans leave unchanged
Paid plans are a commercial layer on top of the MIT-licensed engine and Hub content. They do not relicense the engine or the open rules. Ask CrowdSec to confirm in writing that your self-hosted engine remains under MIT after you subscribe, and that no paid feature is required for the open components you already run.
What paid plans change
Paid terms cover access and service, not the open-source license. Expect differences in the console features, the blocklist tier, the CTI API and the support commitments. Ask for the exact list of entitlements per plan, the per-Security-Engine billing unit, and whether a subscription is required for each feature you plan to use.
Published support terms
Support levels, response expectations and escalation paths differ by plan and are defined by CrowdSec, not by this comparison. Do not assume community forum help is a support commitment. Ask which channels are covered, the severity definitions, and whether support extends to the self-hosted components you operate in your own infrastructure.
Update and version terms
Release cadence is public on the CrowdSec releases page, where version 1.8.1 was published on September 3, 2026. Ask which versions receive fixes under each plan, how long older branches are maintained, and whether security patches reach the Security Engine and bouncers at the same time. Record the agreed terms before you schedule upgrades.
How Console Premium changes operations for multi-server fleets
The number of Security Engines you run is the main driver of Console Premium cost, because CrowdSec bills it per Security Engine. The bill follows the number of places where the engine runs, so count before you ask for a quote. List every server running a Security Engine, every firewall or proxy host where one runs, and every Kubernetes cluster that hosts one. Then ask CrowdSec how bouncers, separate Log Processor machines and per-cluster deployments are counted, and how the count changes when you add a host. Confirm the current terms on the CrowdSec pricing page before you set a budget, since the per-engine rate and counting rules are the figures that decide the total.
Central visibility and fleet control matter once decisions are made on several machines and you need one view of them. The documented architecture already supports this shape: the Local API connects Log Processors to remediation components and to the Central API, and every component talks over an HTTP API that supports multi-machine setups. The gap Console Premium would fill is the management layer on top of that. Before you buy, write down the tasks you do today across hosts, such as reviewing alerts from one place, checking which bans are active on which machines, or changing a scenario set everywhere at once. Then confirm with CrowdSec which of those tasks Console Premium covers and which you still do on each host.
A single server gains little from a per-engine console, because there is one Security Engine, one local Local API and usually one bouncer to manage. The operational questions for one host are narrower: whether the alerts and decisions on that machine are visible enough for your review, and whether the community blocklist that a participating installation already downloads through the Central API meets your blocking needs. Test those two points on the free setup first. If the host is the only one in scope, the paid console mainly adds cost unless you expect the fleet to grow soon, in which case ask CrowdSec how adding a second engine changes the bill.
Which plan fits a single host, a fleet or a regulated environment
A single Linux server running its own services is the simplest CrowdSec deployment. The Security Engine, Log Processor and Local API all run on the same machine, and a bouncer on that machine enforces decisions, for example at the firewall. This is the case where the free Community plan most often covers the need, because no second engine has to be licensed and the operator controls every component directly.
- Likely fit: one host with SSH, a web server or a small application where brute force and scanning are the main concerns, owned by one operator.
- Local detection and bans: confirm that the bouncer you need, such as a firewall or web server integration, is supported on your operating system and version.
- Community blocklist: check whether the free plan gives the access you need to the curated list, and whether you accept sharing detected attacks through the Central API.
- Upgrade triggers: a second server, a separate proxy or a demand for vendor support usually changes the answer, so review the terms before adding a machine.
Before you buy anything for one host, compare the current plan limits and add-on list on the CrowdSec pricing page against the features you actually use today.
Several machines or several sites bring in the distributed model. One Local API can serve many Log Processors and remediation components at firewalls, proxies or load balancers, and the Central API connects the installation to the shared blocklist. Console Premium is billed per Security Engine, so the number of engines is the main cost input in this case, and it is the number most likely to be understated in early planning.
- Engine count: list every machine that runs a Security Engine across sites, including staging, disaster recovery and lab hosts, before requesting a quote.
- Local API placement: decide where the Local API runs and how remediation components reach it, then confirm how each bouncer behaves when the Local API is unreachable.
- Blocklist and CTI API needs: Platinum Blocklists and the CTI API are separate add-ons. Confirm whether the fleet needs them or whether the community blocklist meets the requirement.
- Outbound connectivity: if sharing is enabled, confirm that each site can reach the Central API through its egress path and proxy rules.
Ask the vendor for every paid component and its billing unit in writing, using the engine count you have documented.
CrowdSec's AppSec component is a web application firewall built on Coraza. It loads SecLang rules, the OWASP Core Rule Set and YAML rules, and it inspects HTTP requests from compatible web servers. A reverse proxy front end therefore combines request inspection with IP-level decisions, which is why teams publishing applications often evaluate it alongside the plan question. Which components you run, and where enforcement happens, determines what you need to license.
- Who it suits: teams that publish web applications behind a reverse proxy and want request inspection and IP decisions managed in one tool.
- Integration support: confirm that your web server or proxy has a supported bouncer or AppSec integration at the version you run.
- Rule ownership: the Core Rule Set and custom rules need a named owner for tuning, exceptions and false positive review.
- Edge enforcement: if blocking happens at a CDN or other edge service, confirm that the provider is supported and do not assume it from a generic bouncer.
- Plan impact: confirm whether proxy-attached engines count as Security Engines for billing in the same way as log-analysis engines.
Test in a non-production route first, then confirm the plan terms before turning on blocking across every site.
Regulated teams need more than a working blocklist. They need to show who approved the configuration, what data left the network, which support commitments apply and what evidence an assessor can review. DeployOpen can plan, configure, document and prepare evidence for an assessment under a fixed written scope. It does not issue audit reports, attestations or certifications, so the assessor decides whether the evidence is sufficient.
- Data sharing review: participating installations share the attacks they detect through the Central API. Get the data scope in writing and check it against your data handling policy before enabling sharing.
- Support commitments: if a paid plan is needed for support, ask for the scope, response commitments and any service levels in writing. Do not assume a plan includes them.
- Evidence trail: decisions, bans and configuration changes need retention in a log store your assessor accepts, with integrity controls you can describe.
- Change control: pin versions, track releases such as CrowdSec 1.8.1 and test upgrades in a staging environment before rollout.
- Assessor alignment: confirm with your assessor which controls the blocklist and paid features support before counting them as evidence.
Before buying, have your security, legal and procurement teams review the data sharing terms and support scope together.
Cost components for each CrowdSec plan and what a quote should include
This table lists each cost component in a CrowdSec deployment, who is paid for it, whether it is one-time or recurring, and what moves it. Published CrowdSec prices are not reproduced here, so check the CrowdSec pricing page for current amounts. The main takeaway is that staff time and engine count usually drive total cost more than the license.
| Cost component | Who is paid | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Engine and Hub content (free) | No license fee; CrowdSec and Hub rules are MIT licensed | Staff time to deploy and tune, recurring | Number of hosts, log sources and scenarios you enable |
| Community plan and community blocklist | No fee for the engine; confirm blocklist access terms on the pricing page | Recurring operating effort only | Whether each server runs its own engine or shares a central Local API |
| Console Premium | CrowdSec, billed per Security Engine; confirm the per-engine rate in writing | Recurring, scales with engine count | Number of Security Engines, environments and console features you need |
| Platinum Blocklists | CrowdSec; confirm whether pricing is per engine or per organization | Recurring | Blocklist scope, update frequency and how many systems consume it |
| CTI API | CrowdSec; confirm quota, rate limits and overage terms | Recurring | Request volume, number of integrations and enrichment lookups per event |
| Internal staff time | Your own team | One-time setup, then recurring tuning | Number of sites, bouncer types, change control and alert review load |
| Implementation or support, if bought | A provider under a written scope; DeployOpen does not publish a price list | One-time for implementation, optional recurring retainer | Scope, deliverables, environments and support hours agreed in writing |
| What to request in a quote | Ask every vendor and provider for the same line items | Read as one-time and recurring separately | Engine count, blocklist scope, API volume, support terms, renewal and overage rules |
Moving from the free plan to a paid plan and back
This sequence shows how an existing self-hosted CrowdSec deployment can add Console Premium or the CTI API while keeping its current Local API, log processing and bouncer layout, and how to return to the free plan if the paid features are not needed. Exact commands and console steps must be confirmed against the CrowdSec documentation for the version you run, such as 1.8.1.
Inventory the current deployment before changing anything
Your platform or security team lists every Security Engine, Local API host, Log Processor, and bouncer (firewall, web server, or reverse proxy) that is in production, along with the version of each component and where its configuration lives. Record which engines already enroll with the Console, if any, and which bouncers use the Local API key. The step is done when the team has a written map showing every component and its owner, so later checks have a baseline to compare against.
Confirm plan terms and billing unit with CrowdSec
Ask CrowdSec sales or read the current plan pages on the CrowdSec pricing site to confirm what Console Premium covers, what Platinum Blocklists and the CTI API add, and how billing is counted per Security Engine. Ask whether a Security Engine that is a Local API host counts differently from a Log Processor only host. The step is done when you hold a written answer on billing units and the features in each plan, which becomes the basis for your quote and internal approval.
Upgrade and test in a non-production copy
Run the same CrowdSec version you plan to use in production, such as 1.8.1 if that is your target, on a staging copy of the Local API and one bouncer. Confirm the upgrade path for your installed version in the CrowdSec release notes and documentation first, because exact commands differ by version and install method. The step is done when staging starts cleanly, scenarios still load, and a test decision reaches the bouncer.
Enroll engines with the Console and enable paid lists
In the Console, register each Security Engine using the enrollment command that CrowdSec documents for your version, then enable the paid blocklists or CTI API access in the Console for the engines that need them. Keep enrollment on the Local API host so the existing LAPI topology does not change. The step is done when each engine appears in the Console with the expected name and status, and the enabled lists show as active for those engines.
Verify decisions and bouncers after enrollment
Trigger a controlled test event from a lab host that the detection scenarios should catch, then confirm that the decision appears in the Local API and that each bouncer enforces it. Also confirm that the bouncers still authenticate, that the Local API still serves decisions to every remediation component, and that the community blocklist still loads. The step is done when the test decision is enforced on each bouncer type you run and no bouncer reports an authentication or stream error.
Document the change and set a review point
Record the enrolled engines, the enabled lists or CTI access, the Console account owner, and the version of every component in your runbook and change log. Name who reviews the Console usage and billing each period, and add a check to your monitoring that alerts when a bouncer stops receiving decisions. The step is done when the runbook reflects the new state and an owner has accepted the review responsibility.
Roll back to the free plan if needed
If the paid features are not used or not justified, remove the engines from the Console or disable the paid lists, following the removal steps in the CrowdSec documentation for your version. Then rerun the decision test and the bouncer checks from the verification step to confirm that the Local API, the scenarios, and the free community blocklist still work. The step is done when the free configuration passes the same tests as before the change and the Console records no active paid subscriptions for these engines.
Confirm the final state with the vendor and your records
Ask CrowdSec for written confirmation of the final plan, the billed engine count, and any charges that continue after removal, then reconcile that against your runbook. Keep the rollback procedure with the change record so it can be reused if the plan changes again. The step is done when the invoice or account statement matches the engine count in your inventory and the rollback procedure is stored with the change record.
What buyers ask before paying for CrowdSec Console Premium
What drives the cost of CrowdSec Console Premium?
The main driver is the number of Security Engines you enroll, because Console Premium is billed per Security Engine, so the cost grows with each server or instance running the engine. Check the current figures on the CrowdSec pricing page before you budget, and confirm whether Platinum Blocklists and CTI API access are included in Premium or sold separately. On the services side, DeployOpen does not publish a price list. A quote follows from a written, fixed scope that lists the systems to be deployed, the integrations, the testing and the handover documents. One-time costs usually cover planning and rollout. Recurring costs cover the CrowdSec subscription and any support retainer you choose. Ask for the engine count, the blocklist tier and the API usage assumed in the quote so you can compare it with your own estimate.
Can a team evaluate the free CrowdSec plan before paying?
Yes. The CrowdSec engine is MIT licensed, the detection rules on the CrowdSec Hub are also MIT licensed, and the free Community plan is the starting point for a self-hosted deployment. A practical evaluation runs the engine on one non-production host, connects one bouncer such as a firewall or reverse proxy integration, and records what gets detected and blocked over a set period. Confirm on the pricing page exactly which features the Community plan includes, especially how it connects to the Central API and the community blocklist. Use the 1.8.1 release, published on September 3, 2026, as the version to test, and check the release notes for your own environment before you move the same configuration into production.
How long does it take to switch to Console Premium?
No duration is supplied for this switch, so the answer depends on your environment. The change is mainly an enrollment and configuration step for each Security Engine, which means the effort rises with the number of engines, the number of bouncers that consume decisions and how your change control approves production changes. Ask CrowdSec to confirm the enrollment steps for the version you run, and check that your monitoring still sees alerts after the change. If DeployOpen carries out the work, the timeline is set in the written, fixed-scope agreement before work starts, and the agreed deliverables define when the switch is complete.
What does running CrowdSec Premium require from our staff?
Your team needs the following skills and ownership to run the platform after the switch:
- Linux administration to install and update the Security Engine, Log Processors and bouncers
- Ownership of log sources, parsers and scenarios so detections match your services
- Firewall, reverse proxy or WAF changes so that decisions are enforced where traffic enters
CrowdSec documents deployments on a single machine, across multiple machines, on Kubernetes, in containers and in a WAF-only mode, so the workload depends on which of these you pick. The paid plan adds central management, but it does not remove the need to test false positives, review blocked IPs and keep components on supported versions. Assign a named owner for these tasks before you enroll the first engine.
Does a team need a partner to adopt CrowdSec Console Premium?
No. The MIT licensed engine and the free plan can be run by an in-house team, and the paid plan is bought through CrowdSec's own pricing. A partner helps when the team lacks time or experience with log pipelines, firewall integration or hardening. DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, and it can prepare evidence for compliance assessments, although it does not issue audit reports or certifications. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support and upgrades are available as retainers. DeployOpen is not a CrowdSec partner or reseller.
When do paid CrowdSec plans change outcomes for a team?
They change outcomes when a team runs several engines and needs one place to manage them, when it wants the Platinum Blocklists, or when it needs the CTI API for other tools. A single server with local bans may never reach those conditions. The free setup already shares attacks it detects and downloads the curated community blocklist through the Central API, so the paid plan matters only if you need more than that. Before you decide, list the engines, the bouncers, the blocklist requirement and any integration that needs API access, then check which of these the Community plan already covers on the pricing page.
What should a quote for CrowdSec Console Premium include?
A useful quote separates one-time work from recurring charges and states each assumption in writing. Ask for these items:
- The number of Security Engines and the environments they run in
- The blocklist tier and whether Platinum Blocklists are included
- Whether CTI API access is needed, and for which tools
- The bouncers, firewalls, proxies or WAF points to integrate
- The support, upgrade and testing duties, and whether they are one-time or a retainer
- The deliverables, the timeline and the acceptance criteria
DeployOpen issues a quote from the written scope, so a vague scope produces a vague quote. Compare each line against the pricing page before you sign.
How DeployOpen scopes and delivers CrowdSec plan decisions
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For CrowdSec plan decisions, we start from a written scope that sets out which Community features, Console capabilities and blocklist sources the team actually needs before anything is installed or purchased.
How we scope
- Inventory the servers, firewalls, reverse proxies and web applications that would consume CrowdSec decisions.
- Record which Security Engine installations need Console visibility and which would stay on the free Community plan.
- Confirm current plan terms, billing basis and blocklist entitlements with CrowdSec before the written scope is agreed.
- Agree deliverables, timelines and exclusions in writing before work starts, since most engagements are fixed-scope.
How we build
- Deploy and configure the Security Engine, Local API and bouncers in the client's own cloud accounts or data centers.
- Test scenarios and remediation paths against representative traffic to confirm decisions reach the intended enforcement points.
- Set up any paid Console or Platinum Blocklist subscription only after the scope confirms it is needed.
- Document the configuration, licensing assumptions and per-engine count so the client can audit their own setup.
How we hand over
- Deliver runbooks covering enrollment, bouncer rollout, blocklist updates and rollback steps.
- Provide a written record of which plan applies to each installation and what would change if the count of engines grows.
- Walk the operations and security teams through alert review, false-positive handling and whitelisting.
- Hand over the artifacts and access needed for the client's own staff to run the setup without DeployOpen.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped separately.
- Review CrowdSec release notes and plan changes with the client when a retainer is in place.
- Re-check the licensing and plan fit whenever the number of Security Engines or blocklist needs change.
- Coordinate with the client's compliance team on evidence for controls, while auditors and certification bodies issue any assessment.
