Cloud is the default starting point
Most plants open their Industry 4.0 digital-twin journey in the public cloud. Automatic processing of .fbx and .obj files gets the 3D model running quickly. Push notifications keep supervisors and logistics teams updated without extra steps. The platform acts as an umbrella layer that ingests live data from RTLS, MES, ERP, WMS and SCADA systems. Early pilots stay short—often a few weeks—and the focus stays on seeing forklifts, people and materials in one spatial view.
At that stage security and latency requirements are still flexible. Data can sit in a managed environment and response times feel good enough for the first use cases.
When the requirements harden
The picture changes once the operational twin is no longer a pilot. Security teams begin insisting on OT/IT segmentation, full audit logging and clear control over where location and production data live. Certain logistics or safety workflows start demanding lower and more predictable latency. Defense, critical infrastructure and some regulated manufacturing sites hit this wall earlier than others.
Twinzo supports public cloud, private cloud, fully on-premises and hybrid deployments. The fully on-premises option runs on Ubuntu 24.04 LTS with Docker. That path becomes visible only after the plant has already invested time in connecting data streams and building daily habits around the live 3D map.
The concrete features that disappear on-premises
Moving to a fully on-premises installation removes two capabilities that felt automatic in the cloud. Automatic 3D processing of .fbx and .obj files is no longer available. Models still load, but the pipeline that handled conversion without manual intervention is gone. Push notifications also stop. Status updates that previously arrived on phones or tablets now require a different delivery method.
These are not abstract limitations. They surface as real daily friction only after teams have already grown used to them. Early conversations rarely list them because the first priority is simply getting visibility. Once security or latency rules harden, the same teams discover they must trade those conveniences for control of the infrastructure.
Why plants accept the trade-off later rather than sooner
In the opening months the goal is speed and breadth of data. A plant wants to see material flow, forklift routes and people movement without rewriting existing systems. The cloud model delivers that fast. Only after the spatial dataset is live and people rely on it for shift decisions do the harder constraints appear. By then the operational value is already proven, so the loss of automatic 3D processing and push notifications becomes an acceptable cost of meeting the new security or latency bar.
Hybrid configurations often bridge the gap. Critical data streams or sites move on-premises while other sites or non-sensitive streams stay in the cloud. The same data-point licensing and API surface continue to work. The journey does not restart; only the hosting model shifts at the point where requirements have actually hardened.
Keeping the decision practical
Treat the on-premises versus cloud choice as a mid-journey checkpoint rather than a day-one architecture debate. Document which use cases truly need local control or lower latency. Confirm whether the loss of automatic 3D processing and push notifications is tolerable for those specific flows. Then decide which parts of the twin stay in the cloud and which move. The platform already supports the full range of options; the timing of the decision is what determines whether the plant keeps momentum or has to rework earlier choices.