Originally published at hafiz.dev
You're adding real-time features to a Laravel app. Live notifications, a chat panel, a collaborative cursor, a dashboard that updates without a refresh. The broadcasting code is the easy part because Laravel's API is the same no matter what's underneath. The actual decision is which WebSocket server sits behind it.
Three options dominate the Laravel world: Reverb (first-party, self-hosted), Pusher (hosted, pay per connection), and Soketi (open-source, self-hosted, Pusher-compatible). They all speak the Pusher protocol, so your broadcasting and Echo code barely changes between them. What changes is cost, scaling ceiling, and how much operational work lands on you.
I'll compare all three on the things that actually decide it, then give you a clear pick for each stage. There's also one fact about Soketi that should change how you think about it in 2026, and most comparisons skip it.
The Quick Version
Pusher is the hosted option: zero servers to run, you pay per concurrent connection, and it gets expensive as you grow. Reverb is Laravel's first-party server: free software, you host it (or let Laravel Cloud host it), and it scales with Redis. Soketi is the open-source Pusher-compatible server: also free and self-hosted, historically the budget favorite, but its maintenance situation in 2026 is the catch.
All three use the Pusher protocol. That's the thing that makes this a real choice rather than a lock-in: you can move between them with config changes, not rewrites.
Pusher: Pay to Not Think About It
Pusher is the original hosted WebSocket service, and the pitch hasn't changed. You never run a server. You never tune file descriptors or restart a daemon. You create an app, get credentials, and broadcast.
The pricing is connection-based and it's the whole story:
- Free Sandbox: 100 concurrent connections, 200,000 messages/day
- Startup: $49/month, 500 concurrent connections
- Business: $299/month, 2,000 concurrent connections
- Higher tiers climb past $499 to $1,199/month for 15,000 to 30,000 connections
A message counts both ways. Publish one event to 50 subscribers and that's 51 messages against your quota. For a chatty app (presence channels, typing indicators, live cursors) the message count climbs faster than you'd expect, and the daily cap on the free tier makes it unsuitable for production testing.
Pusher's real value is the zero-ops promise and the SDK breadth. If you want real-time working in 15 minutes and you'd rather pay than provision, it delivers. The problem is purely cost at scale: 2,000 connections for $299/month is the kind of bill that makes self-hosting look attractive the moment you have the ops capacity to handle it.
Reverb: The First-Party Default
Reverb is Laravel's own WebSocket server, built on ReactPHP, shipped in 2024, and by 2026 it's the default choice for most Laravel teams. It speaks the Pusher protocol, so it's a drop-in for Laravel broadcasting and Echo. A single server handles thousands of concurrent connections, and it's free software: you only pay for the box it runs on.
That last point is the headline. A Reverb instance on a $10 DigitalOcean droplet or a cheap Hetzner VPS handles early-stage real-time features for the cost of the server, not per connection. Compared to Pusher's $49 to $299 tiers, the savings start immediately and widen as you grow.
Scaling past one server uses Redis. You set REVERB_SCALING_ENABLED=true, point your Reverb instances at a shared Redis server, and put them behind a load balancer. When a message hits one server, Redis publishes it to the others via pub/sub, so connections spread across machines stay in sync. It's the same horizontal-scaling pattern you'd use for any stateful service.
Two things make Reverb in 2026 stronger than it was at launch.
First, the database driver. You no longer need Redis for small-to-medium apps. Reverb can use your existing MySQL or Postgres database to coordinate, which means you can ship live notifications, dashboards, and collaborative features without provisioning, securing, and paying for a Redis cluster. For early-stage products that's a real infrastructure cost cut. For high-throughput apps (10,000+ concurrent connections), Redis is still the recommended backend.
Second, managed Reverb on Laravel Cloud. If you want Reverb's economics without running the server yourself, Laravel Cloud offers fully managed Reverb clusters. You pick the number of concurrent connections, and Laravel claims up to 50% less than third-party tools like Pusher. It became the single most requested Cloud feature for a reason: it's the middle ground between self-hosting and paying Pusher's per-connection rates. It's the same managed-versus-self-hosted trade I walked through for Cloud's managed queues versus Horizon, just applied to WebSockets.
The cost of Reverb shows up as operations, not dollars. A self-hosted Reverb server is a long-running process you have to keep alive with Supervisor, tune for open file limits, restart on deploy with reverb:restart, and monitor. If your site is on Forge, the Application panel has a Reverb integration that handles the server tuning for you. But it's still infrastructure you own. That's the trade against Pusher: you swap a monthly bill for operational responsibility.
Soketi: The Catch in 2026
Soketi is an open-source, Pusher-compatible WebSocket server built on uWebSockets.js (a C library ported to Node.js, which makes it very fast). For years it was the go-to budget pick: run it on a $5 to $10 instance and get effectively unlimited connections and messages, where the equivalent Pusher plan would cost $49 for just 500 connections. On raw price-per-connection, Soketi has always won.
Here's the part most comparisons won't tell you, and it's the most important fact in this whole post. As of 2026, Soketi's maintenance is a concern, and that's not speculation. The maintainers say so directly. Their own documentation describes release and maintenance frequency as based on available time that's "tight as hell," and openly notes that maintenance issues have caused infrequent updates and infrequent support.
That changes the calculation. A Pusher-compatible server that's blazing fast and free but slowly maintained is fine for a side project where you can absorb the risk. For something you're betting a business on, leaning on a server whose maintainers have flagged their own limited bandwidth is a different proposition. And the kicker: Reverb now does almost everything Soketi did (Pusher protocol, self-hosted, free, fast), but with the entire Laravel core team behind it and first-party integration. The main reason to pick Soketi over Reverb in 2026 is if you specifically want a Node-based server in a non-Laravel-centric stack. Inside a Laravel app, Reverb has quietly taken Soketi's lunch.
Head to Head
Cost at a small scale (say 500 concurrent connections): Pusher is $49/month. Reverb is the price of a $10 VPS. Soketi is the price of a $5 to $10 VPS. Self-hosting wins by a wide margin the moment you can run a server.
Cost at a larger scale (5,000+ connections): Pusher runs into the hundreds per month and keeps climbing. Reverb and Soketi cost the same VPS plus a Redis instance, a fraction of the hosted price, but now you're managing horizontal scaling yourself. Managed Reverb on Laravel Cloud sits in between: more than a raw VPS, less than Pusher, and if you're already eyeing Cloud, the $5 plan with spend caps and scale-to-zero keeps the floor low.
Operational burden: Pusher is zero. Managed Reverb (Cloud) is near zero. Self-hosted Reverb and Soketi both require you to run, tune, monitor, and scale a long-running process.
Maintenance confidence: Reverb and Pusher are actively, professionally maintained. Soketi has the open maintenance concern above.
Laravel integration: Reverb is first-party and tightest. Pusher and Soketi are Pusher-protocol compatible, which is close, but Reverb is the one the framework ships with and the docs assume.
My Recommendation
For most Laravel apps in 2026, start with Reverb. It's first-party, it's free, the database driver means you don't even need Redis early on, and a single instance handles thousands of connections on a cheap server. You'd have to have a specific reason not to use it.
If you don't want to run any infrastructure and you'd rather pay for it, you've got two clean options. Managed Reverb on Laravel Cloud keeps you in the Reverb ecosystem with no ops. Pusher makes sense if you want a battle-tested hosted service with the broadest SDK support and you're early enough that the connection count keeps you in the cheaper tiers.
Pick Pusher over managed Reverb when you need the SDK breadth for non-web clients, or you want a vendor with a long track record and enterprise SLAs. Pick managed Reverb when you're a Laravel shop that wants the lowest hosted cost and tightest framework fit.
I'd be cautious about starting a new production project on Soketi in 2026. The technology is solid and fast, but the maintainers' own note about limited upkeep, combined with Reverb now covering the same ground with first-party backing, makes it hard to recommend over Reverb for new Laravel work. If you're already running Soketi happily, there's no fire drill. But for a fresh build, Reverb is the safer version of the same idea.
FAQ
Can I switch between these later without rewriting?
Mostly yes, and that's the upside of all three speaking the Pusher protocol. Your Laravel broadcasting code and Echo config stay the same; you change connection credentials and host settings. Moving from Pusher to Reverb, or Soketi to Reverb, is a config and infrastructure task, not an application rewrite. That makes "start simple, move later" a viable strategy.
Do I need Redis for Reverb?
Not anymore, for small-to-medium apps. Reverb's database driver lets it coordinate through your existing MySQL or Postgres, so you can skip Redis entirely early on. You'll want Redis once you scale horizontally across multiple Reverb servers or push into very high connection counts (10,000+), where it's the recommended backend.
How many connections can one Reverb server handle?
A single Reverb instance handles thousands of concurrent connections, with the exact ceiling depending on your server's resources and tuning (open file limits matter a lot here). Past what one box can hold, you scale horizontally with Redis pub/sub and a load balancer. For context, Soketi reports holding 500 active high-traffic connections on a 1GB, 1-CPU machine, and Reverb is in the same class.
Is Pusher still worth paying for?
When you value zero operations and broad SDK support over cost, yes. Pusher's advantage is that you never run anything and it works across many platforms and languages. The downside is purely price: connection-based tiers get expensive fast, and a chatty app burns message quota quickly. If you have the ops capacity to run Reverb, the math usually favors self-hosting.
What about Ably or other alternatives?
Ably is another hosted option with stronger delivery guarantees (exactly-once, message history, state recovery) and is worth a look for mission-critical messaging where dropped messages aren't acceptable. But it's not Pusher-protocol native in the way these three are, so it's a bigger integration lift inside Laravel. For most Laravel real-time features, the Reverb-Pusher-Soketi triangle covers the decision.
Wrapping Up
The honest 2026 answer is that Reverb won the default-choice slot, and for good reasons: first-party, free, fast, and no longer even requiring Redis for smaller apps. Pusher remains the right call when you'll pay to never touch infrastructure, especially via managed Reverb if you want to stay in the Laravel ecosystem. And Soketi, once the obvious budget pick, now carries a maintenance question that Reverb sidesteps entirely. Start with Reverb, reach for a hosted option when ops isn't where you want to spend time, and treat the Pusher protocol compatibility as your insurance policy to change your mind later.
If you're planning real-time features for a Laravel app and want help choosing and setting up the right WebSocket layer, let's talk.
Top comments (0)