Voltrus Gateway vs Kepware: Drivers, API and Licensing Compared

By Dzulfikar Ats Tsauri, founder of Voltrus / JoyoDigitama. He builds the protocol tools covered in these posts. Updated October 28, 2026.

If you're shopping for an industrial protocol gateway, Kepware (KEPServerEX) is the name everyone knows. It is the default OPC server in a lot of plants, and it has earned that. But three of its assumptions are awkward for new projects: it runs on Windows, it is licensed per driver and per instance, and its main client surface is OPC rather than an API your application code can call directly.

This is a comparison of Voltrus Gateway and Kepware at the layer they share: getting data out of PLCs and field devices. It covers platform, how S7 and Allen-Bradley connectivity is packaged, the API, licensing, and the cases where you should keep Kepware or run both.

Both Are Plumbing, Not SCADA

A common mix-up in forum threads is "should I use Kepware or a SCADA?" Kepware is not a SCADA. It translates device protocols into OPC UA or OPC DA so other software can read them. It has no operator dashboards, no trend charts and no alarm notification of its own; those live in whatever consumes the data.

Voltrus Gateway sits in the same layer. It holds the device connections and exposes the data over gRPC, and it does not draw screens either. So the real question is which protocol layer to put under your SCADA, historian or custom collector, not whether to replace one with the other. If you want dashboards and alarms on top, that is what Voltrus SCADA or any other SCADA is for.

Platform Coverage: Linux and Windows vs Windows Only

Kepware is a Windows application. It runs on Windows Server, and on desktop Windows for development. Deploying it at the edge, next to a PLC on the shop floor, means a Windows license and Windows patching on that box, and its configuration UI is a Windows desktop application.

Voltrus Gateway is a single static Rust binary for Linux (x86_64 and aarch64) and Windows (x64). Drop it in a container, on an aarch64 board or on a Windows server. There is no installer and no runtime to install. For edge and containerised deployments that is the difference between "a service" and "a Windows VM we have to patch."

Protocols: Siemens S7 and Allen-Bradley Without Extra Drivers

Kepware reaches different device families through separate drivers, and licensing follows the drivers you enable. In a plant with a Siemens line, an Allen-Bradley packaging area and Modbus meters, that is three driver line items plus the base server, before the OS license. Check a current quote rather than trusting a number from a forum post; the structure is what matters.

Voltrus Gateway ships Modbus TCP, OPC UA, EtherNet/IP (CIP), Siemens S7, DNP3 and BACnet/IP in the one binary, each with read, write, subscribe and discover. You do not pick a driver; you pick a protocol in the connect call. MQTT ships too, with publish, read and subscribe on the same API.

What those two PLC protocols involve on the wire is worth knowing, because it is the work you are paying for either way:

• Siemens S7 runs over ISO-on-TCP (RFC 1006) on TCP/102. The sequence is TCP connect, COTP connection request and confirm, then an S7 "setup communication" exchange that negotiates PDU size, then read and write jobs against data blocks, inputs, outputs, markers, timers and counters. The CPU is addressed by rack and slot, which is one of the per-connection options in the gateway's connect request. For the protocol detail see the S7 communication protocol guide.
• Allen-Bradley uses EtherNet/IP with CIP on TCP/44818. ControlLogix and CompactLogix expose their tag database by name, so you browse the symbol table and read tags rather than raw addresses. That requires a real CIP stack: Forward Open, connection path routing and tag segment encoding. Older MicroLogix and SLC controllers use data-file addressing such as N7:0 instead, and OPC servers often treat them as a separate driver, so confirm the controller family before you commit. Port details are in EtherNet/IP port 44818 explained.

The API Surface: Typed gRPC vs OPC and COM

This is the biggest architectural difference. Kepware's primary client surface is OPC UA and OPC DA, plus legacy COM/DCOM for DA clients. To read a tag from your own code you go through an OPC client library, or through Kepware's REST and IoT Gateway add-on. If your consumers are old OPC DA clients, Kepware's DA support is exactly what you need; see OPC UA vs OPC Classic DA for why that matters.

Voltrus Gateway exposes a typed gRPC API directly: OpenSession, ReadTags, WriteTag, SubscribeTags (server-streamed) and Discover. Your application uses one client regardless of the device protocol. Tag values are carried as a typed oneof (bool, int32, int64, uint32, float, double, string, bytes) plus a source type string such as CIP.DINT, so a CIP DINT or an OPC UA string round-trips intact instead of being flattened to a number.

Licensing: One-Time per Host vs Server + Drivers + Add-ons

Kepware's licensing stacks: a base server license, drivers (some bundled, some purchased), and add-ons such as the IoT Gateway or redundancy. Tag-count tiers push larger deployments into bigger editions, and maintenance is usually a recurring line on top.

Voltrus Gateway is a one-time purchase per host. One license covers one machine running the binary, with no per-tag metering, no driver line items and no subscription. Deploy on as many hosts as you license.

Comparison Table

When Kepware Still Wins

Kepware is the right call for a lot of plants. Keep it when:

• You already run it with hundreds of configured connections. The engineering hours in that configuration are real, and ripping it out buys you nothing.
• Your consumers are OPC DA or OPC UA clients (a SCADA, MES or historian) and you want the gateway to be an OPC server.
• You need a niche or legacy driver Voltrus Gateway does not ship, such as older PLC families or some serial protocols.
• You are a Windows-only plant with an operations team that already knows it.

Running Both

They are not mutually exclusive. A reasonable split in a mixed plant: leave Kepware serving the legacy and OPC-only devices to the existing SCADA, and use Voltrus Gateway at the edge for new work where code needs typed values (a cloud pipeline, a custom collector, an edge service). Voltrus Gateway also speaks OPC UA as a client, so a Kepware OPC UA endpoint can be one of its sources if you want a single API in front of everything.

When Voltrus Gateway Wins

It wins when you are building new software on top of PLC data and want an API your code can call directly, with no OPC client library in the middle. It wins at the edge on Linux or in a container, and on licensing simplicity for teams that do not want to track driver SKUs and tag tiers. For how the protocol engines are structured in one binary, see Modbus, OPC UA and EtherNet/IP in one binary.