<\/p>\n\n\n\n
Most of what we build with Laravel fits comfortably inside one shape: the browser asks, the server answers, the connection closes. Load a page. Save a record. Fetch some JSON. HTTP was designed for exactly this, and it’s very good at it.<\/p>\n\n\n\n
Then a product manager asks for a chat box.<\/p>\n\n\n\n
Suddenly the server knows something the client never asked about. A message arrived. A job finished. Someone joined the room. There is no open request to answer, and refreshing the page is not a feature.<\/p>\n\n\n\n
This post walks through how Laravel solves that today \u2014 with **Reverb**, its own first-party WebSocket server \u2014 and includes a small demo app with public, private, and presence channels wired end to end.<\/p>\n\n\n\n
Realtime isn’t “fast.” It’s *directional*<\/em>. The server can initiate.<\/p>\n\n\n\n Before WebSockets, we faked this three ways, and each has a tell:<\/p>\n\n\n\n Polling every three seconds means a hundred users generate two thousand requests a minute to tell you nothing happened. SSE fixes the wasted requests but only flows one way, which rules out chat and typing indicators. WebSockets start life as an HTTP request, get a `101 Switching Protocols` back, and then leave a two-way pipe open. Either side can speak at any time.<\/p>\n\n\n\n <\/p>\n\n\n\n The thing that trips people up is expecting to write socket code. You don’t. Laravel’s broadcasting is an event pipeline:<\/p>\n\n\n\n Your PHP dispatches an event. A broadcaster delivers it to a WebSocket server. The browser subscribes with **Laravel Echo**. The application code never manages a connection.<\/p>\n\n\n\n That indirection exists for a very PHP-shaped reason: a typical PHP process is request-scoped. It boots, responds, and dies. It’s a terrible place to hold ten thousand open sockets for six hours. So the sockets live somewhere else.<\/p>\n\n\n\n <\/p>\n\n\n\n For years, “somewhere else” meant [Pusher](https:\/\/pusher.com), a hosted WebSocket service. You POST events to their cloud, they fan them out to connected clients, you pay per connection and per message.<\/p>\n\n\n\n But Pusher is two things, and conflating them is what makes the docs confusing:<\/p>\n\n\n\n Laravel Echo has always been a thin wrapper over `pusher-js`. That’s the key detail, because it means anything that speaks the Pusher protocol can serve a Laravel frontend without touching the frontend.<\/p>\n\n\n\n Hosted Pusher is genuinely good: zero ops, global edge, TLS handled, mature clients. The catch is the usual one. Your bill scales with concurrent connections, your users’ messages traverse someone else’s infrastructure, and connection limits become an architectural constraint you didn’t choose.<\/p>\n\n\n\n <\/p>\n\n\n\n Laravel already knew how to broadcast. What it lacked was its own server to broadcast *to*<\/em>. That’s Reverb, shipped with Laravel 11:<\/p>\n\n\n\n **First-party.** Installed with Composer, configured in `.env`, started with Artisan.<\/p>\n\n\n\n **Pusher-protocol compatible.** Your events, channels, Echo code, and `pusher-js` keep working. Switching is mostly env + one config line.<\/p>\n\n\n\n **Self-hosted.** The sockets terminate on your infrastructure. No per-connection invoice, and chat\/presence data never leaves your network.**Horizontally scalable.** Multiple Reverb nodes share connection state over Redis.<\/p>\n\n\n\n The trade you’re making is explicit: you take on a long-running process to manage, and in return you get cost predictability and data locality. If you already run queue workers, you already run this kind of thing.<\/p>\n\n\n\n 1. Install<\/p>\n\n\n\n The installer publishes `config\/reverb.php`, scaffolds Echo, and writes the env keys.<\/p>\n\n\n\n <\/p>\n\n\n\n 2. Point broadcasting at Reverb<\/p>\n\n\n\n The `VITE_` duplicates matter: only prefixed variables are exposed to the frontend bundle. Note that the secret is *not*<\/em> among them \u2014 it stays server-side, where it signs channel authorization.<\/p>\n\n\n\n <\/p>\n\n\n\n 3. Connect Echo<\/p>\n\n\n\n Yes, you still install `pusher-js` \u2014 Reverb speaks that protocol, so that’s the client.<\/p>\n\n\n\n 4. Broadcast an event<\/p>\n\n\n\n Three methods worth knowing:<\/p>\n\n\n\n – `broadcastOn()` \u2014 which channel(s). `Channel`, `PrivateChannel`, or `PresenceChannel`.<\/p>\n\n\n\n – `broadcastAs()` \u2014 a stable event name instead of the fully-qualified class name. Rename the class later without breaking the frontend.<\/p>\n\n\n\n – `broadcastWith()` \u2014 the exact payload. Without it, all public properties get serialized, which is how internal fields leak to the browser.<\/p>\n\n\n\n `ShouldBroadcastNow` sends inline during the request. `ShouldBroadcast` queues it. Use `Now` in demos, queue it under real load \u2014 otherwise fan-out latency lands inside your HTTP response time.<\/p>\n\n\n\n 5. Authorize private and presence channels<\/p>\n\n\n\n This is the security boundary, and it’s easy to misread. When a client subscribes to a private or presence channel, `pusher-js` first POSTs to `\/broadcasting\/auth` with the channel name and socket id. Laravel runs the matching callback **using your normal session auth**, and only then hands back a signed token the WebSocket server will accept.<\/p>\n\n\n\n The difference between the two callbacks is the return type. A boolean gates a private channel. An **array** turns it into a presence channel: that array becomes the member’s public info, visible to everyone else in the room.<\/p>\n\n\n\n 6. Listen in the browser<\/p>\n\n\n\n Two details that cost people an afternoon each:<\/p>\n\n\n\n **The leading dot.** `.listen(‘.announcement.published’)` means “this is the literal event name.” Drop the dot and Echo prefixes your app namespace and expects `App\\Events\\…`. If your listener silently never fires, check the dot first.<\/p>\n\n\n\n **Channel name prefixes.** `Echo.private(‘notifications.1’)` talks to a channel the server sees as `private-notifications.1`, and `Echo.join(‘chat.lobby’)` becomes `presence-chat.lobby`. You write the short name in `channels.php`; the prefix is added by the protocol. This surfaces the moment you write a test:<\/p>\n\n\n\n That endpoint is testable in isolation, which makes channel authorization one of the few parts of realtime you can cover without booting a WebSocket server at all. Assert that a user can authorize their own private channel, that another user gets a 403, and that guests get nothing.<\/p>\n\n\n\n 7. Run the server<\/p>\n\n\n\n If you’re using Sail, remember to publish the port:<\/p>\n\n\n\n Here’s the bug you will write. The user submits a chat message, your JS optimistically appends it to the list, the event broadcasts, and the same browser receives it back \u2014 so the message appears twice.<\/p>\n\n\n\n Laravel’s answer is `toOthers()`, which excludes the originating connection. For that to work, the server has to know which connection sent the request, so the frontend must forward its socket id on the HTTP call:<\/p>\n\n\n\n Then on the PHP side, `broadcast(new ChatMessageSent(…))->toOthers()` instead of `Event::dispatch`. Send the header even if you aren’t using `toOthers()` yet \u2014 it costs nothing and it’s there when you need it.<\/p>\n\n\n\n The demo app pairs three routes with three channel types, which is enough to feel all the differences on one page:<\/p>\n\n\n\n Validate, dispatch, return. Nothing in your HTTP layer knows a WebSocket exists.<\/p>\n\n\n\n The best way to actually *see*<\/em> the distinction is to open two browsers and log in as two different users. Send an announcement: both see it. Send a notification: only one does. Watch the presence list update as the second browser opens and closes. Presence in particular is hard to appreciate until you watch a name appear in another window.<\/p>\n\n\n\n One caution while you’re in there: **the channel name in `broadcastOn()` and the name in `channels.php` must match exactly.** Broadcasting on `new PresenceChannel(‘chat.robby’)` while authorizing and joining `chat.lobby` produces no error anywhere \u2014 no exception, no log line, no failed request. The event goes out to a channel nobody is listening on, and the UI simply stays quiet. When realtime “doesn’t work,” compare those two strings before anything else.<\/p>\n\n\n\n Reverb in development is one Artisan command. Production asks for five more decisions:<\/p>\n\n\n\n **TLS.** Browsers on an HTTPS page will refuse a `ws:\/\/` connection. Terminate SSL at Nginx, Caddy, or your load balancer and proxy through to Reverb, then set `REVERB_SCHEME=https` so Echo dials `wss:\/\/`.<\/p>\n\n\n\n **A process manager.** `reverb:start` is a long-running process; if it dies, realtime silently stops while the rest of the app looks perfectly healthy. Supervisor, systemd, or a Forge daemon \u2014 same treatment as a queue worker. Restart it on deploy, too, since it holds your code in memory.<\/p>\n\n\n\n **Scaling.** One Reverb node keeps connections in its own memory, so two nodes behind a load balancer can’t see each other’s subscribers. Turn on Redis scaling:<\/p>\n\n\n\n Nodes then publish over a shared Redis channel and every connection gets its event regardless of which node it landed on.<\/p>\n\n\n\n **Queues.** Once traffic is real, switch `ShouldBroadcastNow` to `ShouldBroadcast` so fan-out happens in a worker instead of inside the user’s request.<\/p>\n\n\n\n **Allowed origins.** Restrict `config\/reverb.php` to your own domains rather than leaving the default wildcard.<\/p>\n\n\n\n **File descriptors.** Every connection is an open socket. The default `ulimit -n` of 1024 will cap you long before your CPU does.<\/p>\n\n\n\n Realtime is the server pushing events the moment they happen, and WebSockets are how you do it without burning requests on polling. Pusher popularized the protocol that Laravel Echo still speaks. Reverb implements that protocol on your own hardware, first-party, with the same PHP API you already know.<\/p>\n\n\n\n The whole path is: install \u2192 env \u2192 Echo \u2192 events \u2192 channel auth \u2192 `reverb:start`. If you’ve been putting off the chat feature because the realtime bill looked scary, that excuse is gone.<\/p>\n","protected":false},"excerpt":{"rendered":" Most of what we build with Laravel fits comfortably inside one shape: the browser asks, the server answers, the connection closes. Load a page. Save a record. Fetch some JSON. HTTP was designed for exactly this, and it’s very good at it. Then a product manager asks for a chat box. Suddenly the server knows […]<\/p>\n","protected":false},"author":7,"featured_media":1133,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[],"class_list":["post-1121","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-system"],"yoast_head":"\n\n
Approach<\/td> Direction<\/td> Latency<\/td> Cost<\/td><\/tr> Short polling<\/td> Client \u2192 server<\/td> Interval delay<\/td> Mostly empty requests<\/td><\/tr> Long polling<\/td> Client \u2192 server (held)<\/td> Low<\/td> Holds a connection *and*<\/em> a worker<\/td><\/tr> Server-Sent Events<\/td> Server \u2192 client<\/td> Low<\/td> Light, but one-way<\/td><\/tr> **WebSockets**<\/td> **Both ways, persistent**<\/td> **Near instant**<\/td> **One connection, then tiny frames**<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Laravel’s model: you don’t touch sockets<\/h2>\n\n\n\n
Event (ShouldBroadcast) \u2192 Broadcaster (Reverb\/Pusher\/Ably) \u2192 Channel \u2192 Echo (browser)<\/code><\/pre>\n\n\n\nWhere Pusher comes in \u2014 and why the name is everywhere<\/h2>\n\n\n\n
\n
Reverb: the missing piece<\/h2>\n\n\n\n
<\/td> Reverb<\/td> Pusher Cloud<\/td><\/tr> Hosting<\/td> You run the process<\/td> They run it<\/td><\/tr> Echo config<\/td> `broadcaster: ‘reverb’`<\/td> `broadcaster: ‘pusher’`<\/td><\/tr> Cost model<\/td> Your compute<\/td> Per connection \/ message<\/td><\/tr> Best when<\/td> You already operate infra<\/td> You want zero realtime ops<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Setting it up<\/h2>\n\n\n\n
php artisan install:broadcasting\n\n# or explicitly\n\ncomposer require laravel\/reverb\nphp artisan reverb:install<\/code><\/pre>\n\n\n\nBROADCAST_CONNECTION=reverb\n\nREVERB_APP_ID=my-app-id\nREVERB_APP_KEY=my-app-key\nREVERB_APP_SECRET=my-app-secret\nREVERB_HOST=\"localhost\"\nREVERB_PORT=8080\nREVERB_SCHEME=http\n\nVITE_REVERB_APP_KEY=\"${REVERB_APP_KEY}\"\nVITE_REVERB_HOST=\"${REVERB_HOST}\"\nVITE_REVERB_PORT=\"${REVERB_PORT}\"\nVITE_REVERB_SCHEME=\"${REVERB_SCHEME}\"<\/code><\/pre>\n\n\n\n\/\/ resources\/js\/echo.js\nimport Echo from 'laravel-echo';\nimport Pusher from 'pusher-js';\n\nwindow.Pusher = Pusher;\n\nwindow.Echo = new Echo({\n broadcaster: 'reverb',\n key: import.meta.env.VITE_REVERB_APP_KEY,\n wsHost: import.meta.env.VITE_REVERB_HOST,\n wsPort: import.meta.env.VITE_REVERB_PORT ?? 80,\n wssPort: import.meta.env.VITE_REVERB_PORT ?? 443,\n forceTLS: (import.meta.env.VITE_REVERB_SCHEME ?? 'https') === 'https',\n enabledTransports: ['ws', 'wss'],\n});<\/code><\/pre>\n\n\n\nclass AnnouncementPublished implements ShouldBroadcastNow\n{\n use Dispatchable, InteractsWithSockets, SerializesModels;\n\n public function __construct(public string $message) {}\n\n public function broadcastOn(): array\n {\n return [new Channel('announcements')];\n }\n\n public function broadcastAs(): string\n {\n return 'announcement.published';\n }\n\n public function broadcastWith(): array\n {\n return [\n 'message' => $this->message,\n 'published_at' => now()->toIso8601String(),\n ];\n }\n}<\/code><\/pre>\n\n\n\n\/ routes\/channels.php\nBroadcast::channel('notifications.{userId}', function (User $user, int $userId): bool {\n return $user->id === $userId;\n});\n\nBroadcast::channel('chat.{room}', function (User $user, string $room) {\n if ($room !== 'lobby') {\n return false;\n }\n\n return ['id' => $user->id, 'name' => $user->name];\n});<\/code><\/pre>\n\n\n\nwindow.Echo.channel('announcements')\n .listen('.announcement.published', (event) => { \/* ... *\/ });\n\nwindow.Echo.private(`notifications.${userId}`)\n .listen('.notification.sent', (event) => { \/* ... *\/ });\n\nwindow.Echo.join('chat.lobby')\n .here((users) => { \/* who is already here *\/ })\n .joining((user) => { \/* someone arrived *\/ })\n .leaving((user) => { \/* someone left *\/ })\n .listen('.chat.message', (event) => { \/* ... *\/ });<\/code><\/pre>\n\n\n\n$this->actingAs($user)->post('\/broadcasting\/auth', [\n 'socket_id' => '1234.5678',\n 'channel_name' => 'presence-chat.lobby',\n])->assertOk();<\/code><\/pre>\n\n\n\nphp artisan reverb:start\n\n# with Sail\n.\/vendor\/bin\/sail artisan reverb:start\n\n# whole stack at once\ncomposer run dev<\/code><\/pre>\n\n\n\nports:\n - '${APP_PORT:-80}:80'\n - '${VITE_PORT:-5173}:${VITE_PORT:-5173}'\n - '${REVERB_PORT:-8080}:8080'<\/code><\/pre>\n\n\n\nThe `X-Socket-ID` header, or: why you hear your own echo<\/h2>\n\n\n\n
A working playground<\/h2>\n\n\n\n
Channel<\/td> Type<\/td> Who receives it<\/td><\/tr> `announcements`<\/td> Public<\/td> Every visitor, logged in or not<\/td><\/tr> `notifications.{id}`<\/td> Private<\/td> Only that one user<\/td><\/tr> `chat.lobby`<\/td> Presence<\/td> Members of the room, plus join\/leave<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n The controller is unremarkable, which is the point:<\/h2>\n\n\n\n
public function announce(Request $request): JsonResponse\n{\n $validated = $request->validate([\n 'message' => ['required', 'string', 'max:255'],\n ]);\n\n AnnouncementPublished::dispatch($validated['message']);\n\n return response()->json(['ok' => true]);\n}<\/code><\/pre>\n\n\n\nBefore you ship it<\/h2>\n\n\n\n
REVERB_SCALING_ENABLED=true<\/code><\/pre>\n\n\n\nThe takeaway<\/h2>\n\n\n\n