ALLINLET Enterprise

ALLINLET Enterprise is the option for organisations that need the integration platform to run inside infrastructure they control: an on-premises data centre, a private cloud tenancy or a segregated operational network. The architecture below is a target that is validated with each customer before production use.

When self-hosting makes sense

Utilities, hospitals, airports, defence suppliers and banks often have rules that keep operational or personal data inside a defined boundary. Some sites have no permitted internet path at all. In those cases the platform is installed close to the sources, and only agreed, aggregated outputs are allowed to cross to corporate or external systems.

Enterprise uses the same connector model, normalisation rules and record format as Cloud, so a project can start in one environment and move to the other without redefining every source.

Target architecture

The intended deployment consists of the application services, a relational database for configuration and observations, and connector workers that reach sources over the local network. It is designed to sit in a DMZ or operations zone between the plant network and the business network, following a zoned model such as the one described in IEC 62443. Identity can be linked to your existing directory where the project requires it.

Sizing, high availability, backup and patching responsibilities are agreed in the project. Because the infrastructure is yours, availability depends on both parties; we do not state a standard uptime figure, certification or licence price on this site.

Prerequisites

  • Host capacity (virtual machines or a container platform) approved by your infrastructure team.
  • Firewall rules from the integration zone to each source, documented per port and protocol.
  • A database service or storage for the bundled database, with a backup policy.
  • Certificates from your PKI for TLS endpoints and, where used, OPC UA or MQTT client authentication.
  • An operations contact for upgrades and incident handling.

Data handling inside your boundary

Records keep source identifiers, units, source and receive timestamps, and quality flags. Retention is configured locally. Exports to data lakes or analytical tools are explicit, so it is visible which data leaves the zone and in what form.

Limitations

  • Not every catalogue connector has been implemented or validated; each is confirmed during scoping, and some require a gateway or a vendor licence on your side.
  • Air-gapped installation, signed offline update bundles and an installable edge agent are not currently delivered; updates are planned with your team.
  • The platform reads and normalises data. It does not write setpoints to controllers and is not a safety system.
  • Customer infrastructure performance and network design directly affect throughput.

Next steps

Share your network zoning and a list of priority sources. We can then propose a deployment layout and a validation plan for the first connectors.

Further reading

Catalogue listings describe possible integration paths. Implementation and validation status is confirmed for each source during project scoping; no certification, service level or price is implied by this page.

Plan your data integration

Share your devices, protocols and network constraints, and we will propose a first validated connection.

Related pages