Build a Mini SOC with a Raspberry Pi 5: Security Monitoring for Up to 25 Endpoints
Turn a Raspberry Pi 5 into a practical Mini SOC with Wazuh. Monitor up to 25 Windows, Linux and macOS endpoints, detect vulnerabilities, watch file changes and centralize security alerts without buying an enterprise SIEM.
Scope
Turn a Raspberry Pi 5 into a practical Mini SOC with Wazuh. Monitor up to 25 Windows, Linux and macOS endpoints, detect vulnerabilities, watch file changes and centralize security alerts without buying an enterprise SIEM.
A Security Operations Center usually brings a very particular picture to mind: a dark room, six large screens per person, maps with red dots flashing somewhere over Eastern Europe, expensive SIEM licences and at least one analyst who hasn't seen daylight since Tuesday.
That is one version of a SOC.
The other version is a small company with fifteen laptops, three servers, a firewall, a NAS, maybe a MikroTik somewhere in a cupboard, and one unfortunate IT administrator who is expected to know immediately when something suspicious happens.
This article is about the second one.
We are going to build a small but genuinely useful security monitoring system using a Raspberry Pi 5, an NVMe SSD and Wazuh, with the goal of monitoring roughly 10 to 25 endpoints without pretending that a €100-ish single-board computer has somehow become an enterprise SIEM cluster.
It hasn't.
But that doesn't mean it can't be surprisingly useful.
In fact, for a small organisation where the alternative is usually “we have logs somewhere, probably”, a Raspberry Pi running Wazuh can provide a rather dramatic improvement in visibility.
The finished system will give us one place where we can see failed logins, new user accounts, administrator group changes, vulnerable software, important file modifications, suspicious events from Linux servers, Windows security events and logs coming from network equipment.
That is already quite a lot of SOC for something roughly the size of a deck of cards.
First question: can a Raspberry Pi actually run Wazuh?
Yes.
And, importantly, we're no longer talking about an unofficial weekend project where somebody compiled half of the stack from source, sacrificed three goats to dependency management and posted a GitHub repository that hasn't been updated since 2021.
Current Wazuh central components support 64-bit ARM/AARCH64, including the Wazuh server, indexer and dashboard. ARM support for the central components was added officially in Wazuh 4.12.
That makes the Raspberry Pi 5 a legitimate platform for a small installation.
However, there is an important difference between:
“The software runs.”
and:
“The software runs well enough that I would trust it to monitor my infrastructure.”
The second question is the interesting one.
Wazuh's current sizing recommendation for an all-in-one deployment looks like this:
| Agents | Recommended CPU | Recommended RAM | Approx. storage for 90 days |
|---|---|---|---|
| 1–25 | 4 vCPU | 8 GiB | 50 GB |
| 26–50 | 8 vCPU | 8 GiB | 100 GB |
| 51–100 | 8 vCPU | 8 GiB | 200 GB |
The Raspberry Pi 5 gives us a 2.4 GHz quad-core Cortex-A76 processor, Gigabit Ethernet, PCIe connectivity for fast storage and up to 16 GB of RAM.
You can probably already see where I am going with this.
Twenty-five agents make sense.
Fifty agents make for a much better YouTube thumbnail.
Those are not necessarily the same thing.
Could you connect more than 25 agents to the Pi? Almost certainly.
Could 30 or even 40 mostly idle office PCs work? Quite possibly.
But this is a security system, and security systems have an annoying habit of receiving their biggest workload at exactly the moment when everything else is going wrong.
If a compromised host suddenly generates thousands of events, that is not the ideal moment for your monitoring server to announce that it has reconsidered its career choices.
So we are going to be conservative.
Our target is 10–25 endpoints.
What exactly are we building?
The architecture is refreshingly boring.
And boring infrastructure is usually good infrastructure.
Windows laptops
│
Linux servers
│
macOS
│
Wazuh Agent
│
▼
┌─────────────────────────┐
│ Raspberry Pi 5 │
│ │
│ Wazuh Server │
│ Wazuh Indexer │
│ Wazuh Dashboard │
│ │
│ 16 GB RAM │
│ NVMe SSD │
└────────────┬────────────┘
│
HTTPS
│
▼
Web Dashboard
The Wazuh agent runs on Windows, Linux or macOS endpoints and collects security-related information.
That information is sent to the Wazuh server, where events are decoded and evaluated against rules.
Interesting alerts are then written into the Wazuh indexer, which is effectively the storage and search engine behind the system.
Finally, the Wazuh Dashboard gives us the interface where we can investigate what is happening.
Wazuh calls this an all-in-one deployment, because the server, indexer and dashboard all live on the same machine. Wazuh specifically describes this architecture as suitable for labs and smaller environments with a limited number of endpoints.
And yes, placing all three components on a Raspberry Pi feels slightly ridiculous the first time you do it.
That is part of the appeal.
Hardware: don't ruin the project with a microSD card
The basic hardware is simple:
- Raspberry Pi 5 with 16 GB RAM
- active cooling
- a proper USB-C power supply
- an M.2 HAT or compatible NVMe adapter
- 500 GB or 1 TB NVMe SSD
- a case with sensible airflow
- Ethernet
The Raspberry Pi itself isn't the part I would worry about first.
The storage is.
You absolutely can boot a Raspberry Pi from a microSD card, install a database-heavy security platform on it and congratulate yourself when the dashboard appears.
Then the system starts indexing events 24 hours a day.
At that point your poor microSD card discovers that the phrase “high endurance” on the packaging may have been more of a motivational statement than a technical specification.
For a Wazuh installation, use NVMe.
The Raspberry Pi 5 exposes PCIe 2.0 x1 specifically for fast peripherals such as NVMe storage through an appropriate adapter, so there is very little reason not to use it.
I would choose a 1 TB SSD unless the budget is extremely tight.
You probably don't need one terabyte on day one, but SIEM data has the same magical property as old backups: no matter how much storage you have, sooner or later it will start explaining why it needs all of it.
Why the 16 GB Raspberry Pi?
Wazuh says 8 GiB of RAM for an all-in-one deployment with up to 25 agents.
So technically an 8 GB Raspberry Pi looks tempting.
And it might work.
But remember what we are running on this one little board: Linux itself, the Wazuh manager, dashboard and — most importantly — the indexer.
The indexer is the hungry part of this family.
Wazuh's dedicated indexer requirements list 4 GB RAM and 2 CPU cores as a minimum, while the recommended configuration for a dedicated indexer node is significantly larger at 16 GB and 8 cores.
Obviously our small installation isn't going to generate enterprise-scale traffic, but having memory available for the JVM, filesystem cache and occasional event spikes is still useful.
So if this machine is going to spend the next several years quietly judging every computer on your network, give it the 16 GB model.
It deserves it.
Operating system
For this build I would use:
Ubuntu Server 24.04 LTS ARM64
You could use other supported distributions, but Ubuntu Server has one major advantage for a project like this: it is boring, well documented and extremely easy to troubleshoot.
For servers, boring is a compliment.
Install Ubuntu directly on the NVMe SSD and boot the Raspberry Pi.
Once logged in, check the architecture:
uname -m
You should get:
aarch64
Then check memory:
free -h
And storage:
lsblk
You want to confirm that the system is actually running from the NVMe SSD and not from the microSD card you forgot was still inserted.
Ask me how I know.
Prepare the Raspberry Pi
Start with the traditional Linux administrator ritual:
sudo apt update
sudo apt full-upgrade -y
sudo reboot
After rebooting, give the machine a useful hostname.
sudo hostnamectl set-hostname soc01
Please don't call it raspberrypi.
Six months from now, when there are four Pis on the network and somebody asks which one contains the company's security logs, raspberrypi stops being charming surprisingly quickly.
Give it a fixed address, either using a DHCP reservation or static addressing.
For example:
SOC01
192.168.10.20
The exact address doesn't matter.
What matters is that it doesn't suddenly become 192.168.10.143 because somebody rebooted the router.
Installing Wazuh
Current Wazuh releases provide an installation assistant that can install the server, indexer and dashboard together.
At the time of writing, the Wazuh 4.14 installation assistant is downloaded with:
curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh
Then the complete all-in-one installation can be started with:
sudo bash ./wazuh-install.sh -a
Now make coffee.
Not because this takes three hours, but because staring at installation output doesn't make it faster, despite decades of evidence suggesting that system administrators will continue trying.
When installation completes, the assistant provides the address of the Wazuh Dashboard together with the initial administrator credentials.
It will look something like:
https://192.168.10.20
Username: admin
Password: something-you-should-save-now
And yes, save the password immediately.
The fastest way to discover that a password manager would have been useful is to close the terminal containing the only copy of your password.
Open the address in your browser.
You may initially see a certificate warning because the installation uses its own certificates.
Once logged in, you should see the Wazuh Dashboard.
Congratulations.
You now technically own a SIEM.
Your Raspberry Pi still looks exactly the same.
Check that the important parts are alive
Before adding endpoints, make sure the central services are running.
sudo systemctl status wazuh-manager
Then:
sudo systemctl status wazuh-indexer
And:
sudo systemctl status wazuh-dashboard
You want all three services running normally.
You can also check listening services with:
sudo ss -lntup
If everything is healthy, resist the temptation to immediately connect every computer in the building.
Add one.
Make sure it works.
Then add another.
Security platforms reward patience and punish enthusiasm.
Add your first Windows computer
Log in to the Wazuh Dashboard and open the agent deployment section.
Select Windows and enter the address of your Raspberry Pi:
192.168.10.20
Wazuh generates the appropriate installation command for the agent.
Run that command from an elevated PowerShell window on the Windows machine.
After installation, make sure the agent service is running:
Start-Service wazuhsvc
Within a short time, the endpoint should appear in the dashboard.
This is the moment when the project starts becoming interesting, because instead of a nice empty dashboard you suddenly have a computer reporting what is actually happening on it.
Once you start adding multiple endpoints, I would create logical groups such as:
workstations
servers
linux
management
That becomes useful later because a developer workstation, an accounting PC and a public web server should probably not have identical monitoring policies.
Unless your security strategy is “one XML file to rule them all”, which is certainly a strategy, just not one I would recommend.
So what does the agent actually see?
Quite a lot.
And this is one of the reasons Wazuh works so well for small environments: you're not simply forwarding Windows Event Logs into a giant searchable bucket and calling it security.
The agent can provide system inventory, security events, file integrity monitoring, vulnerability information and configuration assessment.
For example, once Syscollector has populated the inventory, you can start seeing things such as operating-system details, installed software, running processes, network interfaces, open ports, users and groups.
Suddenly a question like:
“Which computers still have that old vulnerable version installed?”
doesn't necessarily require walking around the office with a spreadsheet.
That is progress.
Vulnerability detection: finding the software everyone forgot about
Every organisation eventually develops an archaeological layer of software.
There is the application everyone uses.
There is the application three people still use.
There is the application nobody thinks they use.
And then there is SomeVendorRuntime 4.2.1, installed in 2019 for reasons nobody can explain, quietly waiting for a vulnerability scanner to notice it.
Wazuh's vulnerability detection uses software inventory collected from monitored systems and compares it with vulnerability information.
That gives you a central place where you can see vulnerable packages and applications across multiple computers.
It isn't magic and it doesn't replace a proper patch-management programme, but it changes the question from:
“I wonder if any of our machines have this.”
to:
“These four machines have this.”
Those are very different levels of visibility.
File Integrity Monitoring
File Integrity Monitoring, usually shortened to FIM, sounds boring until the day you need it.
Its job is simple: watch important files and tell you when they are created, modified or deleted.
For example, on a Linux web server you might care about:
/etc
/var/www
/usr/local/bin
On Windows, perhaps an important application's configuration folder:
<syscheck>
<directories realtime="yes">C:\ImportantApplication\Config</directories>
</syscheck>
The temptation at this point is to become very secure and monitor everything.
Do not do that.
Monitoring the entire filesystem in real time is the security equivalent of installing a CCTV camera inside every desk drawer.
Technically you are collecting more information.
Practically you have created a huge amount of noise and probably made the system slower.
Monitor files whose unexpected modification would actually matter.
That is the difference between monitoring and hoarding.
Authentication events: where the useful stuff starts
Authentication data is one of the first things I would pay attention to in a small deployment.
You want to know about repeated failed Windows logins.
You want to know when someone successfully logs in with an administrative account.
You want SSH authentication failures.
You want to know when a new account appears or when someone gets added to an administrator group.
Without central monitoring, all of this information exists already, but it exists separately on twenty machines that nobody is checking.
And logs nobody reads are really just very detailed digital diaries.
Wazuh turns those separate events into something you can search and correlate from one interface.
For a small environment, that alone can justify building the system.
Add Linux servers too
Linux servers fit naturally into the same platform.
Install the agent, connect it to the manager and suddenly SSH authentication, sudo activity, package information, services, file changes and system security events become part of the same dataset as your Windows machines.
That matters because attacks are rarely polite enough to remain inside a single operating system.
A compromised Windows workstation may be used to probe a Linux server.
A Linux web server may start making strange outbound connections.
An administrator account may suddenly behave differently across several machines.
When those systems all report to the same place, patterns become easier to see.
And security is very often about patterns.
What about routers, switches and firewalls?
You obviously aren't going to install a Wazuh agent on your switch.
Please don't try.
Network devices normally send their events using Syslog, and Wazuh can receive Syslog data from devices that cannot run an agent. Its architecture explicitly supports receiving information from devices such as routers, switches, firewalls and access points.
A basic Wazuh Syslog listener might look like:
<remote>
<connection>syslog</connection>
<port>514</port>
<protocol>udp</protocol>
<allowed-ips>192.168.10.0/24</allowed-ips>
</remote>
Then restart the manager:
sudo systemctl restart wazuh-manager
Now your firewall, MikroTik router, managed switch or other appliance can forward relevant logs into the same system.
But be careful here.
A workstation is normally fairly quiet.
A firewall can have opinions about absolutely everything.
Wazuh's own sizing estimates assume approximately 0.1 alerts per second for a workstation, 0.25 for a server and 0.5 for a network device. That makes a chatty network device significantly more expensive, from a logging perspective, than a normal PC.
So don't think purely in terms of device count.
Twenty Windows laptops and one firewall can be easier to handle than ten servers, four firewalls and several devices configured to log every packet that has ever experienced an emotion.
How many devices would I actually put on it?
The official number we are using is up to 25 Wazuh agents, because that is the sizing tier that matches the Pi's four CPU cores most closely.
But if this were my installation, I would not treat 25 as a personal challenge.
A configuration such as this would make me perfectly comfortable:
15–20 Windows workstations
2–3 servers
1–2 Linux systems
1 firewall/router
possibly a managed switch
Another perfectly reasonable scenario would be 20–25 normal office endpoints with relatively modest event volumes.
Remember: we're not trying to obtain a high score.
There is no leaderboard.
Nobody from Raspberry Pi is going to visit your office and present a trophy because you connected 47 agents to a computer designed partly for education.
What matters is that the platform has enough spare capacity to process events when something unusual happens.
Keep the logs useful
There is an ancient SIEM tradition that says if collecting some logs is good, collecting every log ever created must be better.
This is how you end up indexing ten million events explaining that a printer successfully checked its toner level.
More data is not automatically more security.
The important question is whether the data helps you answer security questions.
For a small environment, I would concentrate heavily on authentication, privilege changes, new account creation, endpoint protection alerts, important application events, vulnerable software, significant file modifications and useful firewall events.
Debug logs should only be enabled when they solve a specific problem.
The Raspberry Pi has limited CPU resources, but even on much larger systems, reducing useless event noise makes investigations dramatically easier.
Your future self will appreciate not having to search through 600,000 successful DHCP renewals while investigating a compromised administrator account.
Protect the machine that watches everything
There is a certain irony in building a security monitoring server and then leaving its dashboard exposed directly to the Internet.
Don't do that.
The Raspberry Pi now contains information about your computers, usernames, vulnerabilities, installed software, security alerts and network events.
In other words, it becomes one of the more interesting systems on your network.
Treat it accordingly.
Ideally, place the SOC server in a management or server VLAN and only allow administrative access from trusted networks.
If remote access is required, use a VPN.
Use SSH keys.
Restrict SSH.
Don't expose Wazuh administration directly to the Internet just because port forwarding only took eleven seconds to configure.
A simple design might look like this:
Internet
│
┌─────┴─────┐
│ Firewall │
└─────┬─────┘
│
┌──────────────┴──────────────┐
│ │
User VLAN Management VLAN
│ │
PCs / Laptops SOC01
│ Raspberry Pi 5
│ │
└───── security events ───────┘
The machine watching the network shouldn't be the easiest machine on the network to compromise.
That would be embarrassing.
Back it up
There is one additional point that deserves more attention than it usually receives.
Back up the SOC configuration.
You don't necessarily need to retain every historical alert forever, especially in a small installation, but you absolutely want to preserve the configuration, custom rules, certificates and anything else required to rebuild the system.
A Raspberry Pi with an NVMe SSD is reasonably reliable.
“Reasonably reliable” and “backup” are not competing technologies.
The whole point of infrastructure design is accepting that hardware will eventually fail and making sure that this discovery is inconvenient rather than catastrophic.
Monitor the monitor
This part is important.
How do you know whether the Raspberry Pi is actually keeping up?
Looking at the dashboard and thinking “seems fast enough” is not monitoring.
Wazuh maintains internal statistics that can tell you whether the server has started dropping or discarding events.
Two particularly interesting counters are:
events_dropped
discarded_count
Relevant state files include:
/var/ossec/var/run/wazuh-analysisd.state
/var/ossec/var/run/wazuh-remoted.state
Check them:
sudo cat /var/ossec/var/run/wazuh-analysisd.state
and:
sudo cat /var/ossec/var/run/wazuh-remoted.state
You should also watch the usual system metrics.
For CPU and processes:
htop
For memory:
free -h
For filesystem usage:
df -h
For I/O behaviour, install and use iostat:
iostat -xz 5
And because this is still a Raspberry Pi sitting there doing database work all day, keep an eye on temperature too:
cat /sys/class/thermal/thermal_zone0/temp
Divide the result by 1000 to get degrees Celsius.
If events_dropped starts increasing, don't simply add another fan and hope for personal growth.
Reduce unnecessary event volume, reduce the endpoint count, tune the configuration or move the central components onto stronger hardware.
Security monitoring that silently drops events is not security monitoring.
It is decorative logging.
What can this Mini SOC realistically tell you?
After everything is connected, you now have something that is significantly more useful than a collection of individual endpoint logs.
Imagine somebody starts trying passwords against several Windows computers.
Instead of the evidence being hidden in separate Windows Security logs, the events arrive centrally.
Someone creates a new local administrator.
You can see it.
A configuration file on your web server unexpectedly changes.
You can see it.
Several computers contain a vulnerable software version you didn't know was still installed.
You can see that too.
A Linux server suddenly experiences a wave of SSH failures.
Visible.
Your firewall starts reporting unusual connections.
Also visible.
None of these detections is particularly magical on its own.
The real value is that they all appear in the same place.
Security visibility often isn't about inventing new information.
It's about finally looking at information your systems have been producing for years.
What this does not replace
At this point it is worth applying the brakes before somebody installs Wazuh on a Raspberry Pi and announces that the company's cybersecurity programme is complete.
It isn't.
This system does not replace a properly configured firewall, endpoint antivirus or EDR, MFA, backups, patch management, network segmentation, email security, incident-response procedures or people who actually investigate alerts.
It certainly doesn't replace thinking.
A SOC is not a piece of software.
A real SOC consists of technology, processes and people.
What we are building here is primarily the visibility and detection layer.
And for a small organisation, that layer may have been almost completely missing before.
That is why this inexpensive project can still have significant value.
The problem it actually solves
Small businesses often own more security technology than they realise.
They may already have Microsoft Defender on every laptop.
They probably have a firewall.
They may have a VPN.
They probably perform backups.
Their operating systems already generate detailed security logs.
Servers record authentication events.
Routers produce firewall logs.
All of those systems are talking.
Nobody is listening.
That is the gap this project tries to close.
Once twenty endpoints are reporting into Wazuh, you can suddenly ask useful questions from one place.
Which machines contain critical vulnerabilities?
Where did administrator logins happen today?
Was a new account created?
Which systems have modified important files?
Which machines still contain an obsolete software package?
What happened on the server immediately before the incident?
Those are simple questions.
Without centralized monitoring, answering them can involve logging into machines individually, opening Event Viewer, searching text logs, running PowerShell commands, checking firewall logs and slowly reconsidering every career decision that brought you to this moment.
With centralized monitoring, the data is already together.
That is the real upgrade.
And what happens when the company grows?
This is another reason I like this architecture.
Nothing says that the Raspberry Pi must remain the Wazuh server forever.
Imagine the organisation grows like this:
10 endpoints
│
▼
20 endpoints
│
▼
25 endpoints
│
▼
40 endpoints
│
▼
80 endpoints
At some point, the Raspberry Pi has completed its mission.
You move the central Wazuh components onto a proper VM, mini PC, dedicated server or distributed Wazuh deployment.
The agents remain conceptually the same.
Your Raspberry Pi wasn't a failed experiment just because the company eventually outgrew it.
Quite the opposite.
It provided inexpensive centralised monitoring at the exact stage where buying a large SIEM platform probably wouldn't have made financial sense.
Infrastructure doesn't have to last forever to be useful.
The finished Mini SOC
At the end of the project, our environment looks roughly like this:
┌─────────────────────┐
│ Windows Workstations│
│ Linux Servers │
│ macOS Clients │
└──────────┬──────────┘
│
Wazuh Agents
│
▼
┌──────────────────────────┐
│ Raspberry Pi 5 │
│ │
│ Cortex-A76, 4 cores │
│ 16 GB RAM │
│ 500 GB / 1 TB NVMe │
│ │
│ Wazuh Server │
│ Wazuh Indexer │
│ Wazuh Dashboard │
└────────────┬─────────────┘
│
▼
Security Dashboard
Target environment:
10–25 endpoints
And that endpoint limit is intentional.
It is not the absolute point at which the Raspberry Pi explodes.
There is no hidden fuse that activates when agent number 26 connects.
It is simply a sensible design target based on Wazuh's published sizing guidance, the Raspberry Pi's four CPU cores and our desire to retain enough performance headroom for real incidents.
Because there is one thing worse than having no monitoring.
Having monitoring that works beautifully until something actually happens.
Final thoughts
Is a Raspberry Pi 5 a replacement for an enterprise SOC platform?
Obviously not.
But that is the wrong comparison.
For many small businesses, home labs and branch offices the real choice isn't:
Raspberry Pi
vs.
€100,000 enterprise SIEM
The actual choice is:
Raspberry Pi + Wazuh
vs.
Nobody looking at anything
And that makes the Raspberry Pi considerably more interesting.
With a Pi 5, 16 GB of RAM, an NVMe SSD and Wazuh, you can centralize security events from Windows, Linux and macOS endpoints, monitor important files, discover vulnerable software, investigate authentication activity and collect useful logs from network equipment.
All on a device small enough that somebody will eventually ask whether it is “that little computer thing”.
Start with five agents.
Then ten.
Watch CPU, RAM and disk I/O.
Check whether events are being dropped.
Tune the noisy sources.
Then add more endpoints until the environment reaches whatever sensible limit your workload allows, but treat 25 endpoints as the upper design target for this build rather than a challenge that must be defeated.
And if the organisation eventually outgrows the Raspberry Pi, move Wazuh onto larger hardware.
That's not failure.
That's capacity planning actually working.
The goal was never to prove that a Raspberry Pi can impersonate a datacenter.
The goal was much simpler:
to notice security problems that previously happened in complete silence.
Primary references
- Wazuh Quickstart
- Wazuh 4.12.0 release notes: ARM central-component support
- Wazuh architecture
- Wazuh agent installation guide
- Raspberry Pi 5 product brief
Editorial status: First edition. Platform requirements and sizing guidance were reviewed against the cited primary documentation on 23 September 2026.