vNode vs KepServerEX: Complete 2026 Comparison for Industrial Automation Engineers

For system integrators and automation engineers evaluating industrial connectivity platforms, the choice between KepServerEX (Kepware, now PTC) and vNode (Vester Business) is one of the most consequential architectural decisions in an OT/IT convergence project. Both platforms bridge proprietary PLC and RTU protocols to SCADA, historians, MES, and cloud infrastructure — but they diverge sharply on licensing model, data resilience, platform flexibility, redundancy architecture, and security posture in ways that directly affect project cost, long-term operational risk, and scalability.

This comparison is built on technical facts. Limitations cited for KepServerEX are sourced directly from PTC’s official driver and plug-in documentation — not third-party claims. Where vNode advantages are described, they reflect the platform’s published architecture and proven deployments across 40+ countries.

KepServerEX: Two Decades of OPC Connectivity Leadership

KepServerEX, developed by Kepware Technologies and acquired by PTC in 2016, has been the dominant OPC server in industrial automation for more than 20 years. It earns its market position through an unmatched driver library of 150+ protocols — from Siemens S7 and Rockwell ControlLogix to niche devices like Fisher ROC flow computers, Lufkin pump controllers, Mettler Toledo scales, and legacy DCS systems. For plants with legacy or regional devices, KepServerEX is often the only commercial option with a qualified driver.

Its OPC DA and OPC UA server implementations are battle-tested and widely certified. A global network of integrators trained on KepServerEX over 20 years represents real institutional knowledge. These are genuine strengths that any honest comparison must acknowledge.

vNode Industrial Data Platform: Unified Architecture, No Plug-In Stack

vNode is developed by Vester Business (Spain, founded 2006). Unlike KepServerEX — a 32-bit Windows OPC server that delivers IoT, redundancy, and historian capabilities through separately purchased and annually licensed plug-ins — vNode ships as a unified 64-bit service with native binaries for Windows, Linux x86-64, and ARM. Protocol connectivity, MQTT client/server, a MongoDB-backed disk historian, disk-based Store & Forward, built-in Primary/Backup redundancy failover, Sparkplug B, REST API server, and an MCP Server for AI platform integration are all modules of the same platform. None require a separate license purchase or an additional installed software component. Configuration is done entirely through a web browser; no Windows desktop software is required on site. The platform is deployed across 40+ countries, including Oil & Gas operators, European utilities, and pharmaceutical manufacturers.

Where vNode is demonstrably better positioned for current OT/IT engineering projects is in protocol currency and architecture decisions made after IEC 62443, edge Linux deployments, and MQTT became real operational requirements — not features added as retrofits to a legacy core. Its IEC 61850 driver includes GOOSE: the fast multicast messaging used for protection relay coordination between IEDs in modern substations, which KepServerEX’s IEC 61850 driver does not implement. IEC 60870-5-104 connects with TLS transport encryption. Store & Forward is disk-based by design, not a RAM buffer. For engineers working to ISA/IEC 62443 zone and conduit principles, NIS2-oriented critical infrastructure designs, or deploying on ARM edge hardware, the platform’s architecture addresses these requirements natively. The honest trade-off relative to KepServerEX: fewer legacy device drivers, and a smaller — though actively growing — global integrator network.

vNode vs KepServerEX: Comparison at a Glance

1. Licensing: Perpetual vs Annual Subscription

The licensing model difference between vNode and KepServerEX is one of the most practically significant factors for industrial projects — and one that is often underweighted in initial evaluations.

KepServerEX operates on an annual subscription model. The base server subscription recurs every year. On top of that, each driver family is a separate license: a plant connecting to Siemens S7 PLCs, Rockwell ControlLogix, and Schneider Modbus devices requires three driver licenses in addition to the base subscription. Any IoT or cloud connectivity (MQTT, REST, cloud) requires the IoT Gateway Plug-in — another separate purchase, with per-tag licensing. Redundancy requires the Media-Level Redundancy Plug-In. A historian requires the DataLogger or Local Historian Plug-in. Each is a separate annual cost.

