Confession: I shipped a product launch two years ago with my realtime features running on Pusher’s free tier, and I found out what the 100-connection limit feels like at about 9:15pm, live, while people were actually using the thing. Notifications just stopped. No error, no crash, the badge counter quietly froze and I spent twenty minutes convinced my queue had died before I checked the Pusher dashboard and saw the connection graph flatlined against the ceiling.<\/p>\n
I limped through that night by upgrading the plan from my phone. Then I sat on the Pusher bill for another year because switching felt scary. Last spring I finally moved everything to Laravel Reverb<\/a>, the first-party WebSocket server that ships with Laravel now. This is the post I wish I’d read before I did it: what actually changed, what didn’t, and the production stuff nobody mentions in the quickstart.<\/p>\n Reverb is a WebSocket server written in PHP that speaks the Pusher protocol. That last part is the whole trick. Your front end already talks to Pusher through Laravel Echo, so when you swap in Reverb, Echo doesn’t really know the difference. You point it at your own server instead of Pusher’s cloud and most of your client code stays put.<\/p>\n Before Reverb existed I’d used two approaches, both of which I’m a little embarrassed by. The first was polling, because I didn’t want to think about WebSockets at all:<\/p>\n This works until you have a few thousand tabs open across your users, at which point you’re paying for a steady drumbeat of requests that mostly return “nope, nothing new.” It’s wasteful and it feels laggy because nothing is actually instant. Five seconds is a long time when someone’s staring at a chat window.<\/p>\n The second approach was Pusher, which is genuinely good and I have nothing bad to say about the product. The problem was the pricing model and the fact that my realtime traffic lived on someone else’s server. For a hobby project that’s fine. For something with real users and spiky load, the connection caps start to matter, and you can read the current tiers on the Pusher pricing page<\/a> yourself.<\/p>\n Here’s roughly what my broadcasting config looked like in the Pusher era. Nothing exotic:<\/p>\n And the client, pointed at Pusher’s cloud:<\/p>\n The events themselves were already framework-standard. An event that implements I want to flag that last code block because it’s the reason the migration turned out to be smaller than I’d built it up to be in my head. The events don’t change. The channel authorization doesn’t change. The only thing that changes is who’s holding the socket open.<\/p>\n On a fresh Laravel app you can do the whole thing with one command, which still feels slightly fake to me:<\/p>\n On my older app I did it by hand, which was still short:<\/p>\n The config gains a The client moves from “Pusher’s cluster” to “my host.” Same Echo object, different address:<\/p>\n Then you start the server:<\/p>\n That’s it. My The honest version: some things improved a lot, one thing got worse, and a couple of things I expected to be hard turned out fine.<\/p>\n The connection ceiling stopped being a number I worried about. Reverb on a small server handles thousands of concurrent connections without complaining, and the only limit is the hardware I’m already paying for. My realtime cost went from a monthly SaaS line item to roughly zero marginal cost, which for my traffic is the whole argument.<\/p>\n Latency felt the same, maybe a hair better, because the socket server now lives next to the app instead of bouncing through a cloud cluster. I didn’t benchmark this rigorously, so take it as a vibe, not a measurement.<\/p>\n What got worse: I now own an always-on process. Pusher’s whole pitch is that you never think about the server. With Reverb, if the process dies, your realtime dies, and that’s on me. The first week I learned this the dumb way when a deploy didn’t restart the daemon and notifications silently stopped again. Different cause, same frozen badge, same brief panic.<\/p>\n The thing I expected to be painful and wasn’t: queues. Broadcasting an event still goes through your queue worker when the event is queued, so if your jobs aren’t reliable, your realtime isn’t either. I’d already spent a while getting that part trustworthy, which I wrote about in my post on Laravel queue defaults<\/a>, and that work paid off here directly. If you’re moving to Reverb and your queue setup is shaky, fix that first.<\/p>\n The quickstart gets you a server running in your terminal. Production needs three more things, and none of them are hard once you’ve seen them.<\/p>\n First, keep the process alive. Second, terminate TLS in front of it. Browsers want a secure WebSocket ( Third, if you outgrow one server, turn on scaling. Reverb can use Redis to share events across multiple Reverb processes, so a message published on one node reaches clients connected to another. You flip One small gotcha worth saying out loud: your app server and your Reverb server both need to agree on the app key and secret, and if they drift, you get silent auth failures on private channels that look exactly like “nothing is broadcasting.” I lost an afternoon to a stale Spin up a throwaway Laravel app, run If you’re already on Pusher, do the swap on a branch, not in production at 9pm during a launch. Point your local Echo at Reverb, confirm your existing events still fire, then plan the systemd and Nginx pieces before you ship. The application code barely moves; the operational part is where your attention should go. I help teams untangle exactly this kind of self-hosting decision in my freelance work<\/a>, and the pattern is almost always the same: the migration is easy, the “who restarts the daemon at 3am” question is the real one.<\/p>\n","protected":false},"excerpt":{"rendered":" I moved my realtime features off Pusher to self-hosted Laravel Reverb. Here’s the actual code diff, what got better, and the production gotchas that bit me.<\/p>\n","protected":false},"author":2,"featured_media":319,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rank_math_title":"","rank_math_description":"I moved my realtime features off Pusher to self-hosted Laravel Reverb. Here's the actual code diff, what got better, and the production gotchas that bit me.","rank_math_focus_keyword":"laravel reverb","rank_math_canonical_url":"","rank_math_robots":"","footnotes":""},"categories":[173,52],"tags":[362,56,360,53,361,231],"class_list":["post-320","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-laravel","category-php","tag-broadcasting","tag-laravel","tag-laravel-reverb","tag-php","tag-realtime","tag-websockets"],"_links":{"self":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/320","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/comments?post=320"}],"version-history":[{"count":0,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/320\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media\/319"}],"wp:attachment":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media?parent=320"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/categories?post=320"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/tags?post=320"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}What Reverb actually is, and what it replaced<\/h2>\n
\/\/ the really old way: poll every few seconds and hope\nsetInterval(async () => {\n const res = await fetch('\/api\/notifications\/unread');\n const { count } = await res.json();\n updateBadge(count);\n}, 5000);\n<\/code><\/pre>\nThe before: my Pusher setup<\/h2>\n
\/\/ config\/broadcasting.php\n'connections' => [\n 'pusher' => [\n 'driver' => 'pusher',\n 'key' => env('PUSHER_APP_KEY'),\n 'secret' => env('PUSHER_APP_SECRET'),\n 'app_id' => env('PUSHER_APP_ID'),\n 'options' => [\n 'cluster' => env('PUSHER_APP_CLUSTER'),\n 'useTLS' => true,\n ],\n ],\n],\n<\/code><\/pre>\n\/\/ resources\/js\/echo.js\nimport Echo from 'laravel-echo';\nimport Pusher from 'pusher-js';\n\nwindow.Pusher = Pusher;\nwindow.Echo = new Echo({\n broadcaster: 'pusher',\n key: import.meta.env.VITE_PUSHER_APP_KEY,\n cluster: import.meta.env.VITE_PUSHER_APP_CLUSTER,\n forceTLS: true,\n});\n<\/code><\/pre>\nShouldBroadcast<\/code> doesn’t care who’s delivering the message:<\/p>\nclass OrderShipped implements ShouldBroadcast\n{\n public function __construct(public Order $order) {}\n\n public function broadcastOn(): array\n {\n return [new PrivateChannel('orders.'.$this->order->user_id)];\n }\n}\n<\/code><\/pre>\nThe after: switching to Reverb<\/h2>\n
php artisan install:broadcasting\n# installs Reverb, sets BROADCAST_CONNECTION=reverb,\n# and wires up Echo in your resources\/js for you\n<\/code><\/pre>\ncomposer require laravel\/reverb\nphp artisan reverb:install\n<\/code><\/pre>\nreverb<\/code> connection. Notice how much it rhymes with the Pusher block above, because it’s the same protocol underneath:<\/p>\n\/\/ config\/broadcasting.php\n'reverb' => [\n 'driver' => 'reverb',\n 'key' => env('REVERB_APP_KEY'),\n 'secret' => env('REVERB_APP_SECRET'),\n 'app_id' => env('REVERB_APP_ID'),\n 'options' => [\n 'host' => env('REVERB_HOST'),\n 'port' => env('REVERB_PORT', 443),\n 'scheme' => env('REVERB_SCHEME', 'https'),\n 'useTLS' => env('REVERB_SCHEME', 'https') === 'https',\n ],\n],\n<\/code><\/pre>\n\/\/ resources\/js\/echo.js\nimport Echo from 'laravel-echo';\nimport Pusher from 'pusher-js';\n\nwindow.Pusher = Pusher;\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});\n<\/code><\/pre>\nphp artisan reverb:start\n<\/code><\/pre>\nOrderShipped<\/code> event didn’t get touched. My channel auth routes didn’t get touched. I changed two config files and an env block, and the realtime features I’d been renting now ran on the same box as everything else. If you want the canonical version of all this, the Laravel broadcasting docs<\/a> cover the event and channel side properly.<\/p>\nWhat actually got better, and what didn’t<\/h2>\n
Running it in production without it falling over<\/h2>\n
php artisan reverb:start<\/code> needs a supervisor. I use a systemd service that restarts on failure and on boot, so a crashed daemon or a server reboot doesn’t take realtime down with it. This is the single most important step, because it’s the failure I actually hit.<\/p>\nwss:\/\/<\/code>), so I run Reverb behind Nginx as a reverse proxy with the certificate on Nginx and plain WebSocket traffic on the loopback behind it. The Reverb docs have a sample Nginx block that handles the connection upgrade headers correctly, and I’d copy theirs rather than hand-roll it.<\/p>\nREVERB_SCALING_ENABLED=true<\/code> and point it at Redis. I’m not at that scale on most projects, but it’s reassuring that the path exists and doesn’t involve rewriting anything.<\/p>\n.env<\/code> on one of two boxes. Check that first when private channels go quiet.<\/p>\nIf you want to try this this week<\/h2>\n
php artisan install:broadcasting<\/code>, and wire one toast notification to a ShouldBroadcast<\/code> event. Open two browser tabs, trigger the event from a Tinker session, and watch it land in both without a refresh. That single loop took me about fifteen minutes and it’s the moment Reverb stopped feeling like infrastructure I had to be afraid of.<\/p>\n