Deployment

Consystence is not a single box. It is a layered system whose pieces run wherever the connectivity, data-sovereignty, and control requirements put them — from a multi-tenant cloud cell down to a controller on a process-control network with no internet at all. This page maps those layers and the way they are deployed; the sub-pages cover each target in detail.

Beta — not intended for production use

Consystence is in public beta. Use it for evaluation, authoring, simulation and supervised commissioning trials alongside your existing SCADA — production control stays on your existing system. Deterministic controller logic and hardwired safety systems hold final authority over physical outputs regardless.

The deployment model

The runtime spans three tiers, with a thin control plane provisioning tenants above them and the plant’s controllers below:

• Browser — the server-driven UI, delivered over SignalR. No SPA framework ships; the browser renders a semantic UI tree.
• Server — the tenant runtime. One codebase, published as two mode-baked artifacts: a Cloud-baked image runs as a multi-tenant cell in the cloud, and a Site-baked artifact runs as an on-prem site server.
• Edge runtime (optional) — consystence-edge, a .NET 10 single-silo Orleans process at the site that reads the controllers and buffers store-and-forward (SQLite), streaming to the site server over gRPC (HTTP/2). In our workshop it runs on an Nvidia Jetson Orin. The Phoenix Contact PLCnext VL3 is a target platform for it, and we are proving the edge runtime for the VL3 on a Linux container in our workshop.

Controllers are read by the site server (ControlLogix, early access) or through an optional edge. The site server reads a ControlLogix directly, read-only, without an edge. This is in early access: our engineers enable it per controller, and it has run at a site trial since 28 October 2026. Off by default. A PLCnext is read through an edge. Production control stays on your existing control system. For Consystence-managed equipment, a PLCnext border gateway is an accepted target topology; it is one option, not a requirement (see below).

Above the tiers, the account control plane (account.consystence.com, with id.consystence.com as the Entra External ID identity provider) provisions tenants into cells and routes each tenant’s subdomain to the cell that owns it.

Public beta

The hosted service is in public beta. During the beta, free individual sandboxes and paid organisations are both arranged with our team: request access. Today’s production is a single managed cloud cell — a multi-silo Orleans cluster on Kubernetes serving subdomain-routed tenants, enrolled with the control plane; treat the independent multi-cell topology below as the target architecture at fleet scale.

flowchart TB
  BROWSER["Browser<br/>server-driven UI over SignalR"]
  subgraph CP["Account control plane"]
    ACC["account.consystence.com<br/>directory + routing + signup"]
    IDP["id.consystence.com<br/>Entra External ID (CIAM)"]
  end
  subgraph SERVER["Server — one codebase, two baked artifacts"]
    CELL["Cell (Cloud artifact)<br/>Orleans + PostgreSQL 16 + historian<br/>serves {slug}.consystence.com"]
    SITE["On-prem site server<br/>Site artifact"]
  end
  EDGE["consystence-edge<br/>.NET 10 Orleans, store-and-forward"]
  CTRL["Controllers<br/>ControlLogix · PLCnext"]
  GW["PLCnext border gateway<br/>target topology"]
  FIELD["Field devices<br/>IO racks, VFDs, relays"]
  BROWSER --> SERVER
  CP -->|provisions tenants into cells| CELL
  EDGE -.->|"gRPC (planned)"| CELL
  SITE -->|gRPC| EDGE
  EDGE -->|"EtherNet/IP CIP · gRPC (GDS)"| CTRL
  SITE -->|direct read| CTRL
  CTRL --> FIELD
  EDGE -.->|gRPC| GW
  GW -.->|CIP / EtherNet/IP| FIELD

One codebase, two baked server modes

The server is a single codebase, but its mode is baked into each published artifact at build time and is never read from configuration — a Server:Mode config or env entry is inert:

Mode	Role	Artifact	Where it runs
Cloud	Multi-tenant cell — provisioning, admin, multi-tenant runtime	Cloud-baked container image, privately held	Managed Kubernetes (multi-silo Orleans cluster)
Site	Single-tenant on-prem server, activated against the cloud or provisioned standalone	Site-baked artifact	Customer hardware / on-prem VM