For a plant running five protocol families with MQTT connectivity and a redundant server pair, it is not unusual to have five or more separate line items in the annual Kepware renewal. Every year.

vNode uses a perpetual license model. One license per deployed node — purchased once, owned permanently. Features are unlocked per module on that node: the OPC UA module, MQTT module, Historian module, Redundancy module, Sparkplug B, MCP Server, and others are selected at purchase, but the license itself never expires and never requires renewal. There is no annual subscription risk.

For industrial systems with 15–20 year operational lifespans — a substation, a refinery, a water treatment plant — this distinction is material. A perpetual license purchased today for a Iberdrola substation will still be running and licensed in 2040, without a single renewal decision, renewal cost, or business continuity risk from a lapsed subscription. A KepServerEX subscription that lapses stops the system.

On a 10-year total cost of ownership basis, a perpetual model with comparable module coverage typically delivers 40–60% lower lifetime cost than an equivalent annual subscription with add-on plug-ins — even when the perpetual license has a higher initial price.

2. Platform and Deployment: The Linux and ARM Question

KepServerEX runs exclusively on Windows — specifically as a 32-bit WOW64 application on 64-bit Windows. There is no native Linux deployment. There is no ARM support.

Kepware Edge partially addresses this by offering a Linux x86-64 deployment. But Kepware Edge carries significant constraints: it supports only 6 drivers (Allen-Bradley ControlLogix, Mitsubishi, Modbus TCP, OPC UA Client, Siemens TCP/IP, Siemens S7 Plus), has no REST Client or REST Server agents (MQTT Client only), licenses on 7-day renewable leases from a network license server that must remain reachable, and inherits all of the full KepServerEX limitations on Store & Forward and redundancy. Kepware Edge is a reduced-capability Linux port, not a native edge platform.

vNode runs natively on Windows, Linux x86-64, and ARM. The same software running on a low-cost ARM gateway at a remote wind turbine in Senegal runs identically on a ruggedized Industrial PC at a petrochemical plant in Mexico. Full feature parity across all platforms. The Infinity Power wind project at Taiba N’Diaye, Senegal — connecting the wind power station to a UK-based control center over IEC 60870-5-104 — used vNode on edge hardware that KepServerEX’s ARM-incompatible architecture cannot reach.

For system integrators building repeatable multi-site architectures, platform consistency matters: the same configuration, same modules, same monitoring approach whether the hardware is an ARM gateway, a Linux server, or a Windows IPC.

3. Data Resilience: Store and Forward

The question every engineer running a remote asset should ask: what happens to process data when the network goes down?

KepServerEX’s answer, from PTC’s own documentation:

“This buffer is entirely in memory and is not written to disk.”

The IoT Gateway Plug-in (the component responsible for MQTT and REST data delivery) buffers up to 100,000 events per agent in RAM. When KepServerEX’s service restarts, crashes, or the Windows host reboots, every buffered event is permanently lost. There is no disk persistence, no recovery, no replay.

The situation is worse for Wide Format publishing: “Wideformat sends only the latest value for each tag and has no buffer. If a publish fails while using wideformat, the next publish is the latest scanned values for each tag.” Zero buffer. Any endpoint outage in Wide Format means the data from that entire outage period is gone.

For serial and legacy protocol drivers — the DF1 driver for Allen-Bradley serial, the Fisher ROC drivers for Emerson flow computers, Enron Modbus for oil & gas RTUs — PTC’s documentation is even more direct: “Store and forward feature is not supported.” The Fisher ROC protocol driver’s own error code table lists error code 22 as “Invalid store and forward path” — the protocol itself rejects Store & Forward attempts.

This is not an abstract concern. Oil & Gas remote assets, electric substations, wind farms, and water distribution networks routinely experience network connectivity gaps of minutes to hours. In these applications, missing process data is not an inconvenience — it is a compliance issue, a custody transfer dispute risk, or an operational safety gap.

