Security Onion vs Graylog: which to choose

Security Onion or Graylog: when each one fits

Choose Security Onion when your main question is what crossed the network and where a sensor should sit. It bundles Suricata for intrusion detection, Zeek for network metadata, Strelka for file analysis and full packet capture in one distribution, and its recommended production design splits the work into a manager node, search nodes and sensor nodes. That layout fits a team that can place sensors on network segments, has rack or virtual capacity for them, and wants threat hunting over traffic rather than over application logs. Choose Graylog when your sources are mostly application, server, firewall and identity logs that already flow over syslog, GELF or Beats, and you need streams, processing pipelines and event definitions that route and alert on them. Graylog's storage sits on MongoDB for configuration and a separate search backend, so its footprint follows log volume rather than packet volume.

Both products carry non-OSI licenses, and that matters before any technical comparison. Security Onion's repository is under the Elastic License 2.0, which forbids offering the software as a managed service, and Graylog Open is under the Server Side Public License version 1. Neither license is OSI approved, so have legal review how each one applies to your internal use, any hosting partner you involve and any redistribution you plan. Confirm the current terms in the Security Onion license documentation and the Graylog LICENSE file rather than relying on a summary.

The decision turns on four things: which data sources you must cover, what hardware you can dedicate, which paid features your controls require, and what skills your operators have. Security Onion's documented standalone minimum is 4 cores, 24 GB RAM, 200 GB storage and 2 NICs, and the hardware guidance suggests 32 GB RAM or more once any real traffic is monitored, so confirm sensor placement and capacity with your network team first. For Graylog, check whether you need Enterprise or Security features such as data tiering, correlation or prebuilt detection content, because those sit in paid editions. Write down your top ten log and traffic sources and your alerting needs, then test both platforms against that list before you commit.

Which platform fits which scenario

This table maps common environments to the platform that usually fits better, with the condition that makes each answer hold. Read each row against your own network, log estate and team, because the same requirement can point to different platforms once those change.

Scenario	Better fit	Condition that makes it hold
Network visibility with no existing log pipeline	Security Onion	The team wants network metadata, Suricata alerts and Zeek logs from sensors on mirrored or tapped traffic, and has no central log platform to build on. Confirm the sensor placement and NIC count with the hardware documentation before sizing.
Central log estate with compliance-driven retention	Graylog	Most sources are servers, applications and network devices sending syslog or GELF, and the retention rules are defined by index rotation and archiving. Archiving and correlation sit in paid Graylog Enterprise or Security, so confirm those licenses against the retention requirement.
Team needs packet-level evidence for investigations	Security Onion	Investigators need full packet capture and Suricata or Zeek records tied to alerts in one console. Packet storage is driven by traffic volume, so the sizing must be checked against the monitored links.
Team already runs an OpenSearch cluster	Graylog (on existing OpenSearch) or Security Onion as a separate stack	Graylog works with self-managed OpenSearch from 1.1.x up to 3.7.x, while OpenSearch Security Analytics can run detections without a separate product. Choose Graylog when you want streams, pipelines and event definitions; choose the OpenSearch-native path when that layer is not needed. Confirm version compatibility first.
Strict open-source license requirement	Neither platform fully qualifies	Security Onion is under ELv2 and Graylog Open is under SSPL-1.0, and neither is OSI approved. Teams with an OSI-only policy should consider other options in the SIEM and security monitoring pillar and confirm the position with their legal team.
Small team with limited operating capacity	Graylog Open for log-only use cases	Graylog Open is free with no volume limits and community support, and its operating model is log storage and alerting. Security Onion's distributed design with manager, search and sensor nodes adds more components to run, so compare the staffing with the sensor count.
Hosted SIEM expectations with managed service offering	Depends on the vendor model	The ELv2 license restricts offering Security Onion as a managed service, and Graylog Cloud is a separate vendor-run product. If you plan to resell monitoring, confirm the license terms in writing before choosing either path.

How each platform is built and what that means for operations

Security Onion ships a fixed detection and capture stack on one distribution, while Graylog separates a log server from its configuration database and search storage. Both designs decide who patches what, what fails together, and how much of the stack your team owns after go-live.

