Shipwizeshipwize
offline-communicationcompliance

Why Ship Communication Should Not Run in the Cloud

Shipwize5 min read

Cloud Is Excellent — for Land

Cloud infrastructure is a remarkable engineering achievement. Elastic scaling, global distribution, 99.99% uptime SLAs, automatic failover across data centres. For applications where the users are always connected to a reliable internet connection, cloud is often the right architecture.

For maritime communication, "always connected to reliable internet" is not a design assumption that holds. The argument for vessel-local communication infrastructure isn't anti-cloud dogma. It's a consequence of the operating environment.

Latency Alone Changes the User Experience

A Matrix message sent from a crew member's phone to the Matrix homeserver running on the vessel server takes approximately 5 milliseconds round trip over WiFi.

The same message, routed through a cloud-based Matrix server over satellite, takes:

  • WiFi to VSAT terminal: 5 ms
  • VSAT round trip (geostationary): 550–700 ms
  • Cloud processing: 5–20 ms
  • Return journey: same
Total: 560–730 ms per message. This is perceptible delay on every interaction: typing indicators lag, push notifications arrive late, group chat message order gets confused.

For a push notification during an emergency response, 700 ms is acceptable. For the routine communication experience that determines whether crew actually adopt and use the platform, it's enough friction to send people back to WhatsApp.

Connectivity: The Obvious Point

At sea, beyond coastal mobile network coverage, internet access requires satellite connectivity. The availability of that connectivity varies:

  • VSAT (geostationary): Good throughput but coverage gaps at high latitudes, during extreme weather, and at satellite handoff
  • Iridium/Inmarsat: Near-global coverage but limited bandwidth (10–800 kbps)
  • Starlink maritime: Improving coverage and throughput, but still subject to outages
A cloud-dependent communication platform is unavailable during connectivity outages. These outages don't happen on convenient schedules. They happen in bad weather. They happen during the high-latitude passages where emergency risk is elevated. They happen when you most need reliable communication.

Data Sovereignty and Flag State Compliance

When all crew communications route through a cloud server operated by a commercial vendor, those communications are subject to:

  • The vendor's data retention policies
  • The legal jurisdiction of the server location
  • The vendor's access policies (for law enforcement, for operational staff)
  • The vendor's business continuity (if the vendor ceases operations, what happens to your data?)
For EU-flag vessels or operators subject to GDPR, routing crew personal communications through US-based cloud infrastructure creates data transfer compliance questions under GDPR Article 46.

On-vessel storage eliminates these concerns by design. Data stays on the vessel until you choose to sync it to your own shore infrastructure.

Bandwidth Cost

VSAT bandwidth is metered and expensive. Routing all crew communications (messaging, push notifications, call signalling) through cloud servers consumes satellite bandwidth for traffic that could run entirely over the local vessel network.

An on-vessel communication platform uses satellite bandwidth only for:

  • Vessel-to-shore voice/video calls
  • Vessel-to-shore message synchronisation
On-vessel crew-to-crew communication uses zero satellite bandwidth. On a fleet with 200 active vessels, this is a significant operational cost difference.

The Counterargument: Management Overhead

The standard argument for cloud infrastructure is reduced management overhead. You don't have to maintain servers; the vendor does it.

This is a legitimate consideration. On-vessel servers require:

  • Physical maintenance (cleaning, hardware replacement)
  • Software updates (applied during maintenance windows)
  • Monitoring (anomaly alerts when something goes wrong)
  • Backup verification (periodic restore tests)
But this overhead is manageable and well-understood by maritime IT teams. The vessel already runs servers for navigation, CCTV, and other systems. Adding the communication platform server to the maintenance regime is incremental work, not new capability.

Against the reliability, latency, and compliance advantages of on-vessel infrastructure, the management overhead argument is relatively weak for operators with any IT capability at all.

The Hybrid Model

The practical architecture for maritime communication isn't "all cloud" or "no cloud." It's:

  • On-vessel: All operational communication, all crew-to-crew messages, all push notifications, all incident records
  • Cloud/shore: Aggregated fleet reports, backup synchronisation, software update distribution, shore operator access
This hybrid uses cloud infrastructure for the use cases where it's appropriate (aggregation, distribution, remote access) while keeping the latency-sensitive, availability-critical operations on the vessel where they belong.

See Shipwize in Action

Experience offline-first maritime communication and Augmented Communication live.

Request a Demo