On-Premise vs Cloud SCADA: Air-Gapped, Edge and Raspberry Pi Deployments
Every vendor pitch now leads with "cloud-native," "SaaS," and "AI-powered insights." For office software, that works. For industrial SCADA, it ignores the reality of the factory floor. Cloud SCADA assumes the internet is reliable, cheap, and safe. Inside a plant, none of those assumptions hold.
This post compares on-premise vs cloud SCADA through the lens of real industrial constraints, and explains why air-gapped SCADA, offline SCADA and local deployment on a mini PC or Raspberry Pi are risk management, not legacy choices.
The Assumptions Cloud SCADA Makes
Cloud SCADA platforms are built on three assumptions:
- Always-on internet: Your plant has redundant fiber, 4G backup, and zero downtime.
- Low latency tolerance: A 200 ms round-trip to the cloud is acceptable for alarms and control.
- Data ownership flexibility: You are comfortable with your production data living on someone else's infrastructure.
For a tech startup in Singapore, those assumptions are fine. For a palm oil mill in rural Sumatra, a steel plant in Eastern Europe, or a water treatment facility in the Australian outback, they are fantasy. Even when connectivity is available, security matters. See how SSO with Active Directory provides enterprise-grade authentication for on-premise deployments.
Real Concerns on the Factory Floor
1. Internet Reliability
Industrial sites do not have datacenter-grade connectivity. They have:
- Shared rural fiber that goes down for hours during storms
- 4G modems with 500 MB daily caps and 2-second latency spikes
- Strict IT policies that block outbound connections entirely
- Satellite links that cost $10/GB and drop packets every afternoon
When the internet drops, cloud SCADA goes blind. Your operator sees a blank dashboard. Your historian stops recording. Your alerts stop firing. An on-premise system keeps running because it never needed the internet to begin with.
2. Data Sovereignty
More countries are passing data localization laws. Indonesia, China, Russia, and the EU all have regulations requiring certain data to stay within national borders. Even where laws are vague, clients often have internal policies: production data does not leave the premises.
Cloud SCADA forces you to negotiate where data is stored, how it is encrypted in transit, and whether the vendor can comply with audits. An air-gapped deployment sidesteps all of it. The data never leaves. Compliance is trivial.
3. Latency
Cloud dashboards update every 1-5 seconds. That is fine for trending. It is not fine for:
- Emergency shutdown triggers
- High-speed line synchronization
- Real-time operator control where 200 ms feels sluggish
A local SCADA deployment polls devices at 100-500 ms and pushes updates to the browser via SSE in sub-100 ms. The round-trip never leaves the LAN. Latency is measured in microseconds, not milliseconds.
4. Security
Cloud vendors will tell you their security team is larger than yours. That is true. What they do not emphasize is that connecting your OT network to the internet creates an attack surface that did not exist before.
Air-gapped SCADA has no inbound ports from the public internet. No VPN concentrator to patch. No OAuth token to leak. No third-party API key to rotate. The attack surface is the physical plant, and that is already guarded.
On-Premise vs Cloud: The Comparison
Debunking the "Cloud Is Cheaper" Myth
Cloud SCADA pricing looks attractive at first: $99/month for 100 tags, no hardware to buy. But the real cost accumulates in ways vendors do not advertise:
- Bandwidth: A single Modbus device polling 50 registers at 1 Hz generates ~4 KB/s of payload. Add protocol overhead, heartbeat pings, and dashboard SSE streams. A plant with 20 devices pushes 2-4 GB/month upstream. On rural or metered links, that is $50-200/month in data charges alone.
- Egress fees: Cloud providers charge for data leaving their platform. Viewing a month of historian data in a dashboard can pull 500 MB in a single session. Do that weekly and you are paying egress on top of subscription fees.
- Redundancy: Cloud vendors sell "edge gateways" to buffer data during outages. That is extra hardware, extra licensing, and extra complexity (the very thing cloud was supposed to eliminate).
- API limits: Exceed your tier's API call limit and you are either throttled or upgraded to a $500/month plan. There is no negotiating with a SaaS meter.
Why a $4 VPS On-Premise Beats Cloud SaaS
You do not need a server room. You do not need a rack. You need a cheap mini PC or a small VM on existing plant infrastructure:
- Hardware: A $80 Mini PC (Intel N100, 4 GB RAM, 64 GB eMMC) or a refurbished thin client. No moving parts. Passive cooling. Mounts on DIN rail.
- Power: 6-10W idle. Less than a light bulb. Runs off a small UPS for hours.
- Software: A single binary like Voltrus runs on Linux, Windows, or embedded ARM. SQLite is embedded: no database server to maintain.
- Connectivity: Ethernet to the OT switch. No internet required. Operators access it via the plant LAN at
http://192.168.1.50:3000. - Backup: Copy the SQLite file to a USB stick once a week. That is your disaster recovery.
The total hardware cost is under $100. The software license is $249 one-time. The annual operating cost is essentially zero. And it works when the internet does not. For ensuring your on-premise system stays online even during hardware failures, see our guide to SCADA redundancy and high availability.
Edge Deployment: SCADA on a Raspberry Pi
The smallest on-premise server is a single-board computer inside the plant cabinet. A Raspberry Pi 4 with 4 GB RAM can poll 50 to 100 Modbus TCP sensors every second without straining the CPU, because Modbus polling is I/O bound. A local Modbus TCP round trip takes a few milliseconds, against 50 to 200+ ms to a cloud endpoint, and the dashboard and alarms keep working when the uplink is down. Treat the figures here as planning numbers and verify them on your own hardware and register map.
What the software has to be
The limiting factor is the software, not the Pi. Check before you commit:
- Footprint. Platforms that need 1 to 4 GB of RAM just to start (JVM, SQL Server, .NET stacks) rule out most Pis. Aim for a process that stays under roughly 50 MB at full load.
- ARM builds. Native ARM64 for the Pi 4 and 5, and ARMv7 if you have Pi 3 or older 32-bit industrial gateways. Many commercial packages are x86-only.
- Single binary. Deployment should be copying one file and restarting a systemd service, not an installer, container runtime, or build step on the device.
- Native protocols. Modbus TCP, Modbus RTU, MQTT and OPC-UA built in. A separate translator process is one more failure point and latency source.
- Local storage that survives reboots (embedded SQLite or a time-series file), with optional sync upstream when connectivity returns.
- Browser dashboard. The Pi sits in a cabinet with no monitor; the UI is served over the plant LAN.
A practical test: can you deploy on a fresh Raspberry Pi OS Lite install from a USB drive, offline, in under ten minutes? If not, it is data-center software that happens to run on ARM.
A typical build
- Hardware: Raspberry Pi 4 (4 GB), a DIN rail case, an RS485 HAT or USB-to-RS485 adapter for Modbus RTU, a 24V DIN rail supply with a step-down to USB-C, and a USB SSD or an A2-rated 16 GB microSD. About $80 to $150 total.
- Software: flash Raspberry Pi OS Lite 64-bit, enable SSH, set a static IP on the industrial VLAN, copy the binary, write a YAML config with the Modbus devices, polling intervals and alarm thresholds, and add a systemd unit so it starts on boot and restarts on a crash.
- Remote access: have the Pi open an outbound WireGuard tunnel to your office or a VPS, so no inbound port is opened on the plant firewall.
Where edge runs out
- Scale. Plan for roughly 100 to 200 Modbus TCP sensors per Pi at 1-second polling; less over slow Modbus RTU baud rates. Thousands of tags need a real server.
- SD card wear. Cards corrupt on power loss. Use a USB SSD, run a read-only root filesystem with overlayfs and batch writes, and add a UPS HAT for clean shutdowns.
- Heat. The Pi 4 throttles around 80 degrees Celsius. A sealed cabinet in direct sun or a boiler room at 50 degrees ambient needs a heatsink, ventilation or a fan, and a load test before handover.
- Single point of failure. No redundant power or hot failover. For critical sites keep a cold standby Pi with identical config in the same cabinet; recovery is the time it takes to swap an Ethernet cable.
When Cloud SCADA Actually Makes Sense
Fairness demands balance. Cloud SCADA is the right choice when:
- You have dozens of geographically distributed sites and need a single pane of glass
- Your IT team is nonexistent and you want someone else to handle patching
- You need mobile access for executives who never visit the plant
- Your sites have enterprise-grade fiber with SLA-backed uptime
Even then, the smart architecture is a hybrid: local SCADA for real-time control and alarms, cloud for aggregated reporting and executive dashboards. The local layer keeps running when the uplink fails. The cloud layer gets summarized data, not raw register dumps.
What System Integrators Should Tell Their Clients
Clients ask for "cloud" because they hear it in vendor webinars. Your job is to translate marketing into operational reality:
- "Cloud means your dashboard stops working when the fiber is cut. How often does that happen here?"
- "Cloud means your production data is in a datacenter you do not control. Is that compliant with your internal policy?"
- "Cloud costs $200/month forever. On-premise costs $600 once. Which fits your CapEx vs OpEx preference?"
- "Cloud needs internet. On-premise needs a $80 PC and a cable. Which is easier to replace in an emergency?"
Most plant managers, once they understand the trade-offs, choose local. They have already experienced internet outages. They already know the cost of downtime. They just need someone to present the option clearly.
Built for Air-Gapped Plants
Voltrus is a single-binary SCADA that runs offline on a $4 VPS or a cheap Mini PC. No cloud required. No subscription. Just local monitoring that works when the internet does not.
See How Voltrus Works