vNode’s Store & Forward writes to disk. Data is buffered locally during network disruptions and forwarded automatically, in sequence, when connectivity is restored. Zero data loss is a core architectural guarantee — not an optional configuration, not a paid add-on, and not dependent on the service staying up without interruption.

4. High Availability and Redundancy

Every single KepServerEX driver manual — across all protocol families examined, including Siemens, Allen-Bradley, Modbus, DNP3, IEC 60870-5-104, BACnet/IP, Fisher ROC, Enron Modbus, and Lufkin — contains the same language:

“Redundancy is available with the Media-Level Redundancy Plug-In. Consult the website, a sales representative, or the user manual for more information.”

This is not server-level high availability. The Media-Level Redundancy Plug-In provides device and communications-path redundancy — it can switch between a primary and backup communication path to the same field device, or between two identical device pairs. It is also limited: it does not support all drivers, it is not compatible with Siemens S7-15xxR/H native controller redundancy (customers must choose one or the other), and it doubles the server’s tag count by mirroring all client items to the secondary device.

True server-level KepServerEX high availability — failover between two KepServerEX instances — requires a separate Redundancy Synchronization Plugin, itself an additional licensed component. Redundancy in KepServerEX is therefore a multi-layer paid add-on stack.

vNode includes built-in Primary + Backup hot-standby failover as a standard module. This is not an add-on. It is not a separate purchase. Automatic failover is transparent to connected SCADA, historian, and IT systems. For organizations designing systems to ISA/IEC 62443 availability requirements or operating critical infrastructure under NERC CIP or NIS2 frameworks, having redundancy as a guaranteed baseline feature — not a supplemental budget line — changes the project economics.

5. Cybersecurity Architecture

Several cybersecurity gaps in KepServerEX are worth examining directly, particularly for engineers designing architectures toward IEC 62443 zone and conduit principles or NIS2 risk management requirements.

Siemens TCP/IP Ethernet Driver (covers S7-300/400/1200/1500): PTC’s own driver documentation states there is no password support. The connected PLC must be configured for “Full access (no protection)” in TIA Portal and must have “Permit access with PUT/GET communication from remote partner” enabled. Any device on the same network segment with knowledge of the protocol can read and write to the PLC without any credential challenge.

IoT Gateway MQTT write-back: PTC’s IoT Gateway manual explicitly states: “The MQTT subscription option does not check for user authorization against the User Manager or Security Policies Plug-In. Any valid JSON published to the configured topic will be written to the server.” This is a documented security gap: any device with access to the MQTT broker — even one that bypasses Kepware’s own security policies — can write arbitrary values to any KepServerEX tag via MQTT subscription.

Transport encryption across protocol families: IEC 60870-5-104, IEC 60870-5-101, IEC 61850 MMS, BACnet/IP, Modbus (all variants), DNP3, and most field device drivers have no transport-layer encryption in KepServerEX. The secure variants of these protocols — IEC 62351-3 for IEC 104, BACnet Secure Connect (ASHRAE 135-2020aa) for BACnet, IEC 62351-4 for IEC 61850, DNP3 Secure Authentication v5 for application-layer auth — are either partially implemented or completely absent.

IEC 61850 and GOOSE: For substation automation engineers, this is critical: KepServerEX’s IEC 61850 driver is MMS-only. GOOSE — the fast Ethernet multicast messaging used for protection relay coordination between IEDs in substations — is completely absent from the driver. This is not a configuration limitation; it is an architectural absence.

vNode is designed for Industrial DMZ deployment at Purdue Level 3.5 with reverse connections, data diode-compatible one-way data flows, RBAC user management, and audit-ready diagnostic logs — aligned with ISA/IEC 62443 zone and conduit architecture and relevant to NIS2 compliance-oriented designs for European critical infrastructure operators.

6. Cloud and IoT Connectivity

