Your Ship Has Five Networks. What Should Still Work When the Cloud Disappears?
🔔 Subscribe to ShipUniverse Weekly →
When Starlink Is No Longer Enough for a Connected Ship
Starlink, OneWeb, VSAT, Iridium and 5G are turning vessel connectivity into core infrastructure. The harder decision is no longer how to get the ship online. It is deciding which systems are allowed to depend on being online.
A ship can now carry more communications capacity than some shore offices had a decade ago. But abundant bandwidth creates a new architectural risk: software that once ran independently onboard can quietly become dependent on cloud APIs, shore databases, remote support and continuous authentication.
Royal Wagenborg's fleetwide programme shows where the market is heading. Around 160 ships will use an integrated combination of Starlink, OneWeb, Ku-band VSAT, Iridium Certus and 5G, supported by common onboard IT infrastructure and cybersecurity.
The next design question sits one layer deeper. If the fast link fails, a region blocks one provider, satellite capacity degrades or the ship deliberately isolates itself during a cyber event, which applications still have to operate locally with no shore connection at all?
Shipping is moving from buying internet to designing infrastructure
How much bandwidth does the ship need?
VSAT serves business traffic, email and crew communications. Most important vessel applications remain fundamentally local.
Which network should each workload use?
Cloud applications, remote OEM support, live telemetry, crew traffic, cybersecurity and onboard analytics compete for multiple network paths.
Wagenborg is building the stack at fleet scale
One digital framework across roughly 160 ships
The programme combines communications, vessel IT and cyber controls rather than treating each as a separate project.
High-throughput broadband for cloud access, large transfers, remote work and crew traffic.
A second independent LEO path adds coverage, supplier diversity and another high-performance route.
Existing satellite infrastructure remains useful as part of a hybrid architecture rather than disappearing with LEO.
Lower-throughput L-band connectivity provides another global communications layer for critical traffic and fallback.
Terrestrial bandwidth can take over when the vessel enters suitable coastal, terminal or port coverage.
The winning architecture does not ask every network to do the same job
The cloud-versus-edge decision becomes a consequence-of-failure test
Keep it onboard when delay or outage matters
Machinery alarms should not wait for a round trip to a cloud service before the ship sees the result.
Video can be analysed locally and only events, clips or metadata transmitted ashore.
Crew should retain essential situational awareness when external connectivity fails.
Local detection remains valuable during network isolation or an incident involving shore connectivity.
Buffer sensor data locally and synchronise when a suitable link returns.
Move it ashore when fleet context matters
Comparing one ship against 100 others requires central access to normalized fleet data.
Emissions, finance, maintenance and compliance workflows often need shore-side integration.
Large historical datasets and cross-fleet model development suit central infrastructure.
OEMs, shore engineers and operations centres need shared access to selected vessel information.
Shore infrastructure can manage versioning and packages while the ship controls when they are safely deployed.
Resilience has four different layers
Fast link fails
Traffic moves from one LEO provider to the second provider or another broadband path.
Broadband degrades
Non-critical traffic is delayed while selected operational data moves over a narrower fallback connection.
External links disappear
Edge applications continue locally, data queues onboard and the crew retains essential functionality.
Network isolated deliberately
During a cyber event, the vessel may need to operate safely while shore connectivity is intentionally restricted.
Put each workload where failure hurts least
| Workload | Primary compute | Cloud role | Connectivity need | Outage tolerance |
|---|---|---|---|---|
| Engine anomaly detection | Onboard analysis. | Fleet trends, model improvement and shore diagnostics. | Moderate after event detection. | Must run offline |
| Bridge machine vision | Local video processing. | Event review, training data and fleet safety analysis. | High only if raw video leaves ship. | Must run offline |
| Remote OEM troubleshooting | Local control remains onboard. | Shore expert reviews telemetry and diagnostics. | High during session. | Graceful degradation |
| Voyage optimisation | Local voyage plan and fallback. | Weather, optimisation models and fleet operations. | Periodic updates rather than continuous dependency. | Hybrid |
| Emissions reporting | Local data collection and buffering. | Reporting, aggregation and regulatory workflow. | Delay tolerant. | Cloud leaning |
| Crew internet | Local access control. | Internet application traffic. | High bandwidth, low operational criticality. | Can stop |
| Fleet benchmarking | Minimal onboard processing. | Central comparison and analytics. | Periodic bulk synchronisation. | Cloud first |
More networks create resilience and more doors
Connectivity is now inside the security boundary
Bureau Veritas' 2026 cyber type approval of NexusWave examined onboard ICT architecture, network equipment, orchestration and managed edge infrastructure together rather than validating a modem in isolation.
The difficult part is not connecting one ship. It is keeping 160 ships identical enough to manage.
Configuration problem
A firewall policy, local application or remote-access rule has to be deployed consistently across many vessel classes, ages and hardware generations.
Connectivity domains
More paths improve availability but also create contracts, terminals, routing policies, firmware and monitoring that must be controlled fleetwide.
Operating model
The value comes when shore IT sees the fleet as one managed environment instead of 160 individually configured floating offices.
5G changes what happens when the ship gets close to shore
Satellite connectivity will remain essential offshore, but terrestrial maritime networks can become a high-capacity synchronisation zone around ports. Singapore completed Maritime 5G coverage across its major fairways, anchorages, terminals and boarding grounds in 2025 and explicitly cites remote inspections, autonomous operations, digital bunkering and other real-time applications as use cases.
That creates an architecture opportunity. A vessel does not necessarily need to transmit every large dataset continuously at sea. High-volume files, software packages, inspection video or stored sensor data can be prioritised for a terrestrial window when suitable coverage is available.
Cloud vs Edge Vessel Architecture Simulator
Select a shipboard workload and change its data volume, latency requirement, operational criticality and offline requirement. The model estimates how much processing should remain onboard, how much data needs to cross the satellite link and what network hierarchy best fits the workload.
Should this application live in the cloud, at the edge or both?
The model is intentionally architectural rather than vendor-specific. It treats bandwidth, latency, continuity, data sensitivity and fleet-value as competing design requirements.
Run the operational logic onboard and synchronise selected results and history to the cloud.
The entered workload is operationally important and must survive an external-network outage, while its fleet-wide data still has substantial shore-side value.
The connected ship is becoming a distributed computer
The first stage of maritime connectivity put email and internet aboard. The second stage gave ships enough bandwidth to behave like remote branch offices. The current stage is different: shipboard applications, edge compute, cloud services, cybersecurity and several network providers are beginning to operate as one distributed technology environment.
That makes the cloud-versus-edge decision an operational design decision. The wrong architecture can leave an application unavailable when the crew needs it most. The right one allows the ship to continue locally, reduce its data before transmission, use the best connection available and synchronise with the fleet when the network permits.
We welcome your feedback, suggestions, corrections, and ideas for enhancements.
Please click here to get in touch