Vessel Internet Connectivity: What Shore IT Should Assume About the Link
Satellite at sea improved sharply, but the link is still shared, variable and metered. Design the shore side for that rather than hoping.
A vessel link is shared, variable and usually metered, and it is the one part of a shipping company's network that shore IT cannot engineer. The workable approach is to design shore systems so they queue and sync rather than expect a live session, keep crew welfare internet separated from operational systems, and schedule large transfers instead of pulling them on demand.
Key takeaways
- Design for intermittent, not absent: queue and sync beats live sessions.
- Low-orbit satellite changed capacity and latency, but not the need for separation.
- Crew welfare internet must never share a network with operational systems.
- Keep vessel mailboxes small so a reconnection is not a flood.
- Schedule large transfers to a chosen window rather than allowing them on demand.
- Give the master a documented fallback before the primary link fails, not after.
Vessel internet connectivity: what changed, and what did not
For most of the past two decades vessel connectivity meant a narrow, expensive and high-latency satellite link, and shore systems were designed around that scarcity. Email was compressed and batched. Reporting was a form emailed once a day. Anything large waited for port. The constraint shaped the working practice, and the working practice shaped the software.
Low-orbit satellite services have genuinely changed the capacity and latency picture, and Starlink publishes a maritime offering aimed squarely at commercial vessels. Bandwidth that once made a video call impossible now makes it routine in many operating areas. That is a real change and it is worth taking advantage of.
What has not changed is that the link is still outside your control. Coverage varies by area, service can be degraded or interrupted, hardware fails at sea where nobody can replace it, and the commercial arrangement is usually metered or shaped in some way. A shore system that assumes a permanent connection will fail in exactly the conditions where it matters most.
Design for queue and sync, not for live sessions
The single most useful design principle is that anything a vessel does should complete locally and reconcile later. Mail should accept a message and send it when there is a link, rather than failing to send. A noon report or a maintenance record should be completed and stored on the device, syncing when it can. A document the master needs should already be on board rather than fetched when required.
This sounds obvious and is routinely got wrong, usually by moving a shore process to a web application that requires a live session to do anything. A browser-based form that loses the entry when the connection drops mid-submission is worse than the email it replaced, because the crew stop trusting it and revert to sending things another way.
The practical test when evaluating any system a vessel will use: what happens if the connection drops halfway through this task? If the answer is that the work is lost, the system is wrong for the environment regardless of how good it is ashore.
There is a second-order benefit to designing this way. A system that tolerates a dropped link at sea also tolerates a poor mobile signal in a port office, a lift journey in a tower, or an engineer working from a site cabin. The discipline the vessel forces on you produces software choices that hold up everywhere else in the business.
- Prefer applications that hold data locally and sync, over ones requiring a live session.
- Pre-position documents the vessel will need rather than fetching them on demand.
- Make forms survive a dropped connection without losing the entry.
- Test every vessel-facing system by pulling the connection mid-task.
Keeping the mailbox from becoming the problem
Vessel mailboxes have a habit of becoming enormous, because nobody deletes anything at sea and attachments accumulate. On a narrow link that used to be catastrophic; on a modern link it is merely expensive and slow, particularly after a period offline when everything arrives at once.
The arrangement that works is a small working mailbox on board with an archive held ashore. The master has recent correspondence available locally, historical mail is searchable from shore when needed, and a reconnection after an outage brings a manageable amount of traffic rather than a flood. Microsoft documents the retention and archiving mechanics in its guidance on how retention works, and the same principles apply whichever platform you run.
Attachment discipline matters more here than ashore. Circulating a large drawing to a fleet distribution list sends it to every vessel over a metered link. A shared location with a notification is a fraction of the cost and reaches the same people.
Crew welfare internet, and why separation is not optional
Better connectivity has made crew welfare internet a normal expectation rather than a perk, and that is a genuine improvement to life at sea. It also introduces a network full of personal devices, running whatever software their owners installed, onto a vessel that also carries operational and navigational systems.
The separation principle is identical to hotel guest Wi-Fi ashore, and for the same reason: an infected personal phone should be able to reach the internet and nothing else. Crew welfare traffic sits on its own network, isolated from anything operational, with no route between them. This is straightforward to specify at installation and awkward to retrofit once a single flat network is in service.
Our hotel guest Wi-Fi design guide covers the pattern in a shore context, and the reasoning transfers directly. The network security for small business page covers how segments are built and documented.
Specify it at the point of installation and it costs nothing. Retrofit it onto a vessel already running a single flat network and it means a yard visit, a rewire and a certification conversation, which is why this is the item most worth getting right the first time a vessel enters management.
Bandwidth management without making enemies
Where a link is metered or shared, somebody has to decide what gets priority, and the decision is as much social as technical. A policy that leaves crew unable to video call family generates resentment and eventually workarounds. A policy that lets a single large download saturate the link leaves the master unable to send a required report.
The arrangement most operators settle on gives operational traffic guaranteed priority, allocates a defined share to crew welfare, and schedules bulk transfers into a window when neither is busy. Software updates, chart corrections and large document syncs are pulled at a chosen time rather than whenever a device decides to update itself, which is often the single largest consumer of an unmanaged link.
Whatever the policy, write it down and tell the crew what it is. An unexplained restriction is experienced as the connection being broken, and generates support calls that shore IT cannot resolve because nothing is actually wrong.
Measure before you legislate. Most operators who look at their link for the first time find that the largest consumers are not what they assumed: automatic updates, cloud photo backup on crew phones and background sync of shore document libraries routinely outweigh anything anyone is deliberately doing. Two weeks of measurement usually makes the policy write itself.
Planning for the link failing entirely
Hardware fails at sea, coverage has gaps, and a service can be interrupted for reasons nobody ashore controls. The question worth answering before it happens is how the shore office and the master communicate when the primary link is down, and who decides that it is down rather than merely slow.
That means a documented fallback: a secondary means of contact, a threshold at which it is used, and a named person ashore who is called. Many operators retain a legacy satellite service at minimal cost purely as this fallback, which is a reasonable insurance given what a genuinely uncontactable vessel costs in decision-making terms.
The same planning applies ashore, incidentally. A shipping office with a single internet line is one street works away from being unable to reach its own fleet. Our office network setup page covers dual lines and automatic failover, which in this sector is closer to a requirement than an upgrade.
What stays with the vendor
A clear boundary saves a lot of argument. Navigational and operational systems on the bridge and in the engine room are supplied, updated and certified by class-approved vendors, and shore IT should not be touching them. Chart updates, ECDIS software and engine monitoring are their domain, under the rules that govern the vessel's certification.
Shore IT's proper scope is the business side: mail, documents, reporting, crew administration, the welfare network and the shore infrastructure the vessel talks to. The overlap needing coordination is the network on board, where the vendor's operational equipment and the business and welfare networks share physical infrastructure, and the separation between them has to be agreed rather than assumed.
Getting that boundary written down at the outset prevents the two common failures: shore IT changing something that turns out to be certified, and a vendor installing an operational system onto the business network because it was the socket that was available.
Put the boundary in writing as part of the handover when a vessel enters management, and revisit it whenever a vendor installs anything new. The question to ask at that moment is simple: which network is this going on, and who is responsible for patching it? A five-minute conversation at installation prevents an operational system quietly appearing on the business network.
What good looks like from the shore office
A shipping company with this right has a shore office on dual internet lines with automatic failover, vessel-facing systems that queue and sync rather than requiring a live session, small working mailboxes with archives ashore, welfare traffic separated from anything operational, a written bandwidth policy the crew has seen, and a documented fallback for when the link fails.
None of that depends on which satellite service is fitted, which is the point. The service will change, and has changed twice in a decade. Designing the shore side around the link's characteristics rather than around a particular provider is what makes the arrangement survive the next change.
Our IT support for shipping companies page covers how this fits with the rest of a shore office, and managed IT support covers who watches it once it is running.
The test of whether it is working is what happens on a bad day. A vessel out of coverage for six hours should reconnect and reconcile quietly, with the noon reports queued and sent, the mail flowing without a flood, and nobody ashore having had to telephone the master to ask whether anything was lost.
If you want this set up rather than read about, we survey and install Starlink on vessels berthed in the UAE and integrate it with the ship's network and the shore office. The hardware and subscription are bought in your name directly from Starlink; we do the survey, mounting, cabling and failover. The satellite internet and Starlink page sets out what an install covers, and you can send us the vessel and berth to arrange a survey.
Frequently asked questions
Not quite, and treating it as one is the common mistake. Capacity and latency have improved enough for video calls and routine sync in many areas, but the link remains shared, variable and usually metered, and coverage is not uniform. Design for queue and sync, then enjoy the better performance when it is there.
Never. Crew welfare devices are personal, unmanaged and numerous, and they belong on a network that reaches the internet and nothing else. Operational and navigational systems sit apart with no route between them. It is simple to specify at installation and genuinely awkward to retrofit onto a flat network later.
Because nothing is deleted at sea and attachments accumulate, so the mailbox grows until a reconnection after any period offline brings an unmanageable flood. A small working mailbox on board with the archive held ashore fixes it: recent mail is local, history is searchable from shore, and reconnection stays manageable.
The class-approved vendor who supplied them, under the rules governing the vessel's certification. Shore IT should not touch those systems. The area needing coordination is the shipboard network, where operational equipment and the business and welfare networks share physical infrastructure and the separation has to be agreed explicitly.
Schedule them rather than allowing devices to update whenever they choose. Unmanaged automatic updates are frequently the largest single consumer of a vessel link, and they arrive without warning. Pulling them into a defined window, at a time when neither operational traffic nor crew use is heavy, removes the problem entirely.
Have decided beforehand. That means a documented secondary means of contact, a stated threshold for when it is used rather than waiting to see if the link recovers, and a named person ashore who is contacted. Many operators keep a legacy satellite service at low cost purely for this.
In this sector, effectively yes. A single line means one provider fault leaves the office unable to reach its own fleet during a port call or an incident. A second line from a different provider with automatic failover on the firewall turns that from a stopped day into a slower one, and it is inexpensive relative to what it protects.
Written by Srinivasan Ramachandran, Founder, Listonics · Published Sep 28, 2026 · Last reviewed October 13, 2026 · 2,150 words
