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 and simulation, and commissioning trials alongside your existing SCADA — production control stays on your existing systems until the beta label comes off. Deterministic controller logic and hardwired safety systems hold final authority over physical outputs regardless.

The deployment model

The runtime spans four tiers, with a thin control plane provisioning tenants above them:

• Browser — the server-driven UI, delivered over SignalR. No SPA framework ships; the browser renders a semantic UI tree.
• Server — the organisation 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 — consystence-edge, a .NET 10 single-silo Orleans process at the site, with store-and-forward buffering (SQLite) over gRPC (HTTP/2) and an IT/OT firewall boundary. It runs on PLCnext control hardware (VL3) or an Nvidia Orin variant.
• PLCnext border gateway — the primary path to the field. The edge reads and writes PLCnext GDS/PORT variables over gRPC-over-UDS; the gateway speaks CIP / EtherNet/IP to field devices (IO racks, VFDs, protection relays).

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

Not yet generally available

The account control plane, billing, and the tier/seat pools run in production behind launch gates — new tenants wait on operator approval, and self-serve signup is not yet GA. 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 (ServerMode.Cloud)<br/>Orleans + PostgreSQL 16 + historian<br/>serves {slug}.consystence.com"]
    SITE["On-prem site server<br/>ServerMode.Site"]
  end
  EDGE["consystence-edge<br/>.NET 10 Orleans, store-and-forward"]
  GW["PLCnext border gateway<br/>CSY library"]
  FIELD["Field devices<br/>IO racks, VFDs, relays"]
  BROWSER --> SERVER
  CP -->|provisions orgs into cells| CELL
  CELL -. gRPC .-> EDGE
  SITE -. gRPC .-> EDGE
  EDGE -->|gRPC-over-UDS, GDS/PORT vars| GW
  GW -->|CIP / EtherNet/IP| FIELD

One codebase, two baked server modes

The server is a single codebase, but its ServerMode is baked into each published artifact at build time (-p:DeploymentMode=Site|Cloud stamps an assembly attribute; the mode is never read from configuration — a Server:Mode config or env entry is inert):

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

The mode is immutable at runtime and fail-closed: an unstamped build boots 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 an organisation, its subdomain, and its sites relate — a site is a path under the org 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 {slug}.consystence.com org subdomain, 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 ongoing licence enforcement 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.

Not every deployment includes every tier. A cloud-only sandbox tenant may run with no on-prem server and a simulated controller pool; a site server can run with no edge if a controller is reached another way; 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 sits on the OT side of the IT/OT firewall and is the component that actually talks to control hardware. Its primary path is the PLCnext border gateway: the edge reads and writes PLCnext GDS/PORT variables over gRPC-over-UDS, and the gateway speaks CIP / EtherNet/IP to the field. The driver layer sits behind a common driver abstraction (PLCnext-gRPC, EtherNet/IP, Modbus TCP, or a simulator stub); the direct native drivers are the supported interop path for third-party and legacy controllers — prefer the gateway for Consystence-managed equipment. Detail lives in Edge runtime and PLC communication.

AI is advisory-only

The platform’s AI configures, queries, classifies, and explains; it never commands equipment. Hard interlocks live in IO modules and safety relays, not in software. 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	On-prem deployment
Edge + gateway	consystence-edge on PLCnext (VL3) or Orin; systemd-managed	Edge deployment
AI cell	Stateless per-region inference gateway; the advisory plane is tiered — a grounded floor tier, a tool-augmented mid tier, and an apex reasoning tier — each pinned to in-region inference	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 against a PLCnext gateway
• Cell topology — the cell + control-plane design
• Licensing — tiers, seat pools, and offline degrade-not-kill