Security Onion's bundled detection stack

Security Onion combines Suricata, Zeek, Strelka, full packet capture, Elasticsearch and Elastic Agent in one distribution. Your team gets network detection, file analysis and log search without choosing and integrating those parts separately. The trade-off is that the components move together on the distribution's release cycle, so you test upgrades as a single unit. Ask the vendor which component versions each release ships and how it handles custom rules across them.

Distributed layout of manager, search and sensor nodes

The recommended production design splits Security Onion into manager, search and sensor nodes, with one or more of each for the latter two roles. Sensors sit close to network taps and capture traffic, while search nodes hold indexed data. Plan for more hosts, more network paths and separate patch windows for each role. Confirm how many sensors and search nodes your traffic and retention require before you size the manager.

Manager dependency for indexing

The architecture documentation notes that if the manager goes down, search nodes stop indexing because they cannot reach Redis. A manager outage therefore becomes a logging outage across the deployment, even when sensors keep capturing traffic. Plan maintenance windows for the manager, monitor its health separately, and ask whether your design includes any redundancy for that role. Receiver nodes add pipeline redundancy and load balancing, so confirm whether your layout needs them.

Graylog server nodes and MongoDB

Graylog runs as server nodes that handle inputs, processing and search, with MongoDB holding configuration and metadata. Graylog 7.0 to 7.2 need MongoDB 7.x up to 8.2.x. Your team operates two database tiers, and MongoDB availability limits the whole cluster, so the multi-node guide calls for a replica set. Ask who owns MongoDB backups and version upgrades, since Graylog does not manage that layer for self-managed deployments.

Data Node or self-managed OpenSearch for storage

Graylog stores log data in Graylog Data Node, which Graylog recommends, or in a self-managed OpenSearch cluster. Data Node is the search backend Graylog documents as recommended, and use of OpenSearch 1.x is deprecated since Graylog 7.0. Choosing self-managed OpenSearch means your team owns certificates, cluster membership and version alignment. Confirm which option fits your staffing before you size storage, since index rotation and retention are configured in Graylog but enforced in the backend.

Upgrade paths and what each layout means for operators

Security Onion upgrades arrive as distribution releases, and 2.4 installations on Oracle Linux 9 can move to 3.x only after replacing Stenographer with Suricata, while other distributions need a fresh install. Graylog upgrades are per component: server nodes, MongoDB and the search backend each have their own compatibility range. Ask each vendor for its supported upgrade path, the window for testing custom content, and the staff hours your layout adds to every release.

Capability comparison from supplied facts

This table compares how Security Onion and Graylog cover packet capture, detection content, storage, airgap installs, sign-on and hardware. Read each row as a question to answer for your environment, and treat cells marked to confirm as items to verify with the vendor before you decide.

Capability	Security Onion	Graylog
Packet capture and network IDS	Bundles Suricata, Zeek and full packet capture in one distribution; Suricata replaced Stenographer for packet capture in 3.0.0	Does not bundle packet capture or a network IDS; network sensors must come from separate tools that send logs to Graylog
Log ingestion	Ingests through Elastic Fleet agents and its bundled sensor stack	Inputs include syslog, GELF and Beats, routed through streams and processing pipelines
Detection content	Detections interface manages NIDS rules for Suricata, Sigma rules for ElastAlert and YARA rules for Strelka, with tuning and suppression	Event definitions drive alerts; prebuilt Illuminate detection content sits in paid Enterprise or Security editions
Storage backend	Elasticsearch-based search stack bundled with the distribution	MongoDB for configuration; Graylog Data Node recommended for logs, or self-managed OpenSearch 1.1.x to 3.7.x
Airgap installs	Supported: the ISO carries packages and NIDS, YARA and Sigma rules, and the soup tool updates from newer ISO media	Confirm offline package, rule and update handling for your network with Graylog before planning an airgap install
Single sign-on	OIDC single sign-on is a Security Onion Pro feature; confirm which SSO options your edition supports	Graylog user authentication documentation covers sign-on options; confirm OIDC and LDAP support for your edition
Hardware minimums	Standalone: 4 cores, 24 GB RAM, 200 GB storage and 2 NICs; manager or search node 4 cores and 16 GB RAM; sensor 4 cores and 12 GB RAM; x86-64 only	Sized by daily ingest, retention and a journal of 3 to 5 times daily ingest on SSDs, so hardware follows your log volume rather than a fixed minimum

