The Challenge

A patrol moves. A status changes. Somebody coordinating a rescue needs to know now, not on the next poll.

That requirement sounds like a feature, and it is really a piece of infrastructure. Live updates need a server holding thousands of open connections for hours at a time, which is close to the opposite of what a web application is built for. A request/response app is designed to accept work, finish it, and let go. A websocket server is designed to hold on.

Putting the two in one process couples them in the way that hurts most: the socket tier's memory profile becomes the web app's problem, and a deploy of the web app disconnects everyone watching. Surf Life Saving also has more than one platform that needs to broadcast, so solving it per application would mean solving it repeatedly.

The obvious alternative is a hosted realtime service. That means metered per-message billing on a system whose traffic scales with patrol activity, and volunteer and operational data crossing a third party.

The Solution

We run the realtime tier as its own service: a separate, versioned Laravel application whose only job is to accept broadcasts from the platforms and fan them out to connected clients.

One server, every platform

The platforms do not each carry a socket implementation. They publish over the standard broadcast protocol to a single Nano-operated endpoint on TLS, and the Operations platform points at it by default in its own configuration rather than by convention. Adding a new realtime surface is a matter of declaring a channel in the platform that owns the data, not standing up more infrastructure.

Authorisation stays with the data

The broadcast server moves messages. It does not decide who may hear them. Channel authorisation is enforced by the application that owns the records, which is where the permission model and the membership data already live. Operations carries a substantial set of these authorisation callbacks — the socket tier stays deliberately ignorant of what a patrol is or who may watch it.

That split is what makes the shared server safe to share. A component that fans out messages without understanding them cannot leak something it was never told.

Self-hosted on purpose

Running it ourselves keeps operational data on infrastructure we maintain, and it removes per-message pricing from a workload that spikes exactly when the service matters most — a busy summer weekend. It also means the runtime is ours to keep current, which is the other half of the job.

Kept current, and kept clean

The service tracks the current framework and language versions rather than being left where it was first deployed, and its dependency backlog is worked down deliberately: the outstanding security advisories against it were driven from fifteen to zero, and the front-end advisories cleared alongside them. It carries its own release history, coding-standard and static-analysis gates, application monitoring, and error reporting.

On a component that holds long-lived authenticated connections and carries data about volunteers, that maintenance is the deliverable. An unpatched realtime tier is a worse liability than a slow one.

The Results

One shared realtime service rather than a socket implementation per platform
Self-hosted, so operational data stays on infrastructure we run and traffic spikes carry no per-message cost
Authorisation left with the owning application, so the shared tier holds no permission logic of its own
Fifteen outstanding security advisories driven to zero, with the front-end tree cleared in the same pass
Current framework and language versions, maintained as a deliberate upgrade line rather than left at first deployment
Monitored and instrumented in its own right, with quality gates on every change

What that means commercially

Realtime is where "we could add websockets" quietly becomes an operational commitment. The interesting decision is not making a message appear on a screen; it is who runs the process that holds ten thousand connections at 11am on a Sunday in January, who patches it, and what happens to it when the web app deploys. Separating that tier and operating it is the unglamorous answer, and it is the reason live tracking has been dependable across successive summers.

Technology

A standalone Laravel application running the framework's first-party websocket server, deployed separately from the platforms it serves and reachable over TLS on its own hostname. Platforms broadcast to it over the standard protocol with channel authorisation resolved in the owning application. Application performance monitoring and error reporting are built in; coding-standard, static-analysis and lint gates run on every change. Versioned with its own release history.

See also: SLSA Live Patrol Tracking — the tracking feature this tier delivers, and SLSA Operations App — the platform that broadcasts through it.

Related Nano Solutions services: Managed Linux Infrastructure · Cloud Maintenance · Software Development. WA government agencies can engage us directly through our CUAICTS2021 panel listing.