In KepServerEX, cloud and IoT connectivity is the IoT Gateway Plug-in — a separately licensed add-on with a per-tag count model. It requires a 32-bit Java 21 JRE installed on the Windows host. PTC’s documentation contains this warning: “To prevent the loss of data and to keep the server running properly, do not install Java updates while in production.” This creates an operational dependency on a frozen Java runtime version on a production OT server — an ongoing security and maintenance constraint.

The same tag published to both an MQTT agent and a REST agent counts as two IoT Gateway license units. On Kepware Edge (the Linux deployment), the REST Client and REST Server agents are entirely absent — only MQTT Client is available.

AWS IoT is explicitly supported via MQTT and client certificate authentication. Azure IoT Hub and Google Cloud IoT are not natively named in PTC’s documentation — connectivity relies on standard MQTT broker compatibility.

In vNode, MQTT, REST API, Sparkplug B, and cloud connectivity are built-in modules. No Java dependency. No per-tag count licensing. Native integration with AWS IoT Core, Azure IoT Hub, Google Cloud IoT, and OSIsoft PI. The MCP Server module — an vNode-exclusive capability — exposes structured industrial data directly to AI/ML platforms and industrial copilots via the Model Context Protocol, enabling real-time process data delivery to AI tools without custom middleware.

7. Protocol and Driver Coverage: Where KepServerEX Leads

On raw driver breadth, KepServerEX leads — and this deserves honest acknowledgment. With 150+ drivers covering virtually every PLC, DCS, RTU, and instrumentation protocol in industrial use, including niche and legacy devices that no other commercial platform covers, KepServerEX is the only option for certain legacy integration scenarios.

vNode covers the protocols used in the overwhelming majority of modern industrial projects: OPC UA/DA, Modbus TCP/RTU, Siemens S7 (300/400/1200/1500), EtherNet/IP, DNP3, IEC 60870-5-104, IEC 61850, BACnet/IP, SNMP, MQTT, REST API, and more — fully covering modern Siemens, Rockwell Automation, Schneider Electric, and ABB environments. Where both platforms provide coverage, the architectural advantages of vNode described above apply fully.

One specific note on Rockwell Micro800: KepServerEX’s Micro800 Ethernet driver officially supports only the Micro850 (not Micro810, Micro820, Micro830, or Micro870). More significantly, its documentation requires users to modify the PLC program itself to access data: “If access is required, cut and paste the tags from the Local variable table to the Global variable table.” Collecting process data from a Micro850 via KepServerEX requires a PLC programmer to restructure the controller program and perform a controller restart — a production maintenance window just to enable OPC connectivity. vNode connects to Rockwell EtherNet/IP devices without imposing code changes on the PLC program.

When KepServerEX Is the Right Choice

• Your project requires a niche or legacy device driver that only exists in Kepware’s library — certain regional DCS systems, discontinued instrumentation, or proprietary protocols with no standard implementation.
• Your organization is fully standardized on Windows and has no plans to deploy Linux or ARM infrastructure at the edge.
• You have a large existing KepServerEX installation not in a migration or modernization cycle, and the cost and disruption of migration outweighs the long-term licensing and architectural benefits.
• Your project scope is simple OPC DA/UA server connectivity on a short-duration or low-criticality application where the perpetual licensing advantage and architectural differences do not justify switching platforms.

When vNode Is the Right Choice

• Linux or ARM deployment required — remote gateways, Raspberry Pi-class industrial computers, containerized edge environments. Kepware cannot reach these platforms.
• Long project lifespan — oil & gas, utilities, substation automation, pharmaceutical manufacturing. A perpetual license eliminates subscription renewal risk for systems designed to run 15–20 years.
• High tag count with multiple protocols — mining, petrochemical, pharmaceutical, and multi-plant manufacturing where KepServerEX’s per-driver and per-IoT-tag licensing accumulates into significant recurring cost.
• Zero data loss required — remote oil & gas assets, electric substations, wind farms, water distribution networks with intermittent connectivity where RAM-only buffering is architecturally insufficient.
• Built-in high availability from day one — production environments where redundancy must be guaranteed as a baseline, not purchased separately after the project is live.
• Cybersecurity-aligned OT/IT architecture — projects targeting ISA/IEC 62443 zone and conduit principles, IEC 61850 GOOSE for substation protection relay coordination, or NIS2 risk management requirements for European critical infrastructure.
• AI/ML integration on the roadmap — the MCP Server module delivers structured industrial data directly to AI platforms without additional middleware or custom development.
• System integrators building multi-site portfolios — vNode’s multiplatform, no-code, browser-based architecture enables repeatable deployments across diverse hardware with consistent tooling and faster commissioning.

