When a standalone Security Onion box fits and when to choose distributed
Run a standalone Security Onion box for labs, proofs of concept and very low-throughput sites. Choose the Distributed deployment type for production, because Security Onion's documentation names it the recommended design, with a manager node, one or more sensor nodes and one or more search nodes. A standalone install runs every component on one box and routes logs through Logstash and Redis, and the architecture documentation says it is not as scalable as a distributed deployment. Evaluation and Import are not production choices: Evaluation is built for a quick temporary test, and Import only loads PCAP or evtx files and cannot add Elastic agents or other nodes.
The decision comes down to upfront hardware against scalability and performance. Security Onion's documentation says Distributed may cost more upfront but gives greater scalability and performance. Standalone needs at least 4 cores, 24 GB RAM, 200 GB storage and 2 NICs, and the hardware page suggests 32 GB of RAM or more once any meaningful traffic is monitored. Sensors need their own hardware for Zeek, Suricata and local full packet capture, so ask your team to size sensor, search and manager nodes against the traffic you expect rather than against the standalone minimum. Confirm current figures on the Security Onion hardware requirements page before you request a quote.
Plan for resilience before you commit. In a distributed layout, search nodes pull from the Redis queue on the manager, so if the manager goes down, search nodes stop indexing. Receiver nodes, which run Logstash and Redis, reduce manager load and add pipeline redundancy in an active-active arrangement, and they can be added as needed. Ask your vendor or implementation partner how they will handle manager failure and receiver sizing, and whether a Manager Search combined node is acceptable for your volume, since the documentation says it performs below a dedicated manager with separate search nodes.
Standalone and distributed side by side
This table compares standalone and distributed Security Onion deployments on intended use, node layout, documented hardware minimums, scalability, failure behavior and upgrade scope. Read the standalone column for labs, proofs of concept and low-throughput testing, and the distributed column for production designs. The documented minimums do not size real traffic, so confirm node counts, storage and sensor limits with Security Onion Solutions before you buy hardware.
| Aspect | Standalone | Distributed |
|---|---|---|
| Intended use | Testing, labs, proofs of concept or very low-throughput environments | Recommended design for production environments |
| Node count | One box running all components | A manager, one or more sensor nodes and one or more search nodes |
| Minimum hardware per role | 4 cores, 24 GB RAM, 200 GB storage, 2 NICs. Suggests 32 GB RAM or more for even small traffic. | Manager or search: 4 cores, 16 GB RAM. Sensor: 4 cores, 12 GB RAM, 2 NICs. Confirm storage per role. |
| Scalability and throughput ceiling | Not as scalable as distributed; no documented ceiling, so confirm sizing with the vendor | Greater scalability and performance; add search or receiver nodes as load grows |
| Failure when the manager is down | All components share one box, so a host failure stops monitoring | Search nodes stop indexing because they cannot reach Redis on the manager |
| Supported sensor count | No separate sensor nodes; sensing runs on the same box | One or more sensors; confirm the maximum per manager with Security Onion Solutions |
| Manager and search roles | Not applicable; all roles run on one system | A combined manager search node needs more hardware and performs below a dedicated manager |
| Upgrade scope | One system to upgrade and test | Every node role in the cluster; confirm the upgrade order in the vendor documentation |
Node roles in a distributed Security Onion layout
A distributed Security Onion deployment splits work across a manager, search nodes, sensors and optional receiver and heavy nodes. Each role changes where logs queue, where they are parsed and indexed, and what breaks when one box fails. Check the role list against your throughput and your tolerance for a manager outage before you size hardware.
Manager node
The manager coordinates the deployment and hosts the Redis queue that search nodes pull from. Logs from sensors pass through Logstash on the manager before they are queued. Because the queue lives here, the manager is the component to plan redundancy around. The architecture documentation notes that if the manager goes down, search nodes stop indexing because they cannot reach Redis. Confirm your recovery procedure for this case before go-live.
Search nodes
Search nodes pull logs from the Redis queue on the manager, then parse and index them. Adding search nodes is the main way to spread indexing work out of the manager. Separating search from the manager is the documented layout for production, and it is the reason a manager search node performs below a dedicated manager. Size search capacity against your daily event volume and ask your vendor or partner how indexing load scales as nodes are added.
Sensor nodes
Sensor nodes run Zeek and Suricata, forward alerts and logs through Elastic Agent to Logstash on the manager, and keep full packet capture locally. Packet data stays on the sensor rather than moving across the network, which affects storage planning at each sensor site. Each sensor needs its own capture interfaces and disk. Check the sensor minimums against the traffic each site actually sees, since the documented minimum hardware is for a sensor, not for a busy tap.
Receiver nodes
Receiver nodes run Logstash and Redis to take load off the manager and add pipeline redundancy. They operate active-active and can be added as needed, which makes them the documented option when the manager is the bottleneck or a single point of failure in your design. Receivers add hardware and another component to patch and monitor. Ask whether your ingest volume justifies them before you budget for extra boxes.
Heavy nodes
Heavy nodes are a combined role that the documentation does not recommend for most users because of performance. Treat them as a special case for specific hardware or traffic patterns rather than a default for a team sizing its first production deployment. If you are considering one, get the performance tradeoffs in writing from the vendor and test them against your real log and traffic profile.
Manager search node and Fleet path
A manager search node combines the manager and search roles on one box, which saves hardware but performs below a dedicated manager with separate search nodes and needs more hardware. Endpoints and sensors reach the platform through Elastic Agent and Fleet, so agent enrollment and policy depend on the manager being healthy. Confirm how your agents will be enrolled and updated, and plan for manager-side work whenever the Fleet path is affected.
What happens to indexing when the manager goes down
In a distributed Security Onion deployment, the manager is a single point of dependency for indexing. Search nodes pull logs from the Redis queue on the manager, parse them and index them. The Security Onion architecture documentation states that if the manager goes down, search nodes stop indexing because they cannot reach Redis. Sensors may keep capturing traffic locally, but events that a search node would otherwise have indexed will not reach the search tier until the manager returns. Before you size a distributed design, decide how much of a manager outage your SOC can tolerate and whether a gap in indexed data during that window is acceptable for detection and investigation.
Receiver nodes are the documented way to reduce that exposure. They run Logstash and Redis, which takes intake and queuing load off the manager and adds pipeline redundancy. Receivers operate active-active and can be added as your event volume grows, so the design is not fixed at the point of first install. The architecture documentation describes receivers as adding pipeline redundancy and load balancing, but it does not, on its own, describe a complete high availability design for the manager itself. Treat receivers as a way to spread load and reduce a single intake path, not as proof that the manager can fail without consequence.
Before relying on any failover behavior, ask Security Onion Solutions to confirm in writing how a manager outage affects queued events, what happens to search nodes during and after recovery, and whether a supported high availability layout exists for your version. Test the outage in a non-production environment that mirrors your node roles, and record how long indexing lags and whether any events are lost. Include the cost of extra receiver hardware and the operating effort of monitoring those nodes in your sizing decision, since the hardware minimums in the Security Onion hardware documentation apply to each node you add.
Sizing a distributed layout step by step
This sequence turns the distributed design into a sized, documented node plan that matches your traffic, retention and network access constraints before any hardware is ordered or built.
Confirm traffic volume and retention needs
Start by measuring the traffic each monitored segment carries and writing down how long you need logs and full packet capture kept for investigations and compliance. Your security engineers and the team that owns the network should own this, since they know the link speeds and peak periods. Use the output as the basis for every later sizing decision. The step is done when you have a written traffic profile per segment and a retention target signed off by the people who will rely on the data. Treat the Security Onion hardware minimums as a floor, not a sizing result, and confirm the figures with Security Onion Solutions or your own pilot measurements before procurement.
Choose sensor placement across network segments
Decide where sensor nodes sit so each one sees the traffic it must monitor, usually at chokepoints such as internet egress, data center boundaries and sensitive segments. Sensors run Zeek or Suricata, keep full packet capture locally and forward alerts and logs onward, so each placement also determines local storage and NIC needs. The network architect and the security team should agree the map together and check it against the documented sensor minimums of 4 cores, 12 GB RAM and 2 NICs. The step is complete when you have a diagram that lists each sensor, the segment it watches and its mirror or tap source.
Size manager and search nodes against minimums
Size the manager and search nodes using the documented minimum of 4 cores and 16 GB RAM for each role, then increase capacity based on your traffic profile and retention target. Keep the manager dedicated where possible, because the Manager Search combined role performs below a dedicated manager with separate search nodes and needs more hardware. Ask Security Onion Solutions to confirm sizing for your expected ingest rate, since the minimums do not represent production throughput. The step is done when the platform team has a written spec for each node with CPU, memory and disk figures and a note on the sizing basis.
Add receiver nodes if manager load requires it
Add receiver nodes only if measurements show the manager is overloaded or if you need pipeline redundancy. Receivers run Logstash and Redis to take load off the manager and operate active-active, so they can be added as needed. Because the architecture documentation notes that search nodes stop indexing when they cannot reach Redis on the manager, an outage without receivers halts ingest, so evaluate this risk explicitly. The step is complete when you have a decision record that either states why receivers are omitted or lists their count, placement and network paths.
Validate the design in a lab before production
Build the planned layout in a test environment and replay representative traffic, such as captured PCAP, to confirm that logs flow from sensors through Redis to search nodes without backlog. Standalone and Evaluation modes are for testing only and do not reproduce the distributed topology, so do not use them to prove production sizing. Record queue depth, indexing lag, CPU and disk use under load and any dropped events. The step is done when the lab results meet the throughput and retention targets set in the first step, and a named owner has accepted them in writing.
Plan airgap updates if there is no internet access
If the monitored or management networks have no internet access, plan how updates reach every node before go-live. Security Onion supports full installs without internet access, with the ISO carrying packages and NIDS, YARA and Sigma rules, and the soup update tool can apply updates from newer ISO media in airgap mode. The operations lead should define the media transfer process, the approval path and the update cadence across the manager, search, receiver and sensor nodes. The step is complete when a documented runbook shows how each node receives its next update and how the team verifies the result.
Confirm sizing with the vendor and your own traffic
Before you sign off, confirm the final node sizing with Security Onion Solutions, your implementation partner and the team that will operate the platform, using the lab data and your traffic profile. Ask for written confirmation of supported throughput per node class, the upgrade path and any Pro features you need, such as OIDC single sign-on or Manager of Managers. Revisit the design when traffic grows or the network changes. The step is done when the signed sizing document, the lab report and the runbook are filed together and the team knows the trigger for the next review.
Upgrades, backups, monitoring and skills for each layout
This table compares the ongoing upkeep of a standalone Security Onion box with a distributed manager, search and sensor layout. Read each row as a question to put to your own team: how many nodes change during an upgrade, what a rebuild involves, and which skills you must have in-house before you choose the distributed design.
| Area | Standalone | Distributed |
|---|---|---|
| Upgrade scope | One box to update with the soup tool, so the change window covers a single host and its services. | The soup tool must run in step across the manager, search, receiver, heavy and sensor nodes, so the plan must sequence node order and confirm each node before the next. |
| End of life planning | Security Onion 2.4 reached end of life on October 1, 2026. Confirm whether your 2.4 standalone host runs Oracle Linux 9, because a 2.4 install on another distribution needs a fresh install to reach 3.x. | Same end of life date applies to every 2.4 node. Map each node's operating system before scheduling, since a mixed fleet can split the upgrade path. |
| Current release target | Security Onion 3.3.0 (hotfix 20260911) is the current release per the Security Onion release notes. Confirm the target build against the release notes before you plan. | Target 3.3.0 on all nodes together and confirm version parity across the fleet before you resume ingestion. |
| Backup scope | One host holds configuration, detections, indexed data and packet capture, so the backup set is simpler to define but larger on one disk. | Back up the manager configuration and each search and sensor node separately. Ask the vendor which state is held on each role and what a restore of a single node requires. |
| Rebuild effort | A failed standalone host is rebuilt from install media and restored data, which means a single rebuild path and one set of hardware to replace. | A failed search node can be rebuilt on its own, but a manager failure stops indexing because search nodes cannot reach Redis, so the manager has the widest recovery impact. |
| Monitoring | Watch one host for CPU, memory, disk, NIC drops and service health across the full pipeline. | Watch each role separately: Redis queue depth on the manager, Logstash and indexing health on search and receiver nodes, and capture and forwarding health on sensors. |
| Skills for Redis and Logstash | Troubleshooting covers one local pipeline. Staff still need Logstash and Redis basics, but failures are contained to one host. | Staff need to trace a log from sensor forwarding through Logstash and the Redis queue to search indexing. Confirm which of these skills your team already holds before you commit to this layout. |
| Hardware sizing for operations | Minimum listed as 4 cores, 24 GB RAM and 200 GB storage, with 32 GB RAM or more suggested for even small traffic volumes, per the Security Onion hardware documentation. | Minimums listed as 4 cores and 16 GB RAM for a manager or search node, and 4 cores and 12 GB RAM for a sensor, per the hardware documentation. Ask for sizing against your traffic before you buy. |
What drives the cost of extra hardware and operations
The main cost of moving from standalone to distributed is extra hardware per node role, and the documented minimums set the floor. The Security Onion hardware documentation lists 4 cores and 16 GB RAM for a manager or search node, and 4 cores, 12 GB RAM and 2 NICs for a sensor, compared with 4 cores, 24 GB RAM, 200 GB storage and 2 NICs for a standalone node. Those are minimums, not sizing. The architecture documentation says a Manager Search node performs below a dedicated manager with separate search nodes and needs more hardware, so a realistic budget depends on your traffic volume, retention and search load. Ask Security Onion Solutions or a partner to size each role in writing, with the storage and throughput assumptions stated, and to list which nodes are one-time purchases and which are recurring cloud or data center charges.
Licensing is a separate line that recurs. Security Onion itself is free under the Elastic License 2.0, but Security Onion Pro is a paid edition sold on 1 to 5 year terms, and it is licensed per node. If you need OIDC single sign-on, FIPS mode, OS STIG compliance or the Security Onion API, price each node that will run Pro and confirm whether receiver, search and sensor nodes are counted the same way. Ask what happens at renewal and whether a lapsed license changes how a running cluster behaves. Staff time is the cost most often underestimated: every extra node is another system to patch, monitor and back up, and the architecture documentation notes that search nodes stop indexing when the manager is unreachable, so the on-call design matters as much as the hardware count.
Network and logistics costs are easy to miss in a quote. Each sensor needs a monitoring position on the traffic it inspects, which can mean switch SPAN ports, taps or changes to cabling and VLAN design, and those changes are usually one-time work with change control overhead. Airgapped networks add a recurring step: the Security Onion airgap documentation says the ISO carries packages and NIDS, YARA and Sigma rules, and that the soup update tool updates from newer ISO media, so someone must move each release across the boundary. Ask the vendor or partner to itemize sensor placement, network changes, airgap media handling and who performs each task, and to state which items are included in a fixed-scope engagement and which are excluded.
Questions buyers ask before choosing a layout
Can a standalone Security Onion deployment grow into a distributed one later?
Security Onion's architecture documentation describes standalone as typically used for testing, labs, proofs of concept or very low-throughput environments, and says it is not as scalable as a distributed deployment. Moving to distributed therefore means adding nodes and changing roles rather than flipping a setting, so the work depends on how the standalone box was configured and what data it already holds. Ask whether the existing data, rules and tuning will carry over, and whether the plan keeps sensor placement and packet capture storage intact during the move. Review the Security Onion architecture documentation before deciding whether a standalone build is a sound first step.
How much extra hardware does a distributed Security Onion deployment need at minimum?
The documented minimums are 4 cores and 16 GB RAM for a manager or search node, and 4 cores, 12 GB RAM and 2 NICs for a sensor. A standalone node needs 4 cores, 24 GB RAM, 200 GB storage and 2 NICs. The hardware page also suggests 32 GB of RAM or more for a standalone install monitoring even a small amount of traffic, so real sizing will exceed these minimums. Distributed adds machines, and each sensor and search node brings its own storage, power, network and operating effort. Ask for a sizing review against your traffic rate, retention period and sensor count, and confirm that the platform supports only x86-64 processors. The hardware requirements page lists the figures.
Can one internal team run a distributed Security Onion deployment without outside help?
It depends on whether the team already operates Linux, network sensors, Elasticsearch-based search and an upgrade process. Distributed deployments add a manager, sensors and search nodes that must stay in step, and Security Onion's documentation notes that search nodes stop indexing when the manager is down. Your team will own patching, upgrades, backups, detection tuning and capacity planning for each node role. Some teams run this in-house, while others bring in an implementation partner for the initial build and a retainer for ongoing support. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in the client's own infrastructure, and most engagements are fixed-scope with scope and timelines agreed in writing before work starts.
What skills and staff time does a distributed Security Onion deployment require?
Plan for staff who understand network sensors, Linux administration, Elasticsearch-style indexing and the Security Onion Console. Work recurs after go-live: tuning NIDS, Sigma and YARA detections in the Detections interface, monitoring queue health between the manager and search nodes, and applying Security Onion release updates. The airgap documentation says the soup update tool updates from newer ISO media in airgap mode, which matters if your networks have no internet access. Ask the vendor or partner to describe the staff roles needed, the on-call expectations and the runbooks for losing the manager, and confirm how many hours per month your own team will spend on each area.
How long does migrating from standalone to distributed take, and what drives that effort?
No duration is documented for this migration, so treat any figure you hear as something to verify against your own scope. The main drivers are the number of sensors and search nodes, the volume of data you need to keep, the number of rule and detection customizations to carry over, network changes needed to place sensors on mirror or tap points, and whether the change happens in production or in a parallel build. Security Onion 2.4 upgrades to 3 on Oracle Linux 9 require moving full packet capture from Stenographer to Suricata, which shows that version changes can add work beyond node placement. Ask for a written migration plan with a rollback step and a list of data that will be preserved.
Is Security Onion Evaluation mode safe to run in production?
No. The Security Onion architecture documentation says Evaluation mode is designed for a quick temporary test and is not designed for production usage at all. Use Standalone or Distributed for production. Import mode is also limited: it imports PCAP or evtx files and does not support adding Elastic agents or other nodes. Treat an evaluation build as a way to learn the console and detections, then plan the production layout separately with the hardware and node roles the documentation describes. The architecture documentation explains each deployment type.
What does the distributed design cost in resilience, and how do receiver nodes change that?
A single manager is a dependency. If it goes down, search nodes stop indexing because they cannot reach Redis, so log ingestion pauses until service returns. The architecture documentation says receiver nodes run Logstash and Redis to reduce manager load and add pipeline redundancy, operate active-active, and can be added as needed. Receivers add more machines, more configuration and more monitoring, so the trade is between extra hardware and fewer single points of failure. Ask how the design handles manager outages, what buffering exists during an outage, and how receivers are placed relative to sensors.
How DeployOpen scopes a Security Onion deployment
DeployOpen plans, implements, hardens, documents and supports self-hosted Security Onion inside your own infrastructure, whether that is your cloud accounts, your data centers or an airgapped network. For a distributed design, scoping starts with the node layout: how many manager, receiver, search and sensor nodes, where each sits relative to the monitored links, and how the manager-to-search path is protected, since search nodes stop indexing when they cannot reach Redis on the manager. For airgapped sites, scoping also covers how the ISO media, NIDS, YARA and Sigma rule content and the soup update path will reach the network and on what cadence. Confirm with your team which Security Onion version and operating system your standards require before the design is fixed, because Security Onion 3.x supports only Oracle Linux 9.
Most DeployOpen engagements are fixed-scope. The scope, deliverables and timelines are agreed in writing before work starts, so the written scope is the document you compare against other proposals. Ask any implementation partner to state in that document which node roles are in and out, which hardware they have validated against the minimums in Security Onion's hardware documentation, who installs and tunes detections, how the production manager is backed up and restored, and what handover documentation you receive. DeployOpen does not publish a price list, and a quote follows from that written scope. Costs that recur, such as ongoing support, upgrades and continuous testing, are offered as retainers, so ask for them as a separate line item from the one-time build.
Ask for the scope to name the decision points that drive cost up or down: the number of sensors and the traffic each one sees, whether receiver nodes are needed to take load off the manager, and whether you need Security Onion Pro features such as OIDC single sign-on, which are a separate paid license. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, so any assurance you need must come from an independent auditor or certification body. Confirm with the vendor, in writing, the current licensing terms for the edition you choose, because the Security Onion license is Elastic License 2.0 and it forbids offering the software as a managed service.
How DeployOpen delivers and supports Security Onion
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the standalone or distributed layout is sized to your network and your evidence needs. Work starts from a written, fixed scope that names the node roles, sensors, storage and hand-over deliverables before any build begins.
How we scope
- Written scope names the node roles, sensor placement and search capacity agreed for your environment.
- We record which traffic each sensor sees, expected throughput and where full packet capture will be kept.
- Scope states whether the first phase is a standalone proof of concept or a production distributed layout.
How we build
- We install and configure manager, search, receiver and sensor nodes in your cloud accounts, data centers or air-gapped network.
- Build covers Redis and Logstash flow between nodes, retention settings and the detection content you choose to load.
- Each node is tested for failover behavior, including what happens to indexing when the manager is unavailable.
How we hand over
- Handover includes architecture and runbook documentation covering node roles, upgrade steps and backup procedures.
- Your team receives configuration records and evidence of the tests run against the agreed scope.
- Engagement terms state which operational tasks move to your staff and which remain under a support retainer.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainer scope should be agreed in writing, including upgrade windows for Security Onion releases and how node additions are handled.
- Ask for the support boundary in writing, covering who responds to a manager outage and within what agreed timeframe.