The mode is immutable at runtime and fail-closed: a build with no mode baked in runs as Site, and a Site artifact cannot be reconfigured into a Cloud one — cloud-only endpoints simply return 404 on a Site binary. Baking the mode at build time deliberately ends any “same image, config-selected mode” behaviour, so a Site deployment can never be turned into a Cloud one. See Org and site model for how a tenant, its subdomain, and its sites relate — a site is a path under the tenant subdomain (/sites/{code}), never its own TLD.

Cells

A cell is a self-contained unit: its own Orleans cluster, PostgreSQL 16, and historian, bound to the tenants it hosts. The platform scales by adding cells rather than growing one cluster, and a tenant never spans more than one cell. The cloud cell host itself is never surfaced to users; customers only ever see their tenant subdomain ({slug}.consystence.com or {slug}.consystence.dev), which DNS routes to the owning cell. The full design — invariants, routing, and the sandbox/enterprise split — lives in Cell topology and the wider architecture overview.

On-prem site servers

Mining and processing sites have intermittent or absent connectivity, so a site server must keep running on its own. An on-prem site server runs the Site-baked artifact, holds cached configuration and a local store, and degrades gracefully when the cloud is unreachable. Activation and licensing follow the licensing model, which is degrade-not-kill and never gates operator control writes, even fully offline. See On-prem deployment for the install and activation flow. Site-server deployments are arranged with our team during the beta; contact us.

Not every deployment includes every tier. A hosted tenant may run with no on-prem server and no edge, and an air-gapped site runs without the cloud. Read the topology as a spectrum, not a fixed stack that must be deployed in full everywhere.

Edge and the PLCnext border gateway

The edge runtime runs at the plant, next to the controllers. It reads a Rockwell ControlLogix over EtherNet/IP CIP and a Phoenix Contact PLCnext over gRPC (GDS), on one shared driver layer, and one edge can connect to both. Modbus TCP and OPC UA runtime drivers are roadmap. The edge is designed to sit at the IT/OT boundary; Network security gives a reference policy for the edge host.

Where Consystence manages the control equipment, the PLCnext border gateway is an accepted target topology, demonstrated in our workshop on a virtual PLCnext. The PLCnext runs the control logic and keeps the field network behind it, speaking CIP / EtherNet/IP to the field, and the edge reads the PLCnext’s process variables over gRPC. Detail lives in Edge runtime and PLC communication.

AI is advisory-only

The platform’s AI reads, explains and recommends; it never commands equipment. Hard interlocks are enforced at the plant, in deterministic controller logic and hardwired safety relays — never in a model. On-edge ML inference is roadmap, not shipped — nothing on the edge runs TensorRT/ONNX today.

How it is deployed

Target	Mechanism	Detail
Cloud (cells / server)	Cloud-baked container image on a managed Kubernetes cluster (multi-silo Orleans)	Cloud deployment
On-prem site server	Site-baked artifact, activated against the cloud or provisioned standalone	On-prem deployment
Edge	consystence-edge on a Linux edge host as a systemd service (a Jetson Orin in our workshop; the PLCnext VL3 is a target platform)	Edge deployment
AI cell	Stateless per-region advisory gateway for the two cloud tiers — a non-apex tier (grounded advisory) and an apex reasoning tier (tool-grounded) — see Trust; a site-local tier is roadmap. Since 26 October 2026, advisory AI requests have been processed outside Australia, a temporary exception to our in-Australia inference rule.	Advisory-only

Each cloud data cell runs as a multi-silo Orleans cluster on managed Kubernetes, provisioned from infrastructure-as-code. The stateless AI cell is the exception, running as a lightweight container service.

Next steps

• Cloud deployment — the managed multi-tenant cloud
• On-prem deployment — site-server install and activation
• Edge deployment — running consystence-edge beside your controllers
• Cell topology — the cell + control-plane design
• Licensing — tiers, seat pools, and offline degrade-not-kill