Skip to content
Proxus 2.0.0 Proxus 2.0: the largest release in Proxus history Release notes

Comparison · Kepware

Proxus and Kepware solve different halves of the problem.

Kepware Server (formerly KEPServerEX; since March 2026 part of Velotic, the TPG-backed company that also owns ThingWorx and Proficy) is a connectivity server: it speaks to almost anything on a plant floor and presents it as standard tags. Proxus is a data layer: it collects, models, governs, stores and delivers. Comparing them as substitutes usually leads to the wrong decision, including for us.

What it is
Kepware: Industrial connectivity server, from Velotic (TPG; formerly PTC)
What Proxus is
An industrial data platform: collect, model, govern, store, deliver
Honest summary
The industry’s reference OPC server. Deep driver coverage; a different job from a data layer.
Your options
Keep Kepware as the driver layer and put Proxus above it, or import the Kepware project and move the supported devices into Proxus line by line. Both paths are below.

Give them their due

What Kepware is genuinely good at.

A comparison that only lists the other product's weaknesses is a sales sheet, not a decision aid. These are real strengths, and some of them are reasons not to buy Proxus.

  • The deepest driver library in the category

    Kepware has been shipping industrial drivers for over thirty years, by the vendor’s own account. For obscure, legacy or regional controllers, the odds that a driver already exists are higher with Kepware than with anyone else, including us.

  • A proven, conservative product

    It is widely deployed and is often already installed. In a brownfield site, "it is already there and it works" is a real engineering argument.

  • Standards-first

    OPC DA and OPC UA server interfaces are the point of the product, which is exactly what makes it easy to put a data layer on top of it.

  • Straightforward when the job is aggregation

    If the requirement is "read these machines and expose them as tags", Kepware does that with less conceptual overhead than a modelling platform.

Attribute by attribute

Where the two actually differ.

Both columns are filled in. Where Kepware is ahead, the row says so.

  • What it is built to do

    Proxus

    Collect from field devices, model the signals, govern access, store history and deliver to consuming systems.

    Kepware

    Read from field devices and expose standardised tags to clients over OPC and other interfaces.

  • Driver coverage

    Proxus

    66 protocols across 30 vendor and standard families in the current build: strong on mainstream PLCs, CNCs and robots, narrower on legacy and regional devices.

    In the docs: Driver coverage

    Kepware

    The largest library in the industry, built over three decades, including many legacy and niche controllers.

  • Operating system

    Proxus

    Linux containers throughout, deployed with Docker or Kubernetes. No Windows requirement at the edge.

    In the docs: Operating system

    Kepware

    Kepware Server runs on Windows. Kepware Edge is the Linux, containerised product, and is newer with a narrower driver set.

  • Edge footprint

    Proxus

    One gateway process plus a messaging container next to it that holds the local buffer, installed by one script, with no database at the edge. Built for a plant server or a small industrial PC.

    In the docs: Edge footprint

    Kepware

    A Windows service on a Windows machine for Kepware Server; Kepware Edge is the containerised alternative.

  • Replacing a failed box

    Proxus

    Gateways keep no configuration of their own: it comes from the hub you host. Install the replacement with a new command from the hub; it pulls the same devices, rules and functions. No cloud service is involved.

    In the docs: Replacing a failed box

    Kepware

    Reinstall and restore the configuration, or recover from a backup. Kepware+ Manager, a SaaS control plane, adds central configuration for the servers connected to it.

  • Data model

    Proxus

    Asset-centric. Signals carry units, scaling, quality and an ISA-95-shaped namespace path before anything consumes them.

    In the docs: Data model

    Kepware

    Tag-centric. Context (which machine, which line, what unit) is added by whatever consumes the tags.

  • History

    Proxus

    Built-in telemetry historian with retention policy and query access, in the same deployment.

    In the docs: History

    Kepware

    Data logging writes tag values to a database. A historian, retention policy and query layer are separate products, such as Proficy Historian in the same Velotic portfolio.

  • Dashboards, rules and alarms

    Proxus

    Included: operational dashboards, scheduled reports, rule engine and statistical anomaly detection at the edge.

    In the docs: Dashboards, rules and alarms

    Kepware

    Provided by other products in the Velotic portfolio (Proficy HMI/SCADA, ThingWorx) or by third parties.

  • Delivery targets

    Proxus

    18 destination systems: databases, brokers, cloud IoT services and REST endpoints, configured per device.

    In the docs: Delivery targets

    Kepware

    Clients connect to it, plus IoT gateway and data logging options for selected destinations.

  • AI access

    Proxus

    Governed MCP interface in the platform: read tools by default, plus one write tool limited to the user’s own permissions, with deletes blocked. Same roles and audit trail as any other consumer.

    In the docs: AI access

    Kepware

    Through the wider Velotic portfolio (ThingWorx, Proficy) and third-party tooling.

  • Licensing shape

    Proxus

    Priced by connected gateways and data rate, with published recommended prices from $5,500 a year. Tags, devices, users and dashboards are unlimited in every package.

    Pricing: Licensing shape

    Kepware

    Per server and per driver suite, with commercial terms from the vendor (Velotic since March 2026).