How vNode Solves This

The vNode Industrial Data Platform directly addresses the architectural gaps that organizations running KepServerEX — or evaluating it for new projects — most commonly encounter in demanding industrial environments.

At National Oilwell Varco (NOV), vNode integrated a hydraulic well model with a Siemens PLC-based drilling control system for real-time optimization — with Store & Forward ensuring no process data was lost during communication interruptions. The combination of Siemens S7 connectivity, real-time data delivery, and disk-based buffering is a combination that a Windows-only OPC server with RAM-only MQTT buffering cannot replicate.

At Iberdrola, vNode manages data flows across large-scale renewable energy infrastructure connecting field sensors, SCADA, historian, and enterprise systems — with the built-in redundancy module providing the high availability that grid-connected generation assets require without an additional plug-in purchase.

For the Infinity Power Taiba N’Diaye Wind Power Station in Senegal, vNode provided edge connectivity to a UK-based control center using IEC 60870-5-104 with TLS encryption — deployed on hardware that KepServerEX’s ARM-incompatible architecture cannot reach, configured via browser from the engineering office in the UK without a local Windows workstation.

For system integrators managing 10, 50, or 200 customer sites, vNode’s perpetual licensing model, multiplatform support, and browser-based configuration eliminate the three most common friction points in scaled deployment: recurring license management, hardware platform constraints, and remote configuration dependency on Windows desktop access.

To evaluate vNode for a new project or as a migration path from KepServerEX, contact the vNode team for a protocol-by-protocol assessment of your architecture, or explore the full technical capabilities at the vNode User Manual.

Frequently Asked Questions

What is the main difference between vNode and KepServerEX licensing?

vNode uses a perpetual license model — one license per deployed node, purchased once, with features unlocked per module. There is no annual renewal. KepServerEX uses an annual subscription model with additional per-driver licenses for each protocol family, per-tag licensing for the IoT Gateway, and separate licenses for plug-ins such as redundancy, historian, and alarms. For projects with 15–20 year operational lifespans, the perpetual model typically delivers a significantly lower total cost of ownership.

Can vNode replace KepServerEX in an existing deployment?

For the protocols used in most modern industrial projects — Siemens S7, Rockwell EtherNet/IP, Modbus, OPC UA/DA, DNP3, IEC 60870-5-104, IEC 61850, BACnet/IP, MQTT — vNode provides equivalent or superior coverage. For niche or legacy devices requiring KepServerEX-specific drivers, a protocol-by-protocol review is recommended before migration. Contact the vNode team for a specific evaluation of your device list.

Does KepServerEX support Store and Forward for MQTT and REST connectivity?

The IoT Gateway Plug-in buffers up to 100,000 events per agent in RAM only. PTC’s documentation explicitly states: “This buffer is entirely in memory and is not written to disk.” When the KepServerEX service restarts or the host reboots, all buffered data is permanently lost. Wide Format publishing has no buffer at all. For serial and legacy drivers such as DF1 and Fisher ROC, Store and Forward is explicitly documented as not supported. vNode’s Store and Forward writes to disk and guarantees zero data loss.

Does vNode run on the same Windows Server infrastructure as KepServerEX?

Yes. vNode runs on Windows Server and Windows 10/11, making it deployable on existing infrastructure without hardware changes. It additionally runs on Linux and ARM, providing deployment flexibility for remote sites and edge environments that KepServerEX cannot reach.