What each license allows and what costs extra

Security Onion's repository is licensed under the Elastic License 2.0 (ELv2), a source-available license rather than an OSI-approved open-source license. Components moved from the GPL to ELv2 starting with Security Onion 2.4, a change announced on August 31, 2022. ELv2 forbids offering the software to others as a managed service, so a provider cannot host Security Onion for customers as a service without a separate agreement.

Free use: Running Security Onion inside your own organization, including air-gapped networks, does not carry a license fee under ELv2.
Managed service limit: Offering Security Onion as a hosted service to third parties is the restriction most relevant to MSSPs and service providers.
Security Onion Pro: A paid license on 1 to 5 year terms adds OIDC single sign-on, LUKS data-at-rest encryption, FIPS mode, OS STIG compliance, the Security Onion API, external notifications, Manager of Managers, an MCP server, the Onion AI assistant and professional support.
Version timing: Security Onion 2.4 reached end of life on October 1, 2026, and 3.x is the supported line, so license changes and edition terms should be read against the version you deploy.

Confirm with your counsel whether your intended use, including any shared or outsourced operation, falls within ELv2 before you build the platform into a service.

Hardware sizing and what drives it for each platform

Start with the Security Onion minimums, but treat them as a floor for a lab, not a production budget. The hardware documentation lists 4 cores, 24 GB RAM, 200 GB storage and 2 NICs for a standalone node, 4 cores and 16 GB RAM for a manager or search node, and 4 cores, 12 GB RAM and 2 NICs for a sensor. The same documentation suggests 32 GB of RAM or more once you monitor even a small amount of network traffic, so plan above the minimum from the start. Packet capture is the main storage driver. Every sensor writes full packet capture and Suricata output, so the volume of traffic on each monitored segment, and how many days of pcap you keep, set disk size far more than the base 200 GB figure does. Confirm the capture retention you need before ordering disks, and confirm that Security Onion supports only x86-64 processors in your environment.

Graylog sizing works from log volume, not packets. The Graylog system architecture guidance advises sizing log storage as daily ingest multiplied by retention days multiplied by 120 percent, which gives you a storage target for the search backend. Separately, the message journal should be 3 to 5 times daily ingest, placed on SSDs, so that a backlog during an indexer outage does not drop messages. Graylog also needs MongoDB for configuration and a search backend, either Graylog Data Node or self-managed OpenSearch, and each adds its own CPU, memory and disk needs. The official guidance does not publish a single minimum that fits every team, so ask Graylog or your implementation partner to confirm node counts and heap settings against your measured ingest rate.

Both platforms need your own numbers before anyone signs off hardware. Measure sustained and peak network throughput on each monitored segment, the events per second your firewalls, endpoints and cloud accounts send, and the retention your compliance or incident response policy requires. Feed those figures into the Graylog formula and into a packet capture estimate for Security Onion, then size from the larger result. Ask for a written sizing worksheet as part of any quote, and check that it covers the manager and search node tiers for Security Onion and the Data Node or OpenSearch tier for Graylog. A sizing estimate built on assumed traffic is a risk to plan for, so validate it with a pilot on representative traffic before committing to a production layout.

What drives running cost on each side

Running cost on Security Onion and Graylog comes from the same few places: sensors and storage, the people who tune detections, paid editions, and upgrades. The cards below separate what is paid once from what recurs, and list what to ask for before signing either a services or a licensing quote.

Sensor and storage infrastructure

Security Onion needs sensors placed where traffic is visible, plus full packet capture, so its hardware bill grows with the number of links watched and how long packets are kept. Graylog's bill grows with log volume, retention and the search backend. The published minimums are a starting point only (Security Onion lists 4 cores, 24 GB RAM and 200 GB storage for a standalone node). Ask any quote to size storage from your daily ingest and retention, and to state where sensors go on each network segment.

Staff time for detection tuning

