Skip to content

Deployment Model

NTWIST products are deployed on customer-managed infrastructure. This section describes the standard topology, hosting options, and operating models we support.

Where NTWIST products run

NTWIST products are designed for on-premises or customer-managed private cloud deployment. The deployment lives inside the customer's network. Process data, recipes, and operating models stay with the customer.

We support three hosting patterns:

Pattern Where it runs When it makes sense
On-premises Customer data center or plant gateway hardware Default for plants and mines with strict data residency or limited connectivity
Customer-managed private cloud Customer-controlled tenancy in Azure, AWS, or GCP Multi-site customers with mature cloud operations
Air-gapped Customer network with no outbound internet connectivity Highest-security environments

NTWIST does not operate a public multi-tenant SaaS. Each deployment is dedicated to a single customer.

Standard footprint

A typical single-site deployment includes:

  • Application tier. One or more Linux or Windows hosts running the shared NTWIST platform services (identity, ingestion, time-series storage, dashboards, alerting) and the deployed MineMax or Nexus iMES applications.
  • Database tier. A dedicated database tier for transactional and time-series storage. We support PostgreSQL, MongoDB, and managed equivalents.
  • Gateway tier. One or more plant gateway hosts handling ingestion from PLCs, SCADA, historians, and equipment.
  • Optional reporting node. A dedicated host for heavier analytical and reporting workloads.

For small sites, the application and gateway tiers may be co-located. For multi-product or high-availability deployments, the tiers are separated, with optional clustering for HA.

High availability and disaster recovery

The Platform supports clustered deployment patterns. For most customers, the appropriate HA strategy is determined during deployment design and reflects the operational criticality of the workload. Typical patterns:

  • Single-node with cold standby. Suitable for advisory products that are not in the operator's critical path.
  • Clustered active-passive. Suitable for products whose unavailability would directly affect operations.
  • Geographic disaster recovery. Offered where the customer has multi-site infrastructure.

Backups, restore runbooks, and DR tabletop exercises are part of the standard onboarding.

Operating model

Customers operate the deployment in one of two ways:

  • Customer-managed. Customer IT operates the Platform with NTWIST support. NTWIST provides support runbooks, release notes, and direct customer success engagement.
  • NTWIST-managed. NTWIST customer success engineering operates the Platform on the customer's infrastructure. Access is mediated by a zero-trust gateway, requires multi-factor authentication, and is fully logged. See Access Controls.

The choice of operating model is independent of where the deployment runs.

Updates

Product updates are delivered as signed bundles, applied during planned maintenance windows agreed with the customer. Air-gapped customers receive offline update bundles.

Sizing

Deployment sizing is determined during the kickoff phase. The variables that drive sizing are:

  • Number of products deployed.
  • Tag count, sample rate, and historical depth of the time-series workload.
  • Number of users and concurrent dashboard sessions.
  • Analytical workload (planning, reconciliation, modelling).

A typical first-product deployment runs comfortably on hardware in the range of 16 to 64 vCPUs and 64 to 256 GB RAM across the tiers, with appropriate disk for the time-series volume.