Where a LogRhythm cost comparison with self-hosted Wazuh actually lands
Wazuh carries no license fee, and its GPLv2 license lets you run it without a per-seat or per-ingestion charge. OpenSearch, if you use it as the storage and search layer, is licensed under Apache 2.0 and is also free to run. That means the comparison with LogRhythm turns on infrastructure, retention storage, staff time and migration effort, not on software fees. LogRhythm's subscription or perpetual license, its support contract and any appliance or hardware refresh are the commercial side of the ledger, and the size of the savings depends entirely on those figures. LogRhythm's prices are not part of the material behind this page, so take them from your own renewal quote or current contract, and ask the vendor to itemize license, support, hardware and storage separately.
Build the self-hosted side the same way. Wazuh runs as an indexer, a server, a dashboard and agents, so your recurring costs are the virtual or physical servers for each role, disk for alert retention, backup storage and the people who operate the platform. Retention is usually the largest variable, because log volume and the number of years your auditors expect you to keep data both multiply storage. Ask your team to size retention by log source and by regulatory period, and compare that figure with how much history your LogRhythm deployment stores today. Also confirm whether you need Graylog Open as an alternative log layer, since it is free to self-manage under the Server Side Public License with no ingestion caps, but its Enterprise and Security tiers carry their own costs.
Treat the one-time migration and the optional support contract as separate line items. Migration covers replacing agents and collectors, translating detection rules, rebuilding compliance reports and keeping a readable history for audits, and it is usually a larger cost in the first year than running the platform afterward. Wazuh support, if you buy it, is also a recurring cost that you should request as a separate quote. Ask any implementation partner, including DeployOpen, for a written scope that names the sources, rules, reports and retention period in play, because those choices drive the effort and the price more than the software itself.
Cost components on each side and whether they recur
This table lists each cost component on the LogRhythm side and the Wazuh side, marks whether it is one-time or recurring, and names what drives it. Use it to build a like-for-like cost model before requesting a LogRhythm quote, because the license terms and hardware sizing will decide most of the difference.
| Cost component | LogRhythm SIEM | Self-hosted Wazuh |
|---|---|---|
| Software license | Subscription or perpetual license, recurring or one-time. Confirm term, metering basis and renewal uplift in the quote. | No license fee. Wazuh is licensed under GPLv2, so the software cost is zero. One-time review of obligations only. |
| Vendor support | Recurring support or maintenance fee, usually tied to the license. Confirm what severity levels and hours are covered. | Optional and recurring if purchased. Without it, support comes from internal staff, community resources or a services partner. |
| Hardware or appliances | Appliance or server hardware, typically one-time purchase plus refresh cycles. Drivers are event rate and vendor sizing rules. | Servers or virtual machines for the indexer, server and dashboard. One-time build, then refresh. Drivers are event volume and cluster size. |
| Storage for retention | Storage tiers sized to the retention period required by the vendor's architecture. Recurring if backed by subscription or cloud storage. | Indexer disk for alerts and archives. Recurring as data grows. Drivers are retention period, log volume and replica count. |
| Agents and collection | Agent licensing and collector components, often counted in the license. Confirm whether System Monitor agents are included. | Wazuh agents are free to deploy. Recurring effort is agent configuration, updates and syslog source onboarding. |
| Implementation and integration | One-time vendor or partner services for deployment, parsing and content. Confirm scope, hours and who owns follow-up. | One-time, usually larger in internal or partner labor. Covers architecture, decoders, rules and dashboards. |
| Migration of history and content | One-time, covering export of prior logs and rule translation. Confirm which formats the vendor will provide. | One-time. Covers exporting audit history, translating AI Engine rules to Wazuh rules or Sigma, and rebuilding reports. |
| Detection engineering and compliance reporting | Recurring staff effort, plus any vendor content packs. Drivers are rule tuning and assessor requests. | Recurring internal staff effort for rules, tuning and PCI DSS, HIPAA or NIST dashboards. Usually the largest ongoing cost. |
| Internal staff operations | Recurring administration of the appliance and platform, patching and vendor coordination. | Recurring administration of four components, upgrades on a patch cadence and backup. Drivers are cluster size and automation maturity. |
What moves the comparison up or down
Six inputs decide whether a self-hosted Wazuh and OpenSearch build costs less than the LogRhythm subscription or perpetual license it replaces. Each one moves hardware, storage or labor, so size them together before you request a quote or start a migration plan.
Event volume and daily ingest
The sustained events per second and bytes per day your sources produce set the indexer size, the disk write load and the number of data nodes. Volume also drives the cost of any SaaS-style ingestion charge on the commercial side. Measure a representative week from LogRhythm's System Monitor and firewall logs rather than relying on license tier estimates, and separate noisy sources such as DNS and proxy logs that can be filtered before indexing.
Retention period and cold storage
How long alerts and raw events must stay searchable is usually the largest storage line. Multiply daily volume by the retention window, then add replicas and index overhead, since an OpenSearch-based indexer stores more than the raw data. Ask your auditors which records must be queryable online and which can move to archived snapshots, because that split changes both disk and labor.
Endpoint and agent count
Each Wazuh agent installed on a Windows, Linux or macOS host adds inventory, file integrity and vulnerability data to the indexer, and agent count drives both server capacity and rollout effort. Wazuh agents are free, but deploying and upgrading them through configuration management is staff time you must plan for. Confirm how many endpoints your LogRhythm System Monitor agents cover today, including servers in unsupported operating systems that need a different approach.
Agentless syslog sources
Firewalls, switches, SaaS APIs and appliances that cannot run an agent feed Wazuh through syslog collection and periodic API probing. Each source adds parsing work, since decoders and rules must be written or adapted for each log format. Count these sources and their formats now, because the parsing effort often exceeds the server cost in a LogRhythm replacement.
Availability and clustering needs
A single Wazuh server and indexer node is simpler to run, but a clustered server allows horizontal scaling, and a multi-node indexer protects against data loss and downtime during a failure. Your uptime targets, the cost of a missed alert and any regulatory expectation for monitoring continuity determine how many nodes you buy and how much failover testing you pay for. Ask your vendor or integrator to size the cluster against your written availability requirement.
Skills already on staff
Running Wazuh, OpenSearch and detection content well requires people who can tune rules, manage index lifecycles, patch clusters and answer audit questions. A team that already runs Elastic or Linux infrastructure needs less training and fewer external hours than one starting from a commercial console. Count the internal hours you can commit, then decide whether to add a managed support retainer, an implementation partner or staff hires for the gap.
How to build the cost model with your own numbers
This sequence turns a LogRhythm renewal and a Wazuh alternative into a like-for-like three- to five-year comparison built on your own contract terms, event volumes and retention requirements. Each step produces a figure you can defend in a budget review.
Pull the current LogRhythm contract and support terms
Procurement and the SIEM owner collect the current order form, the license model (subscription or perpetual), the support and maintenance schedule, renewal dates, and any uplift or true-up clauses. Ask the vendor or reseller to confirm each figure in writing, including what is included in support and what is billed separately. The step is complete when every recurring and one-time line item is recorded with its source document and expiry date.
Inventory appliances and their refresh dates
The infrastructure team lists every LogRhythm component in use, including collectors, log processing and storage appliances, and any virtual or hardware platforms beneath them. For each item, record the model or version, warranty or support end date, power and rack footprint, and the date it is due for hardware refresh. The output is a table showing which costs are already committed and which would fall due during the comparison window.
Measure daily event volume and required retention
The SIEM team measures average and peak daily events and bytes per source over a representative period, and separates hot search from long-term archive requirements. Retention periods come from your regulators, auditors and internal policy, not from the tool. The output is a sizing sheet with daily ingest, peak rate, hot and archive retention in days, and the number of sources, which becomes the input for every later calculation.
Size Wazuh indexer and server for that volume
Engineers translate the sizing sheet into Wazuh indexer, server and dashboard capacity, choosing between a single-node or clustered design, on-premises hardware, virtual machines or cloud instances. Use the Wazuh deployment and component documentation to confirm the node roles you need, and ask a qualified implementer to validate the sizing against your peak ingest. The output is a bill of materials with CPU, memory, disk and network per node, and an itemized list of the compute you would buy or rent.
Price storage for the retention you need
Storage engineers convert retention days into usable disk capacity, including replicas, index overhead and free space, then price it at the media or cloud rate you actually pay. Separate the hot tier used for search from any archive tier used for audit history. The output is a per-year storage cost with the assumptions written down, so the reader can see how changing retention or replica count moves the total.
Add migration and detection engineering effort
The project lead estimates the one-time work: agent and syslog redeployment, translating existing correlation rules into Wazuh rules or Sigma, rebuilding compliance reports, exporting historical data, and decommissioning appliances. Add the recurring staff time for rule tuning, patching and on-call. Ask any external partner for a fixed-scope written proposal, and treat internal staff hours at your own loaded rate. The output is a labor schedule separating one-time migration cost from ongoing operating cost.
Compare three- to five-year totals
Finance and the SIEM owner place both options on the same timeline, adding license or subscription fees, support, hardware, storage, power and space, labor, and optional Wazuh support against the migration and overlap period when both platforms run side by side. Label any worked example as illustrative and run the model with a best and a worst case for volume growth. The output is a total cost of ownership comparison by year and component that shows which assumptions move the result most.
Why retention storage often decides the total
Retention periods set the storage footprint on both sides of the comparison, so they deserve to be fixed before any quote is compared. Auditors and internal policies typically specify how long alerts, authentication events and firewall logs must be kept and whether they must stay searchable or only retrievable. Those two requirements drive very different storage designs. Ask LogRhythm to confirm, in writing, how exported history is licensed and stored, including whether restoring archived data requires additional capacity, modules or support fees. Then apply the same retention table to a Wazuh design so the comparison uses identical inputs. In Wazuh, alerts are stored in the Wazuh indexer, a full-text search and analytics engine, so the indexer's disk, memory and replica settings determine how much history stays online. Storage cost on the open-source side is the hardware or cloud volumes you provision, the operating effort to size and monitor them, and the snapshot or backup target you choose. Those costs are yours to estimate from your own event rates, which is why the sizing exercise should come before any hardware order.
The OpenSearch layer matters when history must survive platform changes. OpenSearch is wire-compatible with Elasticsearch 7.10 and can use indices created from Elasticsearch 6.0 through 7.10, and it supports rolling upgrades from those versions. If your archive was built on an older Elasticsearch-based store, confirm which index versions are present and plan the upgrade path in a test cluster before retiring any appliance. Also confirm that the Wazuh indexer version you deploy stays compatible with the retention strategy you choose, and check the release notes for the Wazuh 4.14 line before each upgrade. Keeping auditable history readable for the full retention period is often a larger line item than the license it replaces.
Paying for support on the open-source side
Running Wazuh with community support means your own engineers carry the work. The software itself carries no license fee, so the cost sits in people, servers and storage. Your team installs the Wazuh indexer, server, dashboard and agents, tunes decoders and rules, keeps the stack patched, and answers audit questions. Wazuh ships 4.14 patch releases roughly every one to two months, so someone must own upgrade planning. Staff time is the largest recurring line, and it rises with the number of log sources, custom detections and compliance reports you maintain.
- Staff time: Budget for detection engineering, operations on-call and patch cycles as recurring salary cost, not a one-time expense.
- Infrastructure: Servers, indexer storage for alert retention and backup targets recur with data volume and retention period.
- Knowledge risk: Few people who understand custom rules can make the platform hard to hand over, so document ownership early.
- Upgrade effort: Each minor release needs testing against your agents and integrations before rollout.
- Community channels: Public forums and documentation help, but they carry no response commitment.
Before relying on this model, confirm with your own security and compliance leads how many people can realistically cover on-call and audit evidence.
Wazuh's open-source core can be paired with paid support or with Wazuh Cloud, a managed alternative. Support contracts buy access to the vendor's engineers and a defined response process, while the software remains free. A managed service shifts operation of the platform to the vendor, which changes where your data is hosted and who runs the infrastructure. Each choice recurs annually or monthly and should be compared against the staff time it replaces.
- Support tier: Confirm response times, severity definitions, supported versions and whether upgrades are included.
- Managed hosting: Confirm where Wazuh Cloud stores data, which regions are offered and whether this meets your residency rules.
- Scope boundaries: Ask whether custom decoders, integrations and detection content are covered or excluded.
- Exit terms: Confirm data export formats, notice periods and what happens to retained alerts at termination.
- Pricing basis: Ask whether the fee scales with agents, endpoints, data volume or users, and request the metric in writing.
Because pricing bases differ, ask the vendor for a written quote tied to your agent count and retention period, and confirm its terms directly with them.
An implementation partner covers one-time or periodic work that your team may not have capacity for, such as planning, deployment, hardening, integration, documentation and testing. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms inside your own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, and a quote follows from the written scope. Ongoing support, upgrades and continuous testing are available as retainers.
- One-time project: Deployment, migration of rules and dashboards, and handover documentation are typically priced as a fixed-scope project.
- Recurring retainer: Upgrades, monitoring of the platform and periodic testing can run under a separate ongoing agreement.
- Responsibility split: Confirm in writing which tasks the partner owns and which remain with your staff after handover.
- Acceptance criteria: Agree on tested outcomes, such as agent coverage and report output, before sign-off.
- Quote inputs: Provide log sources, retention needs, compliance frameworks and integration count so the quote reflects the actual scope.
Ask for a written scope and deliverables list first, since that document determines what the quote covers.
Questions buyers ask before comparing LogRhythm with Wazuh
Does Wazuh cost nothing to run?
No. Wazuh is free to download and use under the GNU General Public License version 2, so there is no license fee, but the platform still consumes servers, storage, network capacity and staff time. The Wazuh indexer, server, dashboard and agents each need compute and disk, and retention drives storage growth more than anything else. Optional Wazuh support is a separate, recurring contract. Compare the total of these components with your current LogRhythm subscription or perpetual license, support renewal and appliance refresh, using your own log volumes and retention periods rather than a generic figure.
How long does a LogRhythm to Wazuh migration take?
The duration depends on the number of log sources, how many AI Engine rules and compliance reports must be rebuilt, how much history must be exported, and how many appliances must be decommissioned. Agent rollout across Linux, Windows and macOS endpoints usually takes the longest, and agentless devices such as firewalls need syslog or API collection set up one by one. No timeline is fixed in advance, so ask for a written schedule based on an inventory of your own environment before accepting any estimate.
What work must our own team do during the migration?
Your team owns the decisions that depend on your business and audit obligations, even when an implementation partner does the build. Expect internal effort in these areas:
- Confirming which log sources, retention periods and users must be carried over
- Approving detection logic, since rules must be reviewed against your threat model
- Validating compliance dashboards against the control evidence your auditors expect
- Deciding how historical LogRhythm data is kept and who can access it
- Taking on day-to-day operations, patching and upgrades after handover
Ask for a RACI matrix in the written scope so responsibilities are clear from the start.
Can a small security team run a self-hosted Wazuh deployment?
It can, but the answer depends on your team's capacity, on-call coverage and the number of endpoints monitored. Wazuh offers several deployment paths, including a prebuilt OVA virtual machine, Docker, Kubernetes, Ansible and Puppet, which can reduce initial setup effort. Ongoing work still includes agent upgrades, rule tuning, indexer health and backups. Small teams often choose a retainer for upgrades and monitoring, which is available from DeployOpen on a fixed-scope basis, so the internal workload stays predictable.
How do we keep LogRhythm history that auditors may ask for?
Export and retain historical LogRhythm data before any appliance is switched off, because the new platform will not contain it automatically. Agree with your auditors which records, formats and retention periods are required, then decide whether to keep read-only access to the old system, archive exports in your own object storage, or both. Archived data still has storage cost and access controls to plan for. Confirm the export formats and retention obligations with your compliance lead and your auditor, since those requirements come from your environment, not from a product default.
What does a quote for this migration depend on?
A quote follows from a written scope, so it depends on the work that scope defines. The main inputs are the number and type of log sources, the endpoints needing Wazuh agents, the rules and compliance reports to rebuild, the history to export, the target architecture and whether it runs in your cloud account, a data center or an air-gapped network. Ask for line items that separate one-time migration work from recurring support, upgrades and any Wazuh subscription you choose. DeployOpen does not publish a price list.
Which costs stop when LogRhythm is switched off?
Only the costs tied to the old platform stop, and some continue for a time. The subscription or support renewal may run until its end date, and appliances may need to stay powered during parallel running and history access. Hardware refresh and storage for archived data continue as long as those records are kept. Ask your LogRhythm contract team for the exact end dates and exit terms in writing, and plan parallel running around them rather than assuming savings begin on migration day.
When self-hosting costs more than staying put
Staying on LogRhythm can cost less in the short term when the remaining contract term is short and the migration bill is large. Moving a SIEM is not a license swap. Each System Monitor agent or syslog source has to be re-pointed, AI Engine rules have to be translated, compliance reports have to be rebuilt, and the history auditors rely on has to be exported and held in a form they accept. Running both platforms in parallel for a validation period adds ingestion, storage and analyst time on two stacks at once. If those one-time costs plus the parallel period exceed the license and appliance support you would pay by simply renewing, renewal is the cheaper option for that window. Ask LogRhythm or your reseller for a renewal quote with the term length explicit, then compare it with a written migration scope from any implementer, including the parallel-run duration you expect to need.
Staffing decides the outcome as much as license fees. Wazuh and OpenSearch shift work from the vendor to your team: you own decoder and rule tuning, index lifecycle and retention, cluster sizing, upgrades and the on-call rota for the stack. Wazuh's 4.14 line receives patch releases roughly every one to two months, so someone must track and apply them. If your analysts know LogRhythm workflows well and have no one who can write Wazuh decoders, OpenSearch index policies or Sigma translations, the retraining cost and the risk of detection gaps during cutover can outweigh the saving. Similarly, if your organization cannot fund a durable detection engineering function, a managed or supported path, or a fixed-scope partner for the first phase, staying put keeps your detections stable while you build capacity.
Choose self-hosting when the savings and control outlast the transition. The strongest cases are a long remaining horizon, a renewal that sharply increases cost, a data residency requirement that the current deployment no longer meets, or a plan to consolidate log sources the current platform prices poorly. Before committing, confirm three things in writing: the current LogRhythm contract end date and any notice period, the full list of data sources and their daily volume, and the audit evidence your assessor will request for the migration window. A short, well-scoped decision memo built on those facts is usually more useful than a headline comparison of license prices.
How DeployOpen scopes a fixed-price Wazuh implementation
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a LogRhythm replacement, we start with a written scope that separates the one-time migration work from the recurring run costs, so the comparison in this page becomes a plan your finance and security teams can check.
How we scope
- We inventory current LogRhythm subscription terms, support entitlements and appliance hardware before estimating any replacement work.
- We list log sources, agent counts and retention periods so storage and server sizing rest on your own figures.
- We agree deliverables, timelines and exclusions in writing before work starts, since most engagements are fixed-scope.
- Ongoing support, upgrades and continuous testing can be added as a retainer once the initial scope is delivered.
How we build
- We deploy Wazuh indexer, server, dashboard and agents in your cloud accounts, data center or air-gapped network.
- We translate existing detection content and compliance reporting requirements into Wazuh rules and dashboard views agreed with your team.
- We configure the offline vulnerability repository option where your network cannot reach external threat intelligence services.
- We test ingestion, alert paths and dashboards against the sources in scope before cutover.
How we hand over
- We document architecture, sizing assumptions, retention settings and the cost drivers your team will manage after handover.
- We prepare control mappings and evidence packs for your own assessors, noting that DeployOpen does not issue audit reports or certifications.
- We deliver a decommissioning checklist for LogRhythm appliances and confirm the export of historical data your auditors require.
- We run knowledge transfer sessions so your staff can operate, tune and upgrade the platform independently.
How we support
- Retainers can cover Wazuh patch and upgrade work, given the 4.14 patch cadence and the need to schedule each update.
- Continuous security testing of the deployed stack can be scoped separately from the platform support retainer.
- We confirm with you which support scope fits your environment, since Wazuh commercial support is a separate decision from the free software.
- Each retainer or change request is quoted from its own written scope, with no fixed price list.
