Cloud is the default starting point
When you stand up an operational digital twin, start in the public cloud unless security or latency already force a harder host. Revisit on-prem or private hosting only after those requirements are proven, not assumed.
Why public cloud is the usual first host
Cloud computing shortens the first pilot proof under Industry 4.0 programs. Managed hosting removes rack, patch, and capacity work from the pilot team. Automatic processing of .fbx and .obj mesh files gets the facility model online without a local conversion pipeline. Push notifications keep supervisors and logistics leads updated without a separate delivery stack. The same twin platform can ingest live streams from a real-time location system (RTLS), MES, ERP, WMS, and SCADA while the plant learns whether one spatial view is trusted.
Early windows stay short, often a few weeks on a bounded zone. The job is seeing forklifts, people, and materials on one hall people recognize, not finishing a permanent architecture debate. Security and latency tolerances are still flexible at that stage. Response times that feel good enough for search, fleet load, and shift confirmation are enough to pass a pilot. How the disconnected baseline and that first pilot proof sit in sequence is covered in the starting point is still a collection of disconnected systems.
When hosting requirements harden
Once the twin is no longer a pilot, IT/OT and cybersecurity owners often tighten the rules. They ask for clearer network segmentation, fuller audit logging, and explicit control over where location and production data live. Some logistics or safety workflows need lower and more predictable latency than a public path comfortably guarantees. Defense, critical infrastructure, and some regulated manufacturing sites hit that wall earlier than general discrete plants.
Industry guidance on cloud in OT environments makes the same split. Time-sensitive and connectivity-critical work tends to stay local or at the edge. Broader analytics, multi-site history, and elastic compute stay comfortable in the cloud. twinzo supports public cloud, private cloud, fully on-premise, and hybrid cloud deployments. The fully on-premise path runs on Ubuntu 24.04 LTS with Docker. That path becomes visible after the plant has already connected feeds and built daily habits around the live 3D map, not as a day-one architecture fight.
What full on-premise drops
A full move to on-premise 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 managed conversion pipeline that handled preparation without local intervention is gone. Push notifications also stop. Status updates that previously arrived on phones or tablets need a different delivery method the plant owns.
Those are concrete daily frictions, not abstract feature labels. Teams discover them after they have already relied on managed conversion and mobile alerts. Early conversations rarely list them because the first priority is visibility. Once security or latency rules harden, the same teams trade those conveniences for control of the infrastructure. Document that trade before anyone promises that on-premise is a feature-identical copy of the cloud tenant.
Why hybrid often lands in the middle
In the opening months the goal is speed and breadth of data. The plant wants material flow, forklift routes, and people movement without rewriting existing systems of record. Public cloud delivers that fast. Only after the spatially oriented dataset is live, and people rely on it for shift decisions and later correlation and causality analytics, do the harder constraints usually appear. By then operational value is already proven, so losing automatic mesh processing and push notifications can be an acceptable cost of meeting the new bar.
Hybrid configurations often bridge the gap. Critical streams or sites move on-premise 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. Live logistics, the stored place-and-time record, and hall-wide pattern work remain equal reasons to keep the twin honest under any host. Multi-site management cost sits under what multi-hall twin visibility costs and what it buys management when several buildings share one program.
How teams decide hosting without stalling the pilot
1. Start cloud unless a hard rule already forbids it - Prove the hall view first. Treat final hosting as a mid-journey checkpoint.
2. Name the trigger that forces a move - Data residency, OT segmentation, audit scope, or a latency class the public path cannot meet. Vague discomfort is not a trigger.
3. Price the feature trade, not only the rack - Confirm whether loss of automatic .fbx / .obj processing and push notifications is tolerable for the workflows that must stay local.
4. Prefer hybrid when only some streams are constrained - Keep elastic history and non-critical sites in the cloud. Move the streams that own the hard rule.
twinzo keeps the same ingest surface and hall view across those hosts so internal logistics and production monitoring do not restart when hosting changes. Capability depth sits on the features overview. How a rollout is priced sits under pricing. Get in touch if you want to map which of your streams must stay local and which can keep the cloud conveniences the pilot already proved.