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

Comparison · Ignition

Ignition is a platform you build on. Proxus is a layer you configure.

Ignition is one of the strongest value propositions in industrial software: unlimited tags and clients for a server licence, SCADA, HMI, alarming, reporting and a module ecosystem. It overlaps with us at the edges, but the products ask different things of you: Ignition asks you to build an application, Proxus asks you to configure a data layer. Where Ignition is used for monitoring screens, alarms and reports, Proxus can take that job over in the same install; where operators control equipment from the screen, keep Ignition.

What it is
Ignition: SCADA, HMI and application platform, from Inductive Automation
What Proxus is
An industrial data platform: collect, model, govern, store, deliver
Honest summary
An application platform with unlimited licensing and a huge integrator community. You build the application; we ship a data layer.
Your options
Keep Ignition where operators control equipment and move monitoring screens, alarms and reports into Proxus, or keep Ignition for all of it with Proxus as the data layer beneath. Both paths are below.

Give them their due

What Ignition 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.

  • Unmatched commercial value for what it includes

    Unlimited tags, unlimited clients and unlimited connections on a server licence. For plants that need screens as well as data, very little competes on that basis.

  • A real application platform

    SCADA, HMI, alarming, reporting, scripting and web-deployed clients. If you need an operator screen with control on it, that is Ignition territory and not ours.

  • An enormous integrator community

    Finding people who can build in Ignition is easy almost anywhere in the world. That availability is a genuine risk reducer for a long project.

  • Open technologies and a module ecosystem

    Built on SQL, Python, OPC UA and MQTT, with a large third-party module market including MQTT and UNS tooling.

Attribute by attribute

Where the two actually differ.

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

  • What it is

    Proxus

    A product with a fixed operating model: sources, models, rules, targets and roles are configuration.

    Ignition

    An application platform. What it does is what you build with it.

  • Operator screens and control

    Proxus

    Not a SCADA or HMI. Dashboards are operational views, and platform access to equipment is read-oriented.

    Ignition

    A core strength: HMI, SCADA and web-deployed clients, including control actions.

  • Dashboards, alarms, reports

    Proxus

    Configured rather than built: operational dashboards, alerts with acknowledgement and scheduled reports. Enough to take over monitoring screens; not operator control.

    In the docs: Dashboards, alarms, reports

    Ignition

    Built inside the project you design, with the platform’s screen, alarming and reporting modules.

  • Time to a working data layer

    Proxus

    Configuration of sources, models and targets, narrower scope, less to design.

    Ignition

    Depends on the application you design and who designs it.

  • Data model

    Proxus

    A namespace with units, quality and asset context as product behaviour, with changes recorded in the audit trail.

    In the docs: Data model

    Ignition

    Tags, UDTs and whatever structure your project defines, with UNS commonly added through modules.

  • Footprint at a site

    Proxus

    One gateway process plus a messaging container that holds the local buffer, installed by one script. No database at the edge.

    In the docs: Footprint at a site

    Ignition

    A gateway server on the JVM, usually with a database alongside it for history and application data. Ignition Edge is the lighter edition for edge devices.

  • Scripting

    Proxus

    C# functions in the pipeline through the SDK.

    In the docs: Scripting

    Ignition

    Python (Jython) scripting throughout the platform, which is a large part of its flexibility.

  • Governance

    Proxus

    Roles and object-level permissions, including namespace paths, applied to people, integrations and AI clients.

    In the docs: Governance

    Ignition

    Roles and security zones designed as part of the application.

  • Where configuration lives

    Proxus

    On the hub. Edge gateways keep no configuration of their own and receive it from the hub when they connect.

    In the docs: Where configuration lives

    Ignition

    In the gateway project, backed up and promoted between gateways as project exports.

  • Multi-site rollout

    Proxus

    Templates and a gateway fleet with central visibility, from a documented pattern.

    In the docs: Multi-site rollout

    Ignition

    Gateway network and project export, with the consistency your team enforces.

  • 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.

    Pricing: Licensing shape

    Ignition

    Server licence with unlimited tags and clients.

Proxus figures come from the current build's own driver and target inventory. Ignition 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 Ignition

When we are not the answer.

  • Operators control equipment from the screen: that is SCADA and HMI work, and Proxus is not a SCADA or HMI.
  • You have or can hire Ignition capability, and building exactly what you want is preferable to configuring what a product decides.
  • A single platform for SCADA and data is the architectural preference, and you accept owning the application.
  • The site is small enough that one Ignition server covers screens, history and integration in one purchase.

Choose Proxus

When the shape of the problem fits.

  • You want a data layer without taking on an application to build and maintain.
  • The screens are for monitoring, alarms and reports, and you would rather configure them in the data layer than build and maintain an application for them.
  • The same model has to hold across sites without depending on each project being built the same way.
  • Governed AI access, delivery visibility and audit trail are requirements rather than things to design.
  • The team that will own it is closer to IT than to SCADA engineering.

Not either/or

How they are used together.

  • Ignition for control, Proxus for the data layer

    A common split: keep Ignition where operators control equipment, and let Proxus own collection, modelling, monitoring screens and delivery to the systems beyond the plant.

  • Read from Ignition over OPC UA

    Ignition exposes an OPC UA server, so an existing installation can be a source for Proxus without touching the field layer.

  • Meet on MQTT

    Each Proxus gateway publishes the namespace on its built-in MQTT broker, in JSON or Sparkplug B, so Ignition can subscribe to it alongside its own tags.

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 Ignition.

Questions

Proxus and Ignition: short answers.

Is Proxus a SCADA or HMI?
No. Proxus dashboards are operational views, and platform access to equipment is read-oriented. Where operators control equipment from the screen, keep Ignition.
Can Proxus take over monitoring screens, alarms and reports?
Yes. Operational dashboards, alerts with acknowledgement and scheduled reports are configured rather than built, which is enough to take over monitoring screens.
Can Proxus read data from Ignition?
Yes. Ignition exposes an OPC UA server, so an existing installation can be a source for Proxus. Each Proxus gateway also publishes the namespace on its built-in MQTT broker, in JSON or Sparkplug B, for Ignition to subscribe to.

Next step

Decide which screens move and which stay.

Bring the list of Ignition screens your plant uses. In thirty minutes we separate the monitoring screens, alarms and reports Proxus can take over from the control screens that should stay on Ignition.

  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.