Running SCADA on a Raspberry Pi: Why Edge Computing Wins for Industrial Monitoring
Ten years ago, if you told a plant manager their SCADA server could be a $35 single-board computer sitting inside a DIN rail enclosure, they would have laughed you out of the room. Today, that is not just possible. It is often the smartest architecture choice you can make.
The shift happened quietly. Cloud vendors pushed hard for centralized monitoring. IoT platforms promised dashboards for everything. But the plants kept having the same problem: when the internet goes down, the monitoring goes blind. And in industrial environments, internet outages are not rare events. They are Tuesday.
Edge computing changed the equation. Instead of sending every sensor reading to a cloud endpoint hundreds of milliseconds away, you process data where it is generated. The SCADA architecture shifts from centralized to distributed, with the software running on a device inside the plant cabinet. The dashboard loads from the local network. Alarms trigger in milliseconds, not seconds.
And the device running all of this? Increasingly, it is a Raspberry Pi, a BeagleBone, or an ARM-based industrial gateway. Not because these devices are powerful. Because they are powerful enough, and the software has finally caught up.
Why Edge SCADA Matters
The case for edge computing in industrial monitoring is not ideological. It is practical. Here are the four reasons system integrators choose edge over cloud:
Latency
A Modbus TCP round trip to a local device takes under 5 milliseconds. A round trip to a cloud API endpoint takes 50-200+ milliseconds depending on the region, the provider, and whether the VPN tunnel is behaving. For alarm handling and safety interlocks, that difference is not academic. A 200ms delay in detecting an overpressure condition can mean the difference between an automatic shutdown and a manual one that comes too late.
Edge SCADA reads sensors locally, evaluates thresholds locally, and triggers outputs locally. The cloud never sees the alarm. The operator sees it instantly on the plant network.
Reliability
Industrial sites have unreliable internet. Fiber gets cut by backhoes. Cellular modems drop connections in storms. VPN concentrators crash during firmware updates. None of this is theoretical. It happens every week across manufacturing plants, water treatment facilities, and power substations.
Edge SCADA works when the internet goes down. The local device keeps polling sensors. It keeps storing data. It keeps serving the dashboard to anyone on the plant network. When connectivity returns, it syncs the buffered data upstream. The plant never goes blind.
Cost
A Raspberry Pi 4 costs $35. An industrial-grade ARM gateway with DIN rail mounting costs $100-200. Compare that to a cloud SCADA subscription at $150-500 per month, per site. Over two years, a ten-site deployment saves $36,000-120,000 by going edge instead of cloud.
The hardware pays for itself in the first month. The software license, if it is priced right, is a one-time cost instead of a recurring drain on the project budget.
Data Sovereignty
Not every plant wants its sensor data routed through AWS servers in another country. Regulated industries face strict data residency requirements. Defense contractors, utility operators, and critical infrastructure managers often cannot legally send operational data to third-party cloud platforms.
Edge computing solves this cleanly. The data never leaves the plant. It is collected, stored, and visualized on-site. If the client wants remote access, you set up a VPN. The data flows through infrastructure they control. No third-party terms of service. No data processing agreements. No annual compliance audits.
The Comparison
Can a Raspberry Pi Actually Run SCADA?
The short answer: yes, easily, for the majority of small and medium industrial deployments. The long answer requires understanding what the hardware can and cannot do.
What the Pi Can Handle
A Raspberry Pi 4 with 4 GB RAM can poll 50-100 Modbus TCP sensors every second without breaking a sweat. The CPU barely registers the workload. Modbus polling is I/O bound, not compute bound. The Pi's 1.5 GHz ARM Cortex-A72 has more than enough headroom for protocol translation, threshold evaluation, and data logging.
The bottleneck is never the processor. It is the network interface, the storage write speed, and the software you choose to run.
RAM Efficiency Is Everything
Most SCADA software needs 1-4 GB of RAM just to start. That immediately disqualifies the Pi 2 (1 GB) and makes the Pi 4 (1 GB model) unusable. The Pi 4 with 4 GB or 8 GB can run bloated software, but you are wasting three-quarters of your RAM on frameworks, runtimes, and middleware that do nothing for sensor monitoring.
The right approach: software that uses under 50 MB of RAM at full load. That leaves the remaining 3.95 GB for data buffering, the operating system, and whatever else the site needs. A lean binary running in userspace with a built-in web server does not need a JVM. It does not need Node.js. It does not need a container runtime.
The Software Problem
Here is the real barrier to Pi-based SCADA: most SCADA software is too bloated for edge devices. The major platforms were designed for Windows servers with 8+ GB of RAM. They ship with SQL Server dependencies, .NET runtimes, and UI frameworks that assume a desktop environment. You cannot install that on a Pi running Raspberry Pi OS Lite.
Even the "lightweight" open-source options are not lightweight enough. Ignition Edge needs 2 GB minimum. ThingsBoard wants 1 GB before you add any devices. Node-RED works on a Pi but falls apart at scale — a single misconfigured flow node can consume all available memory.
ARM Compatibility
Not all SCADA software runs on ARM architecture. Many commercial packages are x86-only. Some open-source tools compile for ARM64 but not ARMv7 (the architecture of older Pi models). Before choosing any software for a Pi deployment, verify three things:
- Does it compile for ARM64 (aarch64)?
- Does it compile for ARMv7 (armhf) if you are using older Pi hardware?
- Does it run without x86-only dependencies (certain database drivers, proprietary libraries)?
If the answer to any of these is no, the software is out. No amount of emulation or workarounds is worth the reliability hit in an industrial deployment.
What to Look For in Edge SCADA Software
If you are evaluating SCADA software for Raspberry Pi or ARM gateway deployments, here is your checklist:
RAM Usage Under 50 MB
The Pi 4 has 1-8 GB depending on the model. After the OS takes its share and you account for data buffering, you want the SCADA process itself to consume as little as possible. Under 50 MB at full load is the target. Anything over 200 MB and you are running middleware, not SCADA.
ARM64 and ARMv7 Support
You need native binaries for both architectures. ARM64 for the Pi 4 and 5, ARMv7 for the Pi 3 and older industrial gateways still running 32-bit ARM chips. If the vendor only ships x86, move on.
Single Binary Deployment
No Docker. No container runtime. No Java. No Node.js. One statically compiled binary that you copy to the Pi and run. The deployment should be scp binary pi:/usr/local/bin/ followed by systemctl restart scada. If it needs an installer, a package manager, or a build step on the target device, it is not edge software. The difference between a single binary and a microservices stack becomes stark on resource-constrained hardware: one process to monitor versus five services to coordinate.
Built-In Protocol Support
The software must speak Modbus TCP, Modbus RTU, MQTT, and OPC-UA out of the box. Not through plugins. Not through third-party adapters. Natively. If you need to install a separate gateway process to translate Modbus to MQTT before the SCADA can read it, you have added a failure point and a latency source.
Local Data Storage with Sync
Edge devices must store data locally. SQLite, embedded InfluxDB, or a custom time-series format. The storage must survive reboots, handle disk-full conditions gracefully, and sync to a central server when connectivity is available. The sync should be optional, not required for the system to function.
Web-Based Dashboard
The Pi will not have a monitor attached. It will be mounted inside a cabinet. The dashboard must be accessible from a browser on the plant network. No local display needed. No X11. No VNC. Just an HTTP endpoint that serves a responsive web UI.
Real-World Edge Deployment
Here is what a production Pi-based SCADA deployment looks like from start to finish.
Hardware
- Raspberry Pi 4 (4 GB) — the workhorse. The 8 GB model is fine but overkill for most sites.
- RS485/ethernet HAT — for connecting to Modbus RTU serial buses. Alternatively, a USB-to-RS485 adapter.
- DIN rail case — industrial mounting. Brands like Pixtend, Kunbus, or generic aluminum enclosures.
- MicroSD card (16 GB A2-rated) or a USB SSD for better reliability.
- 24V DIN rail power supply — most industrial cabinets already have these. Add a USB-C cable.
Total hardware cost: $80-150 depending on your supplier and whether you use an SSD.
Software
On the Pi:
- Flash Raspberry Pi OS Lite (64-bit) to the SD card or SSD.
- Enable SSH. Configure the network interface for the plant LAN.
- Copy the SCADA binary:
scp voltrus pi@192.168.1.50:/usr/local/bin/ - Write the config file: a single YAML defining your Modbus devices, polling intervals, alarm thresholds, and dashboard layout.
- Create a systemd service unit so the binary starts on boot and restarts on crash.
The systemd unit is four lines. The config file might be 50 lines for a site with 30 sensors. The entire software deployment takes under five minutes.
Network
Connect the Pi to the plant network. Assign it a static IP on the industrial VLAN. The dashboard is now accessible at http://192.168.1.50:8080 from any computer on the plant network.
For remote access, set up a WireGuard VPN tunnel back to your office or a cloud VPS. The Pi initiates the outbound connection. No inbound ports need to be opened on the plant firewall. You access the dashboard through the VPN tunnel. The plant IT team is happy because nothing is exposed to the public internet.
From unboxed hardware to live dashboard: two hours. Including the time to label cables and close the cabinet door.
The Limits of Edge
This would not be a useful article if it only told you the upsides. Edge computing has real limitations, and you should understand them before specifying a Pi-based architecture for a client.
Not for 10,000+ Sensor Deployments
A Raspberry Pi polling 50 Modbus devices with 10 registers each is cruising. A Pi trying to poll 500 devices is straining. A Pi handling 10,000 sensors is not going to work. There is a ceiling, and it is lower than what a rack-mounted x86 server can handle.
The practical limit depends on polling frequency and protocol overhead. For Modbus TCP at 1-second intervals, plan for 100-200 sensors per Pi. For Modbus RTU at slower baud rates, the limit is lower. For MQTT-based sensors with sparse reporting, you can go higher.
SD Card Reliability
MicroSD cards are the weakest link in any Pi deployment. They wear out. They corrupt on power loss. They fail silently and then the entire filesystem goes read-only.
Mitigation strategies:
- Use a USB SSD instead of an SD card. A 120 GB NVMe drive in a USB enclosure costs $25 and is orders of magnitude more reliable.
- Enable overlayfs (read-only filesystem). Raspberry Pi OS supports booting into a read-only mode where writes go to a tmpfs. Combined with an edge SCADA that buffers data in memory and writes to storage in batches, this dramatically extends card life.
- Use a UPS HAT. A battery-backed power supply gives the Pi time to shut down cleanly on power loss.
Thermal Management
Industrial cabinets get hot. 50 degrees Celsius ambient is not unusual in a steel plant or a boiler room in Southeast Asia. The Pi 4 throttles its CPU at 80 degrees Celsius and becomes unreliable above 85 degrees.
Add a heatsink. Add a small fan if the cabinet has ventilation. Test the deployment under load before handing it over to the client. The Pi does not need active cooling in an air-conditioned control room, but inside a sealed outdoor cabinet in direct sunlight, it absolutely does.
Single Point of Failure
The Pi has no redundant power supply, no hot-swappable storage, and no clustering capability. If the Pi dies, the monitoring goes offline. There is no automatic failover to a standby unit.
For critical applications, the pragmatic solution is a cold standby: a second Pi with identical configuration, mounted in the same cabinet, ready to swap in. The data is not real-time replicated, but the recovery time is the 30 seconds it takes to move an ethernet cable.
Built for Edge. Priced for Integrators.
Voltrus runs on ARM64 and ARMv7. It ships as a single binary with no runtime dependencies. Copy it to a Raspberry Pi, write a config file, and start monitoring in minutes. No Docker. No JVM. No cloud subscription.
Starting at $249 lifetime per deployment. Runs on any Linux, including Raspberry Pi OS.
Try Voltrus on a PiFrequently Asked Questions
Can a Raspberry Pi run SCADA software reliably?
Yes, for the majority of small and medium industrial deployments. A Raspberry Pi 4 with 4 GB RAM can poll 50-100 Modbus TCP sensors every second without straining the CPU. The key is using SCADA software with a RAM footprint under 50 MB. Most traditional SCADA platforms require 1-4 GB of RAM just to start, which disqualifies them from Pi deployment. Voltrus runs as a single binary under 20 MB with no JVM or container runtime.
How many sensors can a Raspberry Pi SCADA monitor?
The practical limit for a Raspberry Pi 4 is 100-200 sensors for Modbus TCP at 1-second polling intervals. For Modbus RTU at slower baud rates, the limit is lower. For MQTT-based sensors with sparse reporting, you can go higher. The bottleneck is never the processor; it is the network interface, storage write speed, and the efficiency of the software you choose to run.
What are the reliability concerns with Raspberry Pi in industrial environments?
The main concerns are SD card wearout, thermal throttling, and the lack of redundant hardware. SD cards can corrupt on power loss. The Pi 4 throttles its CPU at 80 degrees Celsius. Mitigation strategies include using a USB SSD instead of an SD card, enabling read-only filesystem mode, adding heatsinks or fans for hot environments, and keeping a cold standby Pi with identical configuration ready to swap in.
Does edge SCADA work without internet access?
Yes, that is one of the primary advantages. Edge SCADA polls sensors locally, evaluates thresholds locally, and triggers outputs locally. The dashboard is served on the plant network with zero cloud dependency. When internet connectivity returns, data can sync upstream. This is critical for industrial sites where internet outages are common due to fiber cuts, modem failures, or VPN issues.