Skip to content
Proxus 2.0.1 Licence and sign-in fixes after the 2.0 upgrade Release notes
Try free Book a demo

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.

Book a demo Request the security brief
The hub · one command
# Linux and macOS
curl -fsSL https://proxus.io/install.sh | bash

# Windows
irm https://proxus.io/install.ps1 | iex
Screen recording: an Edge Gateway’s Install window, where it runs and the hub address, then the one-line command for the host and how long its link works.
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 an installer that backs up the configuration before every update

From one command to a connected gateway

The hub in one line, the gateways from the hub.

One command sets up the hub with Docker. Every gateway after that is installed from the hub’s own screen.

  1. Hub server The installer, run once It asks for formats, time zone and the addresses gateways use
  2. Sign in https://localhost:8443 As Admin, then set a password at once
  3. Gateway Install, from the gateway’s screen One command for a Linux host with Docker
  4. Live check Connected to this hub The window follows the install on the host

Running it

Update it, make it highly available, close it off, secure it.

Update · Linux, macOS, Windows
# The hub: back up, update, check, roll back if needed
curl -fsSL https://proxus.io/install.sh | bash -s -- update --yes

# On Windows
$env:PROXUS_COMMAND='update'; $env:PROXUS_YES='1'; irm https://proxus.io/install.ps1 | iex

Updates you can roll back

The installer backs up the configuration, pulls the new release, waits until every service is healthy and offers to roll back if one is not.

  • A gateway updates when its install runs again, and keeps its data
  • Back up and restore from the same installer
L4–L5 Enterprise and cloud L3.5 Plant DMZ L3 Operations L1–L2 Control and machines Kubernetes cluster Your systems ERP, MES, databases, cloud Hub × 2 Active-active Message server × 3 Every stream on all three Databases Replicated Edge Gateway pods One per gateway PLCs S7, EtherNet/IP Robots OPC UA Meters Modbus
  • Proxus
  • Your systems
  • Reads machines
  • Values, buffered by the sender

High availability on Kubernetes

Two copies of the hub behind the ingress, a three-node message cluster, three database instances and the historian in two replicas.

  • Plain Kubernetes manifests, applied with kubectl apply -k
  • Each gateway stays a single pod; its buffer covers a hub switchover
Air-gapped install
# On a machine with internet: save the images
docker save -o proxus-hub-images.tar $(docker compose config --images)

# On the isolated server: load them, then install
docker load -i proxus-hub-images.tar

No internet, from install to licence

Load the images from a drive and paste the licence key: the server checks it against its signature, with no call home.

  • A key works only on the installation whose License ID it was issued for
  • The AI Assistant can use a local model
The Certificate Store with the platform’s certificates. Enlarge
The Certificate Store with the platform’s certificates.

Certificates without a separate tool

A built-in certificate authority issues the hub’s and the gateways’ certificates and renews them 30 days before they expire, or you use your corporate CA.

  • HTTPS on 8443, MQTT with TLS on 8883
  • OPC UA certificates trusted or rejected in the same store

Real Proxus screens; the machine data shown is simulated.

Want to plan this for your network? Plan your install

Where it goes

Seven layouts, each with its own page.

From one server next to the machines to a group of plants on one hub: the drawing, what to install and what happens when a part fails.

All deployment scenarios
Technical details Problems it solves, every capability and the full protocol table

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

All deployment scenarios
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 the AI Assistant 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.

Proven in production

Operated by the customer, inside their own network.

All deployments

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.

Continue

Two numbers set your price: the gateways you run and the data rate they carry. See pricing

Plan your install

Where will it run?

Tell us where the hub will run, whether it can reach the internet and what your certificates need. An engineer replies within one working day.

Runs on
Internet access
Certificates

We use your email to answer this check. Marketing emails only if you tick the box; no resale. Privacy notice

Plan install Live demo