The defense subcontractor's quality lead opens the twinzo demo on a laptop in the integration office. Forklift spaghetti on a 3D hall, live pins on tool cages, a no-go flash when a tug crosses a paint line. Production wants that picture on the machining floor next quarter. Then cybersecurity asks for the data-flow diagram and where packets leave the site.

‍

There is no outbound path. The plant VLAN that carries RTLS and MES traffic is isolated by policy, not by accident. Radios and shop-floor tablets are not allowed to resolve public SaaS endpoints. The project does not die because the use case is weak. It stalls because the default assumption (subscribe, authenticate, stream positions to someone else's region) does not fit a site that treats the network as part of the security boundary.

‍

That friction is normal in aviation MRO, defense manufacturing, nuclear and radiological facilities, and other critical sectors where IEC and national guidance treat industrial control and operational data as assets that should stay inside the fence. twinzo can run entirely on your LAN. Positions, history, models, and alert rules stay on VMs you operate. Operators still open the same browser and phone apps. The change is who runs the servers and who issues the certificates, not whether the floor gets a live twin.

‍

In a line-maintenance hangar, the job is not abstract visibility. Tooling carts must sit outside engine intake zones. A stand or ladder parked wrong is a foreign-object risk before anyone reads a work package. Supervisors already walk the tail line with clipboards because the WMS does not show where the hydraulic cart actually is.

‍

Hangar IT often mirrors airport security practice: operational Wi-Fi and RTLS live on a segment that never routes to the internet. Tablets may be managed devices with no store access. A cloud-only twin is a non-starter even when leadership likes the 3D view in the pilot room.

‍

On-premise twinzo puts the hangar mesh, stands, and tagged carts on one map served from inside the fence. Airport and hangar operations that already separate public terminals from maintenance zones use the same pattern: local DNS name, HTTPS to your own reverse proxy, BLE or UWB anchors on the maintenance VLAN. When a tug enters a no-go around an open cowling, the alert goes to the duty supervisor's phone on that VLAN, not through a third-party notification relay in another country.

‍

Typical moment: night shift finds a missing torque cart. Instead of paging every bay, maintenance opens the twin, sees the last RTLS position against the aircraft silhouette, and sends one tech. The search time is what MRO benchmarks care about, and it does not require opening the perimeter.

‍

On a defense manufacturing line, intralogistics is where capacity hides. Armor kits, propellant-adjacent components, and classified-adjacent hardware move on forklifts and AGV loops that rarely get the same integration budget as the CNC row. Planners still argue from static layout PDFs while drivers know the real choke point is the corridor past the inspection cage.

‍

Those halls are exactly where export-control and facility security reviews ask for data residency. Live coordinates of people and material are operational intelligence. Streaming them to an external multitenant platform triggers paperwork that production timelines cannot absorb. European rearmament has put more pressure on throughput without relaxing those reviews, and intralogistics on the defense floor is treated as a front line for that reason.

‍

Local twinzo keeps forklift loops, dwell at kitting buffers, and congestion past secure doors inside the same reporting boundary as MES and SCADA. Logistics optimization on the 3D twin (spaghetti paths, heat by aisle, compare shifts) runs against history stored in your InfluxDB instance, not an external analytics tenant. Security signs off because the architecture is two VMs on the plant LAN, not a new egress exception per feature.

‍

Outside commercial nuclear plants and radiological labs, contamination control is spatial. Technicians carry dosimeters and route cards. Some corridors are stay-out unless work orders say otherwise. When someone is down or unresponsive, security does not get a vague radio call from "somewhere in B block." They need a position on a map that matches the posted zone plan the regulator already approved.

‍

Those sites often prohibit consumer cloud services on operational networks entirely. Even when RTLS tags are approved, the back end must live beside other plant systems (historian, alarm server, badge) on hardened Linux or Windows hosts maintained by site IT.

‍

On-premise twinzo maps tagged workers and contractors on the hall model, ties man-down detection with live RTLS position to the same coordinates, and fires no-go entry rules when a tag crosses a radiological control boundary drawn on the twin. The MQTT stream from anchors to the application server stays on TCP 1883 inside the services VM. Nothing in that path requires a DNS lookup of a public API.

‍

Typical moment: an alarm panel shows elevated dose in a corridor. The control room opens the twin, sees which tagged teams were in adjacent zones in the last ten minutes, and directs recall without sending runners through the whole building. The map is authoritative because it is fed locally and stored locally.

‍

Some vendors offer "on-premise" as an edge cache that still phones home for licenses or identity. twinzo's on-premise deployment is the full application stack on your hardware. Web clients, mobile apps, desktop clients, and sensor gateways talk HTTPS to your application server. API, reporting, real-time positions, 3D assets, notification rules, and analytics queries are served from that environment.

‍

Day-to-day operation does not depend on internet reachability. Patch and upgrade bundles are delivered through your change process (USB from vendor media, internal artifact repository, or a one-time maintenance window with a controlled egress), the same way you already ship OS updates to other plant servers. Runtime traffic between shifts does not need that path.

‍

That distinction matters when production asks for 24/7 twin availability next to a line that cannot stop because a SaaS region is down or because a carrier cut the only outbound link. The twin is infrastructure, not a website operators hope stays up.

‍

For a capability map across models, simulate, analytics, and alerts, all available in this deployment model, see twinzo features.

‍

The reference layout splits work across two Linux VMs on your plant network. One hosts the application tier. One hosts data and messaging services. Clients never touch the databases directly. They hit TLS on the application VM, and the .NET services open the backend ports on the services VM.

‍

Application VM: Nginx terminates HTTPS on ports 443 and optional HTTP on 80 for redirects. It reverse-proxies to twinzo's .NET 10 API on port 5290 and the .NET 10 Reporting service on port 5039. Browsers, phones, and desktop apps only need to trust your site certificate and resolve your internal hostname.

‍

Services VM: InfluxDB on 8086 for time-series position and sensor history, Microsoft SQL Server on 1433 for transactional data, Valkey on 6379 for cache and fast state, and Mosquitto MQTT on 1883 for live tag and device streams. Both .NET services connect to all four backends over the private link between VMs.

‍

Firewall rules are predictable: clients to Nginx 443, application VM to services VM on 8086, 1433, 6379, and 1883. No rule needs "anywhere on the internet" for normal operations.

‍

On-premise twinzo is not a appliance you plug in and forget. It is standard Linux services your team already runs for historians, MES bridges, or identity-adjacent tools. Before production cutover, confirm the site can own the following.

‍

• Two Linux VMs: sized for your tag count, retention, and reporting load. Application and services roles can sit on separate hosts for isolation and backup, or on two VMs in the same rack you already use for plant systems.

• OS lifecycle: patching, time sync, disk monitoring, and backup of MSSQL and Influx volumes. Restore drills should include the twin if production relies on it for shift planning.

• Network: VLAN placement so RTLS gateways, operator Wi-Fi, and engineering workstations can reach the Nginx hostname without crossing untrusted segments. MQTT publishers must route to the services VM broker.

• Monitoring: health checks on Nginx, both .NET processes, database services, and disk growth on history stores. Alert your NOC when the API is down, not when operators complain at the shift meeting.

‍

If you do not have a team that administers Linux VMs and MSSQL today, plan headcount or a managed-service partner inside your security boundary before you promise the floor a go-live date.

‍

Operators should bookmark something like twinzo.plant.local, not memorize IP addresses that change after a VM migration. Your DNS team publishes an internal A or CNAME record that points to the application VM's address on the operator VLAN. Engineering laptops on a separate VLAN get the same name if policy allows, or a dedicated admin name on a tighter segment.

‍

TLS is non-negotiable for browser and mobile clients. Issue a certificate from your enterprise CA, the same chain you already deploy to shop-floor tablets, or use a documented internal procedure your cybersecurity group accepts. Nginx presents that cert on 443. Clients must trust the root. Managed devices often need the CA bundle pushed through your MDM before the twin loads without warnings.

‍

Certificate renewal is where air-gapped sites stumble. Put twinzo hostnames on the same renewal calendar as other plant HTTPS services. A expired cert does not stop RTLS tags from blinking on gateways, but it stops supervisors from opening the map at 2 a.m. when they need it.

‍

Sensor devices and desktop apps that pin hostnames should use the same internal DNS name you publish to humans. Split horizons (one name inside, none outside) are fine. There is no requirement for a public DNS record.

‍

Isolation changes hosting, not the jobs operators already recognize. Tagged forklifts still draw spaghetti on the hall mesh. Placed assets (supplier trucks without tags, critical WIP pins) still sit in 3D next to live devices. Area occurrence still answers which zones a run used and how long it dwelled. No-go rules still notify when a tag or simulated path crosses a line production drew on the twin.

‍

Correlating plant systems by space works the same when OPC, MES, or Ignition tags land on the local API. HighByte or a direct OPC bridge on the plant LAN pushes machine state beside RTLS without leaving the site. Analytics and reporting services read the same Influx history whether the cluster runs in your rack or in a vendor cloud. The queries are identical, the egress policy is not.

‍

If you are new to anchor placement and tag types, pair the deployment project with getting started with RTLS on a pilot hall before you scale VLAN rules plant-wide.

‍

Clear ownership prevents the twin from becoming an orphan system after go-live.

‍

Plant IT: VMs, backups, DNS, certificates, firewall rules between application and services tiers, MQTT and SQL connectivity, patch windows.

OT / automation: RTLS gateways, anchor surveys, integration with SCADA or MES tags, VLANs for shop-floor devices.

Operations: zone definitions, no-go rules, who receives alerts, which halls are in scope each shift.

Security / compliance: sign-off on architecture diagrams, data retention, and whether reporting exports may leave the enclave on removable media.

‍

Typical failure mode: IT installs the VMs but nobody in production owns zone geometry. Supervisors open an empty map with perfect HTTPS. The fix is not another firewall rule. It is operations drawing docks, buffers, and restricted lanes on the twin the same way they would on a whiteboard before a holiday rush.

‍

A practical sequence that fits change-advisory habits on critical sites:

‍

1. Architecture review: agree on two VMs, VLAN placement, and port matrix with cybersecurity before hardware is ordered.

2. Services VM: install MSSQL, InfluxDB, Valkey, and Mosquitto. Restore from twinzo deployment packages. Confirm inter-VM connectivity from a jump host.

3. Application VM: install Nginx and twinzo .NET API and Reporting services. Point upstream config at the services VM addresses.

4. DNS and TLS: publish internal hostname, deploy cert chain, verify from a representative shop-floor tablet and an engineering laptop.

5. Pilot hall: one hall, limited tags, operators validate map fidelity and alert latency on the local URL.

6. Integrations: OPC, MES, or ERP read-only feeds on the same LAN segment as the API.

7. Production cutover: expand VLAN access, train shift leads, add monitoring dashboards to the NOC.

‍

twinzo supplies deployment artifacts and versioned upgrades. Your team runs install, backup, and rollback like any other plant system.

‍

Sites that choose on-premise twinzo often share the same pattern: operational data must not leave, but the floor still needs a spatial picture:

‍

• Semiconductor fabs: cleanroom routes and tool carts on a segment with no outbound DNS.

• Government research labs: shared equipment booking plus live position in restricted corridors.

• Pharmaceutical sterile cores: gowning and material airlocks modeled with no-go enforcement.

• Remote mining or energy camps: satellite is for email, not per-tag streaming. Local servers keep the processing plant map alive when the link drops.

• Shipyard assembly halls: heavy plate and crane zones where visitor and contractor tags must stay visible without cloud accounts.

‍

In each case the question is the same: can your IT operate two Linux VMs, internal DNS, and site TLS? If yes, the use cases above are addressable without reopening the perimeter.

‍

Critical-sector projects fail quietly when the twin is sold as SaaS-only. They move when cybersecurity sees a diagram with two VMs, internal HTTPS, and no standing egress. Operators still get the hall they recognize, with live tags and rules that match how they already run docks, buffers, and restricted lanes.

‍

Start with architecture review and a single pilot hall on your LAN. Confirm DNS, certificates, and MQTT paths before you promise plant-wide spaghetti and man-down coverage.

‍

Get in touch if you want an on-premise reference diagram and a walkthrough on your facility model inside an isolated network.

‍