Both platforms recur cost in analyst hours: tuning Suricata NIDS rules, Sigma rules and thresholds on Security Onion, or building streams, pipelines and event definitions on Graylog. Security Onion's Console manages NIDS, Sigma and YARA rules in one place, which can reduce the hours spent switching tools, but the tuning work does not go away. Ask who writes and maintains detections after go-live, and how many hours per month the proposal assumes.

Elastic and Graylog administration skills

Security Onion runs on Elasticsearch and Elastic Agent, while Graylog runs on MongoDB and an OpenSearch or Graylog Data Node cluster. Each stack needs administrators who can troubleshoot the search backend, not just the SIEM console. This skills gap is often the largest recurring cost, and it is rarely in the license line. Ask whether the implementation includes handover training and runbooks, and who is on call for the search layer.

Paid editions and support terms

Security Onion Pro is sold on 1 to 5 year terms and adds OIDC single sign-on, FIPS mode, STIG compliance, the Security Onion API and professional support. Graylog Enterprise starts at 15,000 US dollars per year and Graylog Security at 18,000 US dollars per year, each with a minimum of 10 GB per day or 100 Graylog Compute Units. Both are recurring. Confirm which features your controls require before buying, and compare the term length and renewal terms in writing.

Upgrade windows and version moves

Security Onion 2.4 reaches end of life on October 1, 2026. Installs on Oracle Linux 9 can upgrade to 3.x after moving full packet capture from Stenographer to Suricata, while other distributions need a fresh install. On Graylog, use of OpenSearch 1.x is deprecated since Graylog 7.0 and will be removed in Graylog 8.0, so clusters on 1.x need a planned move to Data Node or a supported OpenSearch line. Ask the quote to price the version move, testing and rollback as separate items.

Sensor placement and network changes

On Security Onion, sensor count follows the network design: each segment that needs visibility typically needs a sensor with two NICs, and every new site or cloud subnet adds hardware or virtual capacity. Graylog's collection cost follows the number of sources forwarding logs. Changes in network topology recur as cost on the Security Onion side, while source onboarding recurs on the Graylog side. Ask for a segment-by-segment sensor map in the scope, and a rule for how new segments are added after handover.

Moving between the two without losing evidence

The sequence keeps log and packet evidence intact while detections, dashboards and access move from one platform to the other. Each step closes with a check that the old and new stacks agree before the next one starts.

