laravel-wave: Laravel broadcasting over plain HTTP with server-sent events

Broadcasting without the WebSocket leg

Wave's pitch is that real-time server broadcasting becomes possible over native HTTP with no WebSocket setup, and the mechanism it uses is Server-Sent Events. SSE is described in the README as specially tuned for real-time server-to-client communication, which is exactly the shape of a Laravel broadcast: the server pushes, the client listens, and the client does not need to send anything back on the same channel. The practical consequence is that the deployment stops needing a second process. Laravel's broadcasting system already has a driver architecture, and with Wave the transport for that driver becomes a plain HTTP response that stays open. The README states that it works with Laravel's default redis broadcasting driver and supports Laravel Echo, and the demo streaming tweets is there to show the behaviour rather than to describe it. Compatibility is claimed with Laravel, Octane and Herd.

The install path changed with Laravel 11

There are two installation routes and which one you use depends on your framework version. On Laravel 11 or higher you install the package with Composer and then run the broadcasting installer.

composer require qruto/laravel-wave
php artisan install:broadcasting

On Laravel 10 or lower you install on both the server and the client side, with Composer and npm.

composer require qruto/laravel-wave
npm install laravel-wave

Either way, the .env file has to point at the redis broadcasting driver.

BROADCAST_DRIVER = redis

The point of the redis driver is not incidental. Laravel's default broadcasting driver is redis, so a project that has never configured broadcasting already has a working queue for events, and Wave reuses it as the transport. No second broker, no socket server, and no separate configuration for the connection. That is the whole architectural difference between Wave and a Pusher-style setup.

Echo with a different connector

On the client the change is one import and one option. You import Laravel Echo as usual and pass the WaveConnector as the broadcaster, so the rest of your Echo code does not change.

import Echo from 'laravel-echo';

import { WaveConnector } from 'laravel-wave';

window.Echo = new Echo({broadcaster: WaveConnector});

This is the part that makes the package a drop-in rather than a rewrite. Applications that already listen on private channels, presence channels or wildcard channels through Echo keep their channel names and their authorization logic, because Echo is still doing the subscribing and the authentication, and only the transport underneath has changed. The README also documents a Wave model API for working with predefined Eloquent events, so an application that wants live model updates does not have to declare its own events by hand.

The stream resumes where it broke

The feature the README leads with is called Resume From Last, and it addresses the failure mode that makes SSE feel fragile. When a connection drops, Wave intelligently resumes the event stream from the last event, so no crucial data is lost in transit. This is the property that distinguishes a server-sent event stream from a plain poll: the browser sends the last event identifier it saw, and the server replays from that point rather than starting over or skipping ahead. The mechanism requires the redis driver underneath, since the replay depends on the event log rather than on the transport alone. If your deployment loses events during a reconnect, this is the behaviour to check first, because the alternative, a reconnect with no replay, is exactly what a resume feature exists to prevent.

pauseInactive closes the stream for hidden tabs

The second headline feature is resource-friendly broadcasting through a pauseInactive option, described as maximizing resource efficiency by closing the data stream when the user is inactive, such as when the user minimizes the browser, and automatically reopening it upon resumption of visibility. The option is turned off by default. The reasoning is about what an open event stream costs on the server: every connected browser holds a response open, and a user who has not looked at the tab for an hour should not be holding a connection for the whole hour. The trade-off is that a closed stream is a gap in delivery, so the pause behaviour interacts with the resume behaviour, and the README does not document how events that occur during a paused window are handled. That is the question to test if you enable it.

You keep control of connection and authentication requests

The third feature is described as full requests control: Wave hands you the reins over connection and authentication requests, granting freedom to shape the broadcasting setup to your exact requirements. In practice this means the package is not deciding for you who is allowed to connect. Laravel's channel authorization file is still the place where permissions are decided, and the README lists what install:broadcasting produces in Laravel 11 and higher: the broadcasting channel authorization file in routes/channels.php, the broadcasting configuration file in config/broadcasting.php, an Echo instance in resources/echo.js, and an optional Wave configuration file in config/wave.php. The Wave configuration file being optional and separate from the broadcasting configuration is the point, since the Wave-specific settings, including pauseInactive, live apart from the framework's own broadcasting options.

The repository shape and the maintainer notice

The repository is a conventional Composer package with a src directory, a config directory for the published configuration, a routes directory, stubs for the installer, tests, and a set of quality tools that say something about the standards the project holds itself to. There is a phpstan configuration with a baseline file, a separate rector configuration, a phpunit configuration, and separate GitHub workflows for tests, styles, types and a refactor job, so static analysis, code style and type checking are separate gates rather than one combined check. The most important fact about the project is at the very top of the README, in a callout titled Looking for a new maintainer. The author says they still love the package and do not want to abandon it, and are looking for someone to take care of it, noting that Wave is still useful and still a good fit for Laravel, and that the same goes for the sibling package Flora which provides the install and update artisan commands. The last push to the repository was on 2026-09-16 and the latest release is 0.10.1 from 2025-03-21, before which came 0.10.0 in March 2025 and 0.9.1 in April 2024.

Where laravel-wave is the wrong choice

Four limits apply. The first is the obvious one: this is a Laravel package, so it is irrelevant outside the framework, and the transport assumes Laravel's broadcasting event pipeline and its redis driver rather than a generic message bus. The second is that SSE is one-directional. The README presents server-sent events as specially tuned for server-to-client communication, which means the pattern of a client sending on the same channel, such as presence channels where clients report presence to each other, is not the shape this transport handles. The third is the maintenance notice, which is not a technical limitation but a practical one: you are depending on a package whose author is asking for a successor, on a 0.x version line, with an MIT licence that permits you to fork it if nobody picks it up. The fourth is infrastructure: SSE needs a long-lived HTTP response, so a reverse proxy that buffers responses, or a serverless runtime that cannot hold one, will break the stream. The README does not document proxy configuration, so that is something you have to work out for your own deployment.

Editorial conclusion

Use laravel-wave when you are on Laravel and want live updates without standing up a WebSocket server, since server-sent events travel over ordinary HTTP and the redis broadcasting driver is already the default on most Laravel installations. Do not start a new project on it without reading the maintainer notice, because the README asks for a new maintainer and the latest release is 0.10.1 from 2025-03-21 even though the last push was on 2026-09-16, so you may be adopting an unmaintained dependency. Verify first that your Laravel version is covered by the install path you follow, since Laravel 11 and higher use the install:broadcasting command while Laravel 10 and lower need the npm package as well, and that a reverse proxy in front of your app does not buffer the event stream.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. qruto/laravel-wave on GitHub
4. README
5. Releases