27 Jul 2026 · 9 min read
Your SCADA server doesn't need Windows anymore
scada · linux · docker · kubernetes · architecture · ignition · n3uron
There's a computer in your plant that everyone is afraid of. It runs the SCADA server. It's a Windows box that was set up years ago by someone who may not work there anymore, it has a yellow sticky note involved somewhere, and the official policy is: don't touch it, don't patch it, don't reboot it unless you absolutely must. Everyone calls it critical infrastructure. Everyone treats it like a haunted house.
This piece is about the case for putting the always-on half of your plant software — the gateways, the historians, the data layers — on Linux instead, and why now is the moment that argument got easy to make. Not because Linux is fashionable, but because the numbers changed, the vendors changed, and the day-to-day work of keeping a SCADA server alive changed. I run this stack in my own lab — Ignition on Kubernetes, a TimescaleDB historian, and an N3uron edge-to-central system — so the numbers in here are either measured on my own rack or linked to their source.
One note before we start: I've written before about Ignition as the "Linux of automation" — that was a metaphor about business models. This piece is about actual Linux, the operating system, on the actual server.
How we got here: SCADA grew up on Windows
No conspiracy — just history. When the current generation of SCADA products was born, around the turn of the century, Windows was where the engineering tools lived, DCOM was how OPC moved data, and every panel builder knew their way around a Windows PC. The vendors built for Windows because that's where the customers were, and the customers stayed on Windows because that's what the vendors supported. Twenty years of that loop gives you today's plant floor.
And today's plant floor shows its age. In a 2026 survey of European industrial operators, six in ten said legacy Windows builds make up at least half of their OT environment — and 43% had a security incident on those legacy systems in the past year. Meanwhile Windows 10 reached end of support in October 2025, which means a very large share of the world's HMI and SCADA PCs just stopped getting security patches — and a chunk of that hardware can't run Windows 11 at all. Every plant running Windows 10 boxes is being forced to decide something right now anyway. That's exactly the moment to ask whether the replacement should be another Windows box.
The cost of the old loop isn't theoretical. In 2017, WannaCry — a worm that spread through a Windows file-sharing hole — halted production at five Renault plants and shut Honda's Sayama factory. A month later NotPetya went through Merck's Windows estate and cost them around $870 million, crippling vaccine production badly enough that they borrowed 1.8 million doses from the U.S. emergency supply. None of those plants were attacked because they ran Windows — but the worm only had a path because the plant floor shared one operating system, one set of holes, with every office PC on earth.
What actually changed
Three things, roughly in order.
The software world picked a side. The always-on half of computing quietly standardized on Linux. Even on Microsoft's own cloud, more than 60% of the compute cores customers run are Linux — Microsoft's number, about Microsoft's platform. Every container, most databases, effectively every web service: Linux. The tooling, the hiring pool, and the documentation followed.
The SCADA vendors followed. Ignition has treated Linux as a first-class platform for years — the same gateway, same features, no asterisks — and its official Docker image has over a million pulls plus an official Helm chart for Kubernetes. N3uron ships as a Linux container you can start in seconds — my whole edge-to-central lab ran that way. The historians (TimescaleDB, InfluxDB), the dashboards (Grafana), the MQTT brokers — Linux-native, all of them. And it's reached the control layer itself: Bosch Rexroth's ctrlX OS is an industrial Linux running a CODESYS PLC runtime as an app. The PLC vendors are shipping Linux inside the controller while plants debate whether it's ready for the server room.
The way you run software changed. Config-as-files, containers, git — the practices that make a system rebuildable instead of precious. They exist on Windows, technically. They're native on Linux. More on this below, because it's the real prize.
The two models, side by side
THE WINDOWS BOX · since ~2005
- INSTALL · click Next for an hour, per server
- ADMIN · RDP in, click around, hope
- CONFIG LIVES · in the registry + one PC's C: drive
- BACKUP · disk image, tested never
- PATCHING · monthly reboot, everyone holds breath
- REBUILD AFTER FAILURE · a weekend, from memory
THE LINUX MODEL · now
- INSTALL · one command, same result every time
- ADMIN · config files; changes reviewed like drawings
- CONFIG LIVES · in git — history, diffs, sign-off
- BACKUP · the repo + data volume; rebuild is the test
- PATCHING · restart a service in seconds, not a server
- REBUILD AFTER FAILURE · minutes, from the file
The left column isn't a caricature — it's how most SCADA servers I've seen are actually run. The right column isn't aspirational — it's how my lab has run for months, on the same SCADA software your plant already uses.
The numbers, in pictures
Start with what the operating system itself costs you before your SCADA does any work. On my rack, both N3uron nodes — edge, central, historian, REST API, MCP server, actively moving live data — together used 469 MB of memory, measured while writing this. A Windows Server with a desktop idles at several times that before you install anything.
MEMORY USED BY THE PLATFORM LAYER
Lower is better. The green bar is doing the actual job; the big blue one hasn't started yet.
That's not about saving money on RAM. Smaller footprint means the same job runs on a fanless box at the site, means one mini-PC instead of a licensed VM host, means the historian and the gateway fit next to each other instead of each demanding its own Windows machine.
Then there's the restart calendar — the one your operations team actually feels. A patched Windows server means a monthly reboot window, and a SCADA reboot means operators staring at disconnected clients while someone watches a progress spinner at 2 a.m. On Linux, security patches to services restart the service — seconds, not a server. The whole machine restarts a couple of times a year for kernel updates, on your schedule.
PLANNED SERVER RESTARTS IN A YEAR · typical patch policy
Windows SCADA server · monthly security patches, each wanting a reboot
Linux SCADA server · a couple of kernel updates; everything else restarts as a service, in seconds
↻ = the whole server goes down and someone has to be awake for it. Twelve nervous nights against two.
And when a box does die: in my Kubernetes lab I deleted a running Ignition gateway outright and it was rebuilt, unattended, in 74 seconds — same name, same config, because the config wasn't trapped inside the machine. That's the difference between a server you restore and a server you reprint.
The real prize: config in files, files in git
Here's the part I'd lead with if I only had one minute. The strongest reason to put SCADA servers on Linux isn't the kernel — it's that the Linux way of running software assumes the machine is disposable and the files are precious, and modern SCADA finally supports that.
Ignition 8.3 stores gateway configuration as files on disk. N3uron's entire node — every module, every tag — is JSON files; in my lab I enabled history on twenty tags with a one-line text edit and a restart. Put those files in git and you get, for free, what the software world calls GitOps and what a plant would call a management-of-change system that enforces itself: every change reviewed before it lands, every version kept forever, every site rebuildable from the repo, and an audit trail that answers "who changed the setpoint and when" in one command. I've written a full piece on infrastructure-as-code for SCADA and built the twenty-site version of it in the lab, so here I'll just say: this is the property everything else hangs off, and on Windows it's swimming upstream while on Linux it's the current.
| The Windows box | The Linux model | |
|---|---|---|
| Where truth lives | inside one machine | in a repo, applied to machines |
| A dead server is | a crisis | an inconvenience (reprint it) |
| Change control | policy + memory | enforced by review + history |
| Patch a service | reboot the server | restart the service, seconds |
| Twenty sites | twenty snowflakes | one template, twenty stamps |
| OS licence per site | paid, plus CALs | zero |
So why hasn't your plant moved? The honest reasons
If Linux were simply better, everyone would have switched. The reluctance is real, and most of it is rational — so name it properly.
- The vendor stack says Windows on the box. FactoryTalk, WinCC, most AVEVA products — Windows-only, full stop. If your SCADA is one of those, the OS decision was made for you, and it renews itself with every version upgrade. This is the single biggest anchor, and it only moves when the platform decision moves.
- "Supported configuration" is a legal phrase, not a technical one. Plants run what the support contract names. If the vendor certifies Windows Server only, running anything else means owning every incident alone. Nobody risks that for an operating system. (This is why vendor-official Linux support — Ignition's, N3uron's — matters more than any benchmark.)
- DCOM never died. Anywhere OPC Classic still links two systems, a pair of Windows boxes is chained together by the protocol itself. OPC UA removed the dependency years ago, but brownfield links outlive everything.
- Validated systems. In pharma and food, the paperwork cost of changing a validated system dwarfs the engineering cost. "It's better" doesn't clear GxP revalidation on its own; those systems move on their natural replacement cycle, not before.
- Skills, honestly assessed. Every integrator on the panel-builder circuit can nurse a Windows box. The team that's never touched a shell prompt isn't wrong to hesitate — though the gap is smaller than feared: administering a well-built Linux SCADA node is mostly not touching it, and the config-in-files model means the daily work is reading diffs, not typing arcane commands.
- Asset life. Plant computers live 15–25 years. A large share of today's estate simply predates the moment Linux became a realistic option, and it will age out slowly. That's fine. The question is what you install next.
Notice what's not on the list: any claim that Windows keeps the process running better. The reluctance is contractual, historical, and human — which means it yields to planning, not to arguing.
What moves and what stays
Nobody serious is proposing Linux on your engineering laptop. TIA Portal and Studio 5000 are Windows programs; the commissioning tools for your drives and instruments are Windows programs; they stay, and that's fine. The split that works is servers versus tools:
MOVES TO LINUX · the always-on stuff
- SCADA gateway / server
Ignition runs on Linux officially - Data layer between plant and IT
N3uron ships as a Linux container - Historian
TimescaleDB, InfluxDB — Linux-native - Dashboards
Grafana — Linux-native - MQTT broker / OPC UA plumbing
all Linux-native
STAYS ON WINDOWS · for now, and that's fine
- PLC programming tools
TIA Portal, Studio 5000 — Windows only - Vendor commissioning tools
drives, instruments, protocol utilities - Legacy OPC Classic (DCOM) links
wrap them, then retire them - Operator workstations
wherever your HMI client needs to live
The always-on stuff — the machines that page you at night — moves. The sit-down-and-engineer stuff stays where the vendors put it. A plant that makes only that split gets almost all of the benefit with none of the retraining drama.
The migration ladder — no rung bets the plant
The way this actually happens in a plant is not a migration project with a gantt chart. It's a ladder, climbed one purchase decision at a time.
ONE RUNG AT A TIME — EACH PAYS FOR ITSELF BEFORE THE NEXT
New historian or dashboard on a Linux box
risk: zero risk to operations
Next gateway upgrade lands on Linux, not new Windows licences
risk: planned change, same software
Run it as a container — install becomes one command
risk: low — same gateway, better packaging
Config into git — every change reviewed, every version kept
risk: process change, not downtime
Many sites? Kubernetes keeps the fleet identical and self-healing
risk: only when the fleet is real
Stop at any rung and you still keep everything the rungs below bought you.
Rung one is the classic beachhead: the next historian or dashboard request lands on a Linux box or container — read-only, zero risk to operations, and suddenly the team has one machine's worth of experience. Rung two is the next gateway upgrade: same Ignition, no Windows licence renewal. Rung three packages it as a container so every future install is identical. Rung four puts the config files in git, which is where the compounding starts. Rung five — Kubernetes — is only for real fleets, and I've written honestly about where that's overkill.
Each rung pays for itself before the next one asks for anything. And if the plant stops at rung two forever, it still got the quiet server, the zero licence line, and the restart calendar with ten fewer nervous nights.
Going forward
The direction of travel is not subtle. The vendors' own flagship moves — file-based Ignition, containerized N3uron, an official Helm chart, Linux running inside new PLCs — all assume the same future: plant software defined by files, running on interchangeable Linux machines, changed through review instead of remote desktop. The AI layer arriving now assumes it too: every MCP server, every API-first data layer, every assistant integration ships Linux-native first.
Windows earned its place in the plant when the tools lived there, and for engineering workstations it still does. But the server under the desk — the haunted house nobody will touch — earned its fear honestly, and it doesn't have to be inherited by the next machine. The next time a gateway, a historian, or a data node gets specified, the boring, low-risk, well-supported choice is the penguin. That's the change: it used to be the brave option. Now it's the safe one.
Keep reading
