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

Platform · Security & deployment

Your data, your infrastructure, your rules.

Proxus is built to be run by your own team, inside your own network, with the controls a security review will ask about: on-premises, private cloud or fully air-gapped.

Deploys as
Containers, with Docker or Kubernetes
Runs
On-premises, private cloud or air-gapped, no cloud dependency
Access control
Users, roles and object-level permissions, including namespace paths
Operated by
Your team, with documented upgrade and backup paths

Local collection. Central coordination.

Edge gateways collect near the equipment. The hub owns the model and deployment configuration.

Field, edge, hub and consumers Equipment sends data through an edge gateway to Proxus Hub, then to Dashboards & systems. Deployment configuration travels from the hub back down to the edge. Controllers S7 / CIP / MELSEC Machines & robots FOCAS / MTConnect Meters & SCADA Modbus / OPC UA Modelled signals 02 / EDGE Proxus Edge Collect / evaluate / buffer 03 / PLATFORM Proxus Hub Namespace / history / access Dashboards &reports Inside Proxus Databases & cloud Optional destinations Business systems MES / ERP / QMS Configuration: hub to edge 01 / PLANT FLOOR04 / CONSUMERS Field, edge, hub and consumers Read from bottom to top. Field equipment is at the bottom and data travels upward. Equipment sends data through an edge gateway to Proxus Hub, then to Dashboards & systems. Deployment configuration travels from the hub back down to the edge. Deployment manifest 01 Plant floor PLCs / CNCs / robots 02 Proxus Edge Collect / evaluate /buffer 03 Proxus Hub Namespace / history /access 04 Dashboards &systems Built-in views +optional targets

What it solves

What teams run into without it.

  • Plant data leaving the plant

    A platform that only works through a vendor cloud is a policy decision disguised as an architecture.

  • Security review at the end

    Questions about transport, credentials and audit arrive after the pilot, when changing course is expensive.

  • Undocumented drift

    Nobody can say what changed on the gateway between the working configuration and the current one.

What you get

Built in, not bolted on.

  • Container deployment

    A documented path for single-host installs and multi-site fleets alike.

  • Role-based access control

    Permissions across configuration, live data, dashboards and API access.

  • Encrypted transport

    TLS on every link: edge to hub (verified against the platform CA), the hub’s own services, the built-in MQTT broker on 8883 (1883 stays open only for devices that cannot use TLS, and can be closed), and outbound integrations, where server certificates are always verified.

  • Certificate management

    One built-in certificate authority in the Certificate Store issues and renews the platform’s certificates, or use your corporate CA instead. OPC UA trust is managed there too.

  • Recorded configuration

    Pipelines keep revisions you can compare; every other configuration change is recorded in the audit trail.

  • Operational transparency

    Health and delivery status in the product; detailed evidence in support bundles, not in the customer-facing log.

What this enables

What the capabilities add up to, in practice.

  • Pass a security review with answers ready before the pilot, not after
  • Run in a plant that has no outbound internet at all
  • Hand the system over to a team that can actually operate it
  • Repeat a known-good configuration at the next site

Detail

Deployment topologies

Security hardening guide
Single host
Hub and one gateway on the same machine: evaluation, demo or a single small site
Site and centre
Gateways at each site connecting to a central hub over a durable, replayable stream
Fleet
Many gateways across many sites, each with its own identity and capacity, centrally visible
Air-gapped
Fully isolated deployments with no outbound internet requirement; images are loaded offline, the licence is checked offline against a signature, and Copilot runs with a local Ollama model

How it is built

Proxus is written as one system, not assembled from other products: one gateway process at the line, a messaging container beside it for the buffer, and no database at the edge.

Read the architecture

Trust and compliance

Certified, and documented for vendor review.

Certificates and controls
  • ISO 27001:2022

    Information Security Management System

    Certificate PDF
  • ISO 9001:2015

    Quality Management System

    Certificate PDF
  • Runs inside your perimeter

    On-premises, private cloud or air-gapped, no cloud dependency.

  • GDPR and KVKK aligned

    Documented data handling, with rights and retention set out in the privacy policy.

Questions

What teams ask before the first call.

Ask something else
Can Proxus run fully air-gapped?
Yes. There is no requirement for outbound internet access for the platform to collect, model, store and deliver data inside your network. Images are loaded offline. Install without internet access
Docker or Kubernetes?
Both are supported. Single-host installs and small sites are usually Docker; larger estates that already run Kubernetes deploy there. The deployment path is documented for either.
Who operates it after go-live, you or us?
Your team, or your integrator. Proxus is designed to be handed over: everything is a configuration object that can be inspected, changed and backed up without vendor involvement.
How is access controlled?
Users, roles and object-level permissions across configuration, live data, dashboards and API access, including permissions on namespace paths.
What does a security review usually ask for?
Transport encryption, credential handling, access model, audit trail, deployment topology and upgrade process. Ask for the deployment and security brief; we send it before the first technical call rather than after procurement.

Next step

Bring your security questionnaire.

Ask for the deployment and security brief and we send it before the first technical call. Send your questionnaire with it, and an engineer answers it against your own topology.

  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.