Inventory log sources and packet needs
Your security engineers list every log source, syslog stream, Beats shipper and sensor that feeds the current platform, and mark which ones need full packet capture. Security Onion's Suricata-based full packet capture and its sensor nodes only cover traffic the sensors can see, so mirror ports, NIC count and sensor placement belong on this list too. The step is done when each source has an owner, a destination on the new platform and a note on whether packets are needed. Confirm the sensor requirements against the Security Onion hardware documentation before you assume a sensor can be reused.
Decide what stays in the old platform
Your compliance lead and the platform owner decide which indexed data and captured packets remain readable in the current stack for the retention period your policy requires, and which can move. Keeping the old cluster read-only for historical searches is often simpler than copying every index, but it also keeps the old license, hosting and patching obligations in place. The output is a written retention decision per data type, signed off before any cutover. Confirm with your legal and records team which evidence must stay in its original form.
Run both platforms in parallel
Point the same sources at the new platform while the old one keeps receiving them, so analysts can compare alert volumes and search results for the same events. Security Onion and Graylog ingest through different paths (Elastic Fleet agents and Security Onion's pipelines on one side, Graylog inputs such as syslog, GELF and Beats on the other), so field names and timestamps will differ and need mapping. The step is complete when a sampled set of known events appears on both sides with matching timestamps and counts. Record any gaps as defects before going further.
Rebuild detections in standard formats
Move detection logic into formats that travel: Sigma rules can be loaded into Security Onion's Detections interface (which loads Sigma rules into ElastAlert) and translated for other backends, and Suricata rule files for network detections can be reused in Security Onion's NIDS tuning workflow. Graylog alerts are not portable in the same way, so each one is rebuilt as a Graylog event definition, with its notification route to PagerDuty, Slack or email set again. The output is a rule register that maps each old detection to its new home, with a test event for each one.
Rebuild pipelines, SSO and access
Graylog streams and processing pipelines do not carry over to Security Onion, and Security Onion's manager, search and sensor layout does not map one to one onto Graylog's server and Data Node roles. Your platform team rebuilds parsing and routing on the new side, then sets up identity. Security Onion OIDC single sign-on is in the paid Security Onion Pro edition, so confirm whether your current identity setup relies on a feature that requires that tier. Graylog authentication settings are documented separately. The check is that each analyst role can log in and sees only the data it should.
Migrate dashboards and user workflows
Analysts rebuild the dashboards and saved searches they rely on in the new interface, starting with the ones used in incident response and audit reporting. Security Onion's Console and Graylog's dashboards use different query models, so most saved views are rewritten rather than exported. Each migrated view is checked against a known-good result from the old platform. Keep a list of the views you have not migrated yet so that nothing critical is dropped at cutover.
Retire the old stack and keep evidence
Once the parallel period has passed its agreed check, the old alerting is switched off first, then ingest, and the old cluster is kept read-only or archived according to the retention decision from step two. Your team confirms that the archived indices and packet files can still be opened and searched by someone who was not involved in the migration. The output is a retirement record listing what was archived, where it is held, who can access it and when it will be deleted. Store that record with your compliance evidence.

Where implementation projects run long

The longest delays in a Security Onion or Graylog project rarely come from the software itself. They come from network access, log source onboarding and rule tuning, and from version choices made before the first install. For Security Onion, the first decision is where the sensors sit. Each sensor needs a tap or mirror port on the monitored segment, and the NICs have to see traffic without being the path it travels. Getting that access through change control often takes longer than the install. Security Onion 3.x also requires Oracle Linux 9, so a team standardized on another distribution should settle that before scoping. Plan airgap updates early too: the soup tool updates from newer ISO media in airgap mode, so the media transfer process into the enclave is part of the operating design, not an afterthought.

On the Graylog side, the version chain drives most of the work. Graylog 7.2 needs MongoDB 7.x up to 8.2.x and an OpenSearch version from 1.1.x up to 3.7.x or Graylog Data Node, per the compatibility matrix. Confirm those pairings against the Graylog compatibility matrix before ordering hosts, since OpenSearch 1.x use is deprecated and removed in Graylog 8.0. A medium or large layout adds three Graylog and MongoDB nodes with a replica set, a separate Data Node cluster, a load balancer and is_leader set to false on follower nodes. Each of those settings needs a test plan. Pipeline design is the other long tail: parsing rules for each log source, stream routing and alert conditions often take more iterations than the cluster build, so scope them as deliverables with named sources.

Whichever platform you choose, the delays follow the same pattern: network access for taps or log forwarding, onboarding each source with its own parsing and field mapping, and tuning detections until alert volume is workable for the analysts. Ask for a written list of log sources and monitored segments, and agree on a tuning acceptance criterion before the project starts. DeployOpen plans and implements both platforms within written, fixed scope, so the delay sources above are named in the statement of work with owners, dependencies and acceptance steps, and a quote follows from that scope.

Questions buyers ask before choosing or hiring help

Can Security Onion replace a log management platform like Graylog?

Only partly, and the answer depends on what you need from the logs. Security Onion is built around Suricata, Zeek, Strelka, full packet capture and Elasticsearch, aimed at network security monitoring and threat hunting. Logs reach it through Elastic Agent and Fleet, but its center of gravity is network evidence, not a stream and pipeline model like Graylog's. Confirm the fit with a written list of log sources, daily volume, retention periods and any routing rules your teams depend on. Security Onion 3.0.0 also replaced Stenographer with Suricata for full packet capture, so check the current release notes before you plan against older documentation.

Does Graylog capture network packets?

The documented Graylog inputs are log-based. Graylog Open ingests logs over inputs such as syslog, GELF and Beats, then routes them through streams and processing pipelines for search, dashboards and alerts. Packet capture and network intrusion detection are where Security Onion's Suricata sensors and full packet capture fit. If your monitoring requirement includes packet-level evidence, plan a sensor layer for it, and confirm any packet-related input with the Graylog installation and input documentation before you assume it is available in your edition.

What do the licenses mean for internal use versus a managed service?

Running either platform for your own organization is the common case, but the license terms differ. Security Onion is licensed under the Elastic License 2.0, which is source-available rather than OSI approved, and its license documentation says it forbids offering the software as a managed service. Graylog Open is licensed under the Server Side Public License version 1, which is also not OSI approved, and it has been the license since Graylog 4.0 in 2020. If you plan to offer monitoring to customers or affiliates, have counsel read both license texts against your model before you commit.

How much effort does each platform need to run without a partner?

Both need sustained operating effort, and the main drivers are architecture and data volume. Security Onion lists bare minimum hardware of 4 CPU cores, 24 GB RAM and 200 GB storage for a standalone install, and suggests 32 GB of RAM or more when monitoring even a small amount of traffic. Its recommended production design is distributed, with manager, sensor and search nodes, and if the manager goes down, search nodes stop indexing. Graylog's multi-node guide recommends three Graylog and MongoDB nodes, three Data Nodes and a load balancer, and its architecture page advises sizing storage as daily ingest times retention days times 120 percent. Ask your team to estimate patching, certificate work and on-call load for each layout.

Which paid tiers are required for single sign-on and correlation?

It depends on the feature and the platform. Security Onion Pro, a paid edition sold on 1 to 5 year terms, adds OIDC single sign-on to the Security Onion Console along with FIPS mode, OS STIG compliance and professional support. On the Graylog side, the correlation engine is part of Graylog Enterprise, which starts at 15,000 US dollars per year according to Graylog's pricing page, and Graylog Security starts at 18,000 US dollars per year and adds SIEM features such as prebuilt threat detection content. Both Graylog tiers have a minimum of 10 GB per day or 100 Graylog Compute Units and are licensed on processed data. Confirm which Graylog edition includes the SSO method you need in the current user authentication documentation.

Does a consultant quote follow from a written scope?

Yes. DeployOpen does not publish a price list, and a quote follows from the scope agreed in writing. Most engagements are fixed-scope, with scope, deliverables and timelines set before work starts. Your scope should name the platform choice, log and network sources, daily volume, retention, sensor locations, high availability requirements, whether the network is air-gapped (Security Onion supports airgap installs from ISO media), and the evidence your compliance team needs. Ongoing support, upgrades and continuous testing are available as retainers, and they are priced separately from the initial build. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications.

Will DeployOpen issue compliance certificates for a SIEM deployment?

No. DeployOpen plans, implements, hardens and documents self-hosted platforms, and it prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. For a log or network monitoring deployment, the evidence typically covers access controls, log retention settings, alert handling records and backup procedures. Ask your assessor early which of those artifacts they expect, and confirm with them which platform settings they will test before the build is fixed.

How DeployOpen helps choose, implement or migrate

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure. For Security Onion vs Graylog, we start from the licensing, sensor placement and log volume you already have, then write down what would be built before any work begins.

How we scope

We confirm whether the need is network traffic monitoring, log management or both before choosing a platform
The written scope lists sensors, search nodes, log sources, detection content and the hardware each one will run on
We record which paid edition features, such as Pro or Enterprise, are in scope and which are left out
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts

How we build

We deploy the chosen platform in your cloud accounts, data centers or air-gapped network
Log inputs, parsers, alert rules or Suricata and Zeek sensor configuration are set up against your sources
Detection content is tested against sample traffic or logs to confirm alerts fire and noise is controlled
Hardening, access control and backup settings are applied and checked against your own security baseline

How we hand over

Architecture, sizing and license notes are documented so your team knows what each component does
Runbooks cover upgrades, retention changes, rule tuning and recovery steps for the manager or Graylog server
Evidence of configuration and testing is delivered so your compliance team can prepare for an independent assessment
Your operators are walked through daily tasks so the platform can be run without DeployOpen on call

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover
Retainer scope is agreed in writing, including which release lines and components are covered
Upgrade planning checks each release against the vendor's end-of-life dates and compatibility notes
Confirm with us which support terms and response expectations apply before you sign

Security Onion vs Graylog