Real-time features in a web app: WebSockets, Laravel Reverb or a hosted service?

How should you add real-time features to a web app?

First decide which screens truly need instant updates. For many dashboards, polling the server every few seconds is enough. For chat, presence and updates people wait for, use WebSockets: in a Laravel app, that means broadcasting events to self-hosted Laravel Reverb or to a hosted service such as Pusher or Ably. Reverb costs server time and upkeep; hosted services cost a monthly fee and remove the scaling work.

Whichever you pick, the hard parts are the same: authorizing who can listen, sending the right data, and recovering cleanly when the connection drops. Our Laravel development team plans those three before choosing a provider.

Which features actually need real time?

• Chat and support conversations, where a delay feels broken.
• Presence and typing indicators, such as showing who else is viewing a record.
• Status changes people wait for, like an order moving to ready, a payment clearing or a long export finishing.
• Shared screens, such as a kitchen display or dispatch board, where several people act on the same data.

A sales dashboard that changes a few times an hour does not need any of this; refreshing it every minute is simpler and cheaper.

There are also two browser technologies to know. WebSockets carry messages both ways. Server-sent events only go from server to browser, which suits simple live feeds, but MDN warns that without HTTP/2 browsers allow only 6 such connections per domain across all tabs (MDN: EventSource). Most business apps that need two-way features choose WebSockets.

How does real time work in a Laravel app?

Laravel calls this event broadcasting. Your code fires an event on the server, Laravel sends it to a broadcasting service, and the browser receives it through Laravel Echo. Laravel ships with drivers for Reverb, Pusher Channels and Ably, according to the broadcasting documentation.

Two details shape the build. Broadcasting runs through queued jobs so pages stay fast, so you need a queue worker running in production; our guide to background jobs and queues covers that part. And you can mark an event to broadcast only after the database transaction commits, so a browser never fetches a record that does not exist yet.

What does self-hosting Laravel Reverb involve?

Reverb is Laravel's own WebSocket server. It runs as a long-running process, so it needs more care than a normal web request:

• A process manager such as Supervisor to keep it running, and a reverb:restart step in every deployment, because code changes are not picked up until it restarts.
• A reverse proxy such as Nginx in front of it, handling the secure connection and passing WebSocket traffic through.
• Raised limits. Each connection is an open file. The default event loop is typically limited to 1,024 open files, so the docs advise installing the ext-uv extension before you go past roughly a thousand concurrent connections (Laravel Reverb docs).
• A plan to scale. Several Reverb servers can share connections through Redis publish and subscribe, behind a load balancer.
• Monitoring, for example Reverb's Laravel Pulse integration, which tracks connections and messages.

None of this is unusual for a team that already runs servers, but it is ongoing work, not a one-off setup. It sits well alongside our cloud and DevOps work for the rest of the app.

What do hosted services like Pusher and Ably charge for?

Hosted services run the WebSocket servers for you. Pricing models differ, so check them against your own traffic:

• Pusher Channels prices plans by concurrent connections and daily messages. Its free Sandbox plan allows 100 concurrent connections and 200,000 messages per day, and the first paid plan is listed at $49 per month for 500 connections, per the Pusher Channels pricing page in November 2026.
• Ably bills by monthly active users and lists a free plan for 500 of them, with paid plans above that, per the Ably pricing page.

Estimate your peak, not your average: a kitchen display open all day counts as a connection all day.

How do the options compare?

How do you keep private updates private?

Use private channels for anything tied to an account. Before a browser can listen on a private channel, Laravel makes an HTTP request to your app, and your authorization callback decides whether this user may listen. Presence channels work the same way and also share a small set of user details with others on the channel.

• Name channels after the record, such as one channel per order, and check ownership in the callback.
• Broadcast IDs and short status values, then let the page load full details from your API, where your normal permissions apply.
• With Reverb, restrict the allowed origins so only your own domains can connect.

What happens when the connection drops?

Connections drop on trains, in lifts and when laptops sleep. Messages sent while a user is offline are simply missed, so design for it:

• When the connection comes back, reload the current state from the API instead of trusting the last message received.
• Show a small connection status indicator; Laravel Echo exposes the connection state for this.
• Avoid duplicates: if a user's own action already updated their screen, broadcast the event only to others.
• Keep the page useful without the socket, so a failure means slower updates, not a broken screen.

Real-time features are often part of larger systems, such as portals or dispatch tools, which our custom software development team builds end to end.

Frequently asked questions

Last updated November 13, 2026