Proxus figures come from the current build's own driver and target inventory. Kepware figures come from the vendor's published material, linked at the end of this page. Nothing here is measured on a benchmark neither party has agreed to.

Choose Kepware

When we are not the answer.

  • You need a driver for a device we do not support, and replacing that device is not an option.
  • You are standardised on Velotic tooling (ThingWorx, Proficy) and staying in one vendor’s portfolio matters more than platform consolidation.
  • The requirement really is only an OPC server: no modelling, no history, no delivery layer, no governance.
  • The plant is Windows-centric by policy and a Linux container at the edge would be an exception to fight for.

Choose Proxus

When the shape of the problem fits.

  • The data has to reach several systems, each with its own format and delivery strategy.
  • You need the same model on the second and tenth site, not a per-site tag naming scheme.
  • History, dashboards, rules and AI access are part of the requirement rather than four more procurements.
  • The deployment must run on Linux containers, on-premises or air-gapped, operated by your own team.
  • You want to move Siemens, Modbus TCP and OPC UA devices off per-server driver licences without rebuilding their tags by hand.

Not either/or

How they are used together.

  • Kepware as the driver layer, Proxus as the data layer

    This is the most common arrangement in plants that already run Kepware. Proxus connects to it as an OPC UA client, and the existing tag configuration keeps its value instead of being rebuilt.

  • Model on top, without touching the field

    Tags arriving from Kepware are mapped into the namespace with units and asset context. Nothing changes at the controller, and the modelling work is done once.

  • One delivery layer for everything

    Signals from Kepware and from devices Proxus reads natively leave through the same outbound channels, with the same delivery visibility.

  • Import the Kepware project

    Proxus reads channels, devices and tags from a running Kepware server through its Configuration API and, after you review each change, turns the Siemens, Modbus Ethernet and OPC UA client channels into native Proxus devices. Keep Kepware, or retire it line by line.

    How the import works

Sources

Last checked against vendor material: October 2026.

Products change. If something on this page is out of date or wrong, tell us and we will fix it, including when the correction favours Kepware.

Questions

Proxus and Kepware: short answers.

Can Proxus import my Kepware project?
Yes. Proxus reads channels, devices and tags from a running Kepware server through its Configuration API and, after you review each change, turns the Siemens, Modbus Ethernet and OPC UA client channels into native Proxus devices.
Can Proxus and Kepware run together?
Yes, and in plants that already run Kepware it is the most common arrangement: Proxus connects to Kepware as an OPC UA client, and the existing tag configuration keeps its value.
Does Proxus need Windows at the edge?
No. Proxus runs as Linux containers with Docker or Kubernetes. Kepware Server runs on Windows; Kepware Edge is its Linux, containerised product.
When is Kepware the better choice?
When you need a driver for a device Proxus does not support and replacing the device is not an option, or when the requirement really is only an OPC server.

Next step

Find out what your Kepware project becomes in Proxus.

Send us the channels and devices on your Kepware server. An engineer replies with which channels the importer turns into Proxus devices and which are better left on Kepware over OPC UA.

  1. 01

    Scoping call

    Equipment, protocols, sites and the systems the data has to reach.

  2. 02

    Technical walkthrough

    A working demo against a scenario that resembles your plant, not a generic tour.

  3. 03

    Pilot plan

    A defined first line or site, with the deployment and security questions answered up front.

  4. 04

    Roll-out

    The same templates bring the next lines and sites online.