Starlink is not redundancy: what a resilient vessel link actually looks like

Starlink changed maritime connectivity. It is fast, it is cheap for what it gives you, and it made things possible that were not possible three years ago: crew video calls, real-time monitoring, bulk data to shore. None of that is in dispute.

What is in dispute is the sentence we keep hearing from operators: "we moved everything to Starlink, so connectivity is solved." It is not solved. It has been concentrated onto a single constellation, and operators who did this discovered what a single point of failure feels like at scale.

How one link fails

A single satellite service, any single satellite service, degrades or drops for reasons you do not control:

• Weather. Heavy rain attenuates the signal, and the ocean specialises in weather.
• Capacity contention. Cells get busy. Throughput that was fine in trials is not fine when every vessel in the anchorage shares it.
• Coverage gaps and high latitudes. Performance is not uniform across the planet, and some of the places vessels go are exactly the places it degrades.
• The ordinary failures. Hardware, cabling, power, software updates, account issues. A dome or a flat panel is still equipment on a moving steel structure.

When the only link drops, the consequences are not abstract. The crew loses contact with home. The payment terminal times out mid-transaction. The shore team loses sight of the vessel exactly when they most want it.

What a resilient architecture looks like

The answer is not a bigger satellite package. It is more than one path, intelligently managed, with something making the decision about which one to use before anybody notices there was a decision to make:

• Starlink carries the load. High-bandwidth LEO for the traffic that used to be unaffordable: crew video, monitoring, bulk transfers.
• VSAT carries the guarantee. Global, proven, and available where and when LEO is not. It is slower and it is there, which is the entire point of a guarantee.
• 4G/5G carries the cheap traffic whenever the vessel is close enough to the coast to use it, including in port, where it is usually the fastest path available.
• Bonding and failover make them one connection. Traffic moves between paths automatically. A voice call started on 5G alongside continues on satellite as you leave the coast, without dropping.

The failure mode nobody tests: session persistence

Switching links is easy. Switching links without breaking the sessions running across themis the hard part, and it is where most "we have a backup link" setups quietly fail. The backup exists, but every TCP session, VPN tunnel and payment transaction dies at the moment of switchover, which the crew experiences as "the internet broke."

We have spent years debugging what happens when a payment session crosses between two links mid-transaction. That is not a theoretical problem, and the fix is not obvious: it lives in how the bonding layer presents one stable connection to the vessel while shuffling paths underneath it.

Bandwidth management is part of redundancy

A resilient link that fails over to a thinner path needs to know what matters. When the vessel drops from LEO bandwidth to VSAT bandwidth, something must decide who gets the remaining capacity:

• Operational systems and the payment terminal get priority.
• Crew streaming gets fair-use limits instead of starving everything else.
• Crew welfare traffic stays separated from operational traffic at all times.
• You can see where the bandwidth is going before the bill tells you.

The honest summary

Redundancy is not a luxury item on a vessel. It is the entire product. One link, however good, is a bet that weather, capacity, coverage and hardware will all cooperate at once, every day, mid-ocean. Two dissimilar paths with automatic failover and session persistence is an engineering answer instead of a bet.

If your airtime contracts are good, keep them; this architecture is about the engineering around the links, not about selling you new ones. More on how we deliver this on our Communications page.