Open-source SCADA is real, usable, and — for the right situation — the correct engineering decision. But the license fee is the only cost that goes to zero; everything else — hosting, drivers, HMI screens, security patching, redundancy, the 2 a.m. call when alarms stop delivering — transfers to you. This guide compares the real open-source options on their merits, adds up what self-hosting actually costs, and lays out honestly where open source wins and where a managed platform is the cheaper system over five years.
Open-source SCADA is supervisory control and data acquisition software whose source code is published under a free license, so you can download it, modify it, and run it without paying anyone. The main options worth evaluating in 2026 are ScadaBR, Rapid SCADA, and FUXA, plus ThingsBoard on the IoT-adjacent side of the same problem.
Two clarifications save a lot of confusion. First, "open source" and "free" describe the license, not the system — a working deployment also needs servers, protocol integration, HMI screens, alarm routing, a historian, backups, and someone on the hook when it breaks. Second, some platforms people assume are open source are not: Ignition, for example, is commercial closed-source software with published pricing. If you are still mapping the overall vendor landscape, start with our top 10 SCADA platforms comparison and come back here for the open-source branch of the decision tree.
Four projects come up in nearly every open-source SCADA evaluation, and they are genuinely different tools with different sweet spots. Here is the honest side-by-side, followed by what each one is actually like to live with:
| Project | Technology | Typical Protocols | Genuine Strengths | Honest Limitations |
|---|---|---|---|---|
| Rapid SCADA | .NET, modular server/communicator/web | Modbus TCP/RTU, OPC UA, MQTT | Actively maintained, solid docs, permissive license, true classical SCADA architecture | HMI building is manual, smaller driver library, redundancy is DIY, forum-based support |
| ScadaBR | Java web application | Modbus, DNP3, OPC DA | Long-established, simple for basic telemetry, strong Latin American community | Aging codebase and UI, slow release cadence, much documentation in Portuguese |
| FUXA | Node.js + Angular web HMI | Modbus TCP/RTU, Siemens S7, OPC UA, BACnet, MQTT, EtherNet/IP | Modern SVG HMI editor, quick to stand up in Docker, active development | Young project, small maintainer base, basic alarming/historian, hardening is on you |
| ThingsBoard CE | Java IoT platform | MQTT, HTTP, CoAP (industrial protocols via separate gateway) | Excellent device telemetry, dashboards, rule engine, multi-tenant design | IoT platform, not operator SCADA; industrial polling needs the gateway; key features reserved for the paid edition |
Rapid SCADA is the closest thing the open-source world has to a classical, production-oriented SCADA package that is still actively developed. Its modular architecture — server, communicator for field protocols, web station for operators — mirrors commercial designs, its documentation is genuinely good, and Modbus, OPC UA, and MQTT cover a large share of real field equipment. The costs show up in the labor: building operator screens is slower than in commercial HMI editors, drivers beyond the core set may mean writing your own, and redundancy, backups, and hardening are entirely your project.
ScadaBR has been around long enough to have monitored a generation of small plants, and for straightforward Modbus or DNP3 telemetry with basic alarming it still works. It also shows the risk profile of community software most clearly: the codebase and interface are dated, releases are infrequent, and much of the strongest community documentation is in Portuguese. It can serve a simple telemetry need — just do not expect the project to evolve underneath you.
FUXA is the most pleasant surprise in the category: a modern, web-native HMI/SCADA tool with a genuinely good SVG graphics editor and an impressive connector list — Modbus, Siemens S7, OPC UA, BACnet, MQTT, EtherNet/IP. You can have a demo running in Docker within an hour, which makes it outstanding for prototypes and lab rigs. The caution is maturity: it is a young project with a small maintainer base, its alarming and historian layers are basic, and everything from TLS to hardening to upgrade testing lands on your desk.
ThingsBoard deserves its reputation — as an IoT platform. Its Community Edition handles MQTT device telemetry, dashboards, and rule-based processing very well, and it scales to large device fleets. But it is not operator-facing SCADA: polling industrial protocols like Modbus or OPC UA requires its separate gateway component, control-room concepts like alarm escalation and operator displays are things you build rather than install, and several capabilities are reserved for the paid Professional Edition. If your problem is genuinely IoT-shaped, it is a strong choice; our guide to IIoT vs SCADA covers how to tell which problem you have.
The license is $0; a production deployment is not. The realistic total cost is dominated by engineering hours — typically weeks to months of setup effort in year one, plus a steady monthly tax of patching, backups, and upgrades for as long as the system runs.
Line items that surprise people, in the order they usually surface:
None of this means open source is a bad deal. It means the deal is labor for license, and it only makes sense if the labor is genuinely available. Our SCADA total cost of ownership comparison works the five-year math, and the licensing models guide places open source among perpetual, subscription, and SaaS options.
Open source wins cleanly in several situations, and pretending otherwise would insult your intelligence:
The common thread: in every winning case, either the downside of failure is small, or the team maintaining the system is exceptional and funded to do so.
A managed platform wins the moment a missed alarm or a dead server has a measurable cost and nobody on staff is funded to own the software stack. The question stops being "why pay for what is free?" and becomes "who carries the operational risk?" — and a contract that puts it on the vendor is usually cheaper than carrying it yourself. Concretely, here is what the managed model buys, using Merobix as the example we can speak to precisely:
Over a five-year horizon, the comparison is labor and risk against subscription. Neither side wins universally — the crossover depends on how critical the asset is and whose time you are spending:
| Cost Category | Open-Source, Self-Hosted | Managed Platform (Merobix) |
|---|---|---|
| Software license | $0 | Included in flat, custom-quoted plan |
| Servers & infrastructure | You buy, size, and replace it | Included (cloud) or your existing VMs (on-prem) |
| Initial engineering | Weeks to months of internal or contracted labor | Typically live in 3–5 days (cloud) |
| Protocol drivers | Community drivers; edge cases are your problem | 20 maintained drivers across 7 families |
| Alarm delivery | DIY gateway integration + subscription | <30s SMS/email, platform-maintained |
| Security patching | Your team, indefinitely | Vendor-managed (cloud); vendor-supported (on-prem) |
| Redundancy | Duplicate everything, test it yourself | 99.9% SLA (cloud); hot standby included in Enterprise (on-prem) |
| Support & on-call | Forums and whoever built it | Vendor support under contract |
| Five-year risk profile | Key-person risk, patch debt, untested failover | Contractual SLA with remedies |
The one-question test: If your SCADA server died at 2 a.m. on a Saturday, who fixes it, how fast, and what did the outage cost? If the honest answer is "an engineer we already pay, eventually, and not much" — open source is a rational choice, and we would tell you so. If the answer involves lost production or "I do not actually know," run the numbers with the ROI calculator before you build.
One more honest note: commercial self-hosted platforms like Ignition occupy the middle ground — paid license, your infrastructure — and we compare that model in our Merobix vs Ignition head-to-head. Whatever you choose, price the labor honestly, because with open source the labor is the price.
Yes. Rapid SCADA, ScadaBR, and FUXA are all genuinely free, open-source SCADA packages you can download and run in production today, and ThingsBoard Community Edition covers the IoT-telemetry side of the same problem. Free refers to the license, not the project: you still pay in engineering hours for hosting, driver integration, HMI building, security patching, backups, and on-call support. For a lab, a pilot, or a non-critical asset watched by a capable in-house team, that trade is often worth it. For revenue-producing equipment where a missed alarm has a real cost, the total cost of ownership usually favors a managed platform with a contractual SLA.
Rapid SCADA is the strongest all-around choice for a classical open-source SCADA deployment in 2026 — it is actively maintained, well documented, modular, and speaks Modbus, OPC UA, and MQTT. FUXA is the best pick when a modern web-based HMI matters most, with a genuinely pleasant SVG graphics editor and connectors for Modbus, Siemens S7, OPC UA, BACnet, and MQTT. ScadaBR remains viable for simple Modbus and DNP3 telemetry, though its codebase and interface show their age. ThingsBoard is the right tool when the problem is device telemetry and dashboards rather than operator-facing SCADA. There is no single best — match the tool to the job and to the team that will maintain it.
It can be, but only if someone owns the security work — and that someone is you. Open code is auditable, which is a genuine advantage, but with no vendor there is no one shipping you coordinated patches, hardening guides, or CVE notifications on a contract. You are responsible for patching the application, its runtime (Java, .NET, or Node.js), the operating system, and every dependency, plus TLS certificates, authentication, network segmentation, and backups. Organizations with real OT-security staff do run open-source SCADA safely. Organizations without them tend to end up with an unpatched, internet-reachable server — which is worse than either alternative.
The license costs nothing; the system does not. A realistic first-year budget for a production-grade open-source deployment includes server or VM hosting, several weeks to several months of engineering time for driver setup, HMI screens, alarm routing, and historian configuration, plus ongoing hours every month for patching, backups, and upgrades. Add an SMS gateway subscription if you need text-message alarms, and duplicate infrastructure if you need redundancy. For a small non-critical system built by an engineer who enjoys the work, the total can stay modest. For anything an operations team depends on around the clock, the labor typically becomes the largest line item — larger than the license fee it replaced.
Choose managed when downtime or a missed alarm has a measurable cost and nobody on staff is funded to own the software stack. A managed platform gives you a contractual uptime SLA, alarm delivery measured in seconds, maintained protocol drivers, and a vendor who does the patching — Merobix, for example, backs its cloud plans with a 99.9% uptime SLA, delivers SMS and email alarms in under 30 seconds, and typically has cloud deployments live in 3 to 5 days. Choose open source when the asset is non-critical, the budget is zero, or you have a strong in-house software team that wants full control of the stack. If you need on-premise control for air-gap or data-residency reasons, note that open source is not the only path: managed platforms including Merobix also deploy on your own servers.
99.9% uptime SLA, <30s alarms, 20 maintained protocol drivers — cloud or on your own servers, on flat custom-quoted plans.