DEV Community: Hibira

Laravel Broadcasting: run Reverb yourself, or use a hosted service?

Hibira — Sat, 07 Nov 2026 11:32:44 +0000

Laravel Broadcasting gives you two good ways to push events to browsers. You can run Laravel Reverb, the WebSocket server the Laravel team released with Laravel 11, or you can point the pusher driver at a hosted service such as Pusher or Hibira. Both speak the Pusher protocol, and both work with Laravel Echo and pusher-js. Your events, channels and routes/channels.php don't change.

So the question isn't which one your code supports. It's who runs the WebSocket server.

What running Reverb asks of you

Reverb is a long-running PHP process built on an event loop. Getting it working locally is one command:

php artisan install:broadcasting
php artisan reverb:start

Production takes more:

A process manager. Reverb has to stay up, so it runs under Supervisor or systemd and restarts on deploys.
TLS and a proxy. Browsers need wss://, so Reverb usually sits behind Nginx or a load balancer that terminates TLS and upgrades the connection.
Server limits. Each connection is an open file. You'll raise the open-file limit, and past about a thousand connections the Reverb docs recommend the ext-uv event loop.
Scaling out. One Reverb process handles a lot, but more than one server means turning on Reverb's Redis-based scaling and putting a load balancer in front.
Watching it. Reverb reports to Laravel Pulse. You'll still want alerts for when the process dies or connections spike.

None of this is unusual if you already run your own servers. It's the same work as any other daemon.

What a hosted service asks of you

With a hosted Pusher-compatible service you set a few values in .env and keep using the pusher driver:

BROADCAST_CONNECTION=pusher
PUSHER_APP_ID=your-app-id
PUSHER_APP_KEY=your-app-key
PUSHER_APP_SECRET=your-app-secret
PUSHER_HOST=ws.hibira.io
PUSHER_PORT=443
PUSHER_SCHEME=https

You don't operate a WebSocket process or its TLS yourself, but you still need to choose a plan sized for peak connections and deliveries. In exchange, you pay a monthly fee once you outgrow the free tier, your events pass through a third party, and you live with the plan's limits.

Side by side

	Reverb on your servers	Hosted service
Cost	Server time and your time	Free tier, then a monthly plan
Setup	Process manager, TLS, proxy, limits	`.env` values
Scaling	Redis scaling and a load balancer	The provider's job
Data path	Stays on your infrastructure	Passes through the provider
Extras	Pulse cards	Depends on the provider: dashboards, webhooks, push notifications
Migration / lock-in	You operate the infrastructure	Compatible SDKs reduce migration work; features and limits may differ

How to choose

Run Reverb when:

You already operate servers with a process manager and monitoring, and one more daemon is little extra work.
Events must not leave your infrastructure.
Your traffic is modest and in one region, close to your servers.

Use a hosted service when:

You deploy to a platform where long-running processes are awkward (serverless, some PaaS plans).
Nobody on the team wants to be paged for the WebSocket server.
Your users are far from your servers. A WebSocket server near them shortens every event, even if your app stays where it is.
You want what sits around the server: a debug console, usage per app, webhooks, push notifications to phones.

You can change your mind later

The shared protocol reduces migration work, but it does not make providers identical. Check your Laravel version and Echo configuration, channel types (including encrypted and cache channels), client events, webhooks, usage limits and peak concurrent connections before switching. Hosted removes server operations from your team; choosing an adequate plan is still capacity planning.

Because both speak the same protocol, moving between them is configuration, not code. Going from Reverb to a hosted service means switching BROADCAST_CONNECTION to pusher, setting the PUSHER_* values, and changing Echo's broadcaster from 'reverb' to 'pusher' with the same host options. Going the other way is the reverse.

Many teams start hosted to ship quickly and move to Reverb once traffic is predictable, or start on Reverb and move to hosted when the ops work stops being worth it. Either path is fine.

If you choose hosted, the Laravel guide has the full setup for Hibira, and the free plan covers development and small apps.

Originally published on the Hibira blog. Hibira is a hosted, Pusher-compatible WebSocket service with servers in Hong Kong; the Free plan needs no card.

Realtime in Asia: where your WebSocket server is matters

Hibira — Sat, 07 Nov 2026 11:32:41 +0000

A chat message, a price tick or a "someone is typing" indicator feels instant when it arrives within about a tenth of a second. Most of that budget goes to the network, and most of the network time is set by one thing you choose: where the WebSocket server is.

Distance sets the floor

Light in optical fibre covers about 200 km per millisecond, roughly two-thirds of its speed in a vacuum. A round trip to a server 1,000 km away therefore takes at least 10 ms, before any routing, queuing or processing. Real cables don't follow the great circle and real routers add delay, so measured round trips are often two to four times this floor: we measured about 30 ms from Hong Kong to Taipei, against a floor of 8 ms.

Here is the floor from Hong Kong, where Hibira runs today (AWS ap-east-1), to cities across the region:

From Hong Kong to	Great-circle distance	Minimum round trip
Taipei	810 km	8 ms
Manila	1,120 km	11 ms
Bangkok	1,730 km	17 ms
Seoul	2,090 km	21 ms
Singapore	2,590 km	26 ms
Tokyo	2,880 km	29 ms
Jakarta	3,270 km	33 ms
Ashburn, Virginia (US East)	13,090 km	131 ms

These are physics, not benchmarks: no network can beat them, and yours will be slower. The last row is there for scale. Many US services run their realtime infrastructure in US East; Pusher's default cluster, mt1, is there too. Pusher does offer clusters in Asia, so if you're on Pusher, check which cluster your app was created in.

Why it matters more for realtime than for web pages

A web page pays the round trip a few times while it loads. A realtime feature pays it on every interaction:

Typing indicators and cursors send client events many times a second; a slow round trip makes them lag behind the user.
Chat goes from one user to your server, to the WebSocket service, and out to everyone else. Every leg adds its distance.
Presence (who's online) updates when members join and leave; slow updates show people as online after they've left.
Reconnects after a phone switches networks cost a TLS handshake plus subscriptions, several round trips in a row.

Count every leg

When your backend publishes an event, it travels:

from the user's action to your backend,
from your backend to the WebSocket service's HTTP API,
from the WebSocket service to every subscribed client.

Legs 1 and 3 depend on where your users are. Leg 2 depends on where your backend is. A backend in Tokyo publishing through a WebSocket service in Virginia crosses the Pacific twice for an event between two users in Taipei. Put the WebSocket service near your users, and if you can, put your backend near it.

Measure it yourself

What this test measures: pusher:ping/pusher:pong measures an already-established WebSocket round trip to the realtime endpoint, not publish-to-subscriber latency or connection setup time. It excludes your backend, event fan-out and browser rendering. Compare multiple runs from representative networks (including mobile), and track the median and p95; DNS, TLS, routing and congestion can change the result.

Tables are a starting point; your users' networks are what count. The Pusher protocol has a ping message that the server answers immediately, so you can time the round trip without publishing anything. Save this as ping.mjs and run it with Node.js 22 or newer (which has WebSocket built in):

// node ping.mjs YOUR_APP_KEY [host]
const [key, host = 'ws.hibira.io'] = process.argv.slice(2);
const ws = new WebSocket(`wss://${host}/app/${key}?protocol=7&client=js&version=8.4.0`);
const times = [];
let sent = 0;

const ping = () => {
  sent = performance.now();
  ws.send(JSON.stringify({ event: 'pusher:ping', data: {} }));
};

ws.onmessage = (msg) => {
  const { event } = JSON.parse(msg.data);
  if (event === 'pusher:pong') times.push(performance.now() - sent);
  if (event !== 'pusher:connection_established' && event !== 'pusher:pong') return;
  if (times.length < 20) return void setTimeout(ping, 250);
  times.sort((a, b) => a - b);
  console.log(`best ${times[0].toFixed(1)} ms, median ${((times[9] + times[10]) / 2).toFixed(1)} ms`);
  ws.close();
};

Run it from where your users are: a cloud server in each country you serve, or a colleague's laptop on a home connection. The median is the number to compare; the best shows how close the route gets to the floor. Mobile networks add their own delay on top, so test on a phone hotspot too.

For a view from real users, time how long pusher-js takes from connecting to connected and send it to your analytics with the user's country.

What we're doing about it

Hibira runs in Hong Kong today because it sits near the middle of East and Southeast Asia. Tokyo is the next region we're preparing, then Singapore. Apps will stay pinned to one region, so you'll pick the one closest to most of your users.

If you'd like to see the numbers for your own users before you switch, the free plan is enough to run the script above against your own app.

Originally published on the Hibira blog. Hibira is a hosted, Pusher-compatible WebSocket service with servers in Hong Kong; the Free plan needs no card.

Add realtime WebSockets with Claude Code in ten minutes

Hibira — Sat, 07 Nov 2026 11:22:16 +0000

Adding realtime to an app is mostly plumbing: create credentials, put them in the right env file, configure a client library, authorize private channels, and then check that an event actually arrives. That's exactly the kind of work an AI coding agent does well, as long as it can reach the service. The Hibira MCP server gives it that reach.

This post uses Claude Code. Cursor, VS Code, Claude and ChatGPT work the same way; the MCP server page has the setup for each.

What the agent can do

Through the Model Context Protocol, Hibira offers nine tools. The agent can read your plan and apps, create and update apps, read usage, publish a test event, watch the debug console, and fetch the integration guide for your framework with your app's ID and key filled in. It can't delete apps or rotate secrets, and it never sees an existing app's secret.

Step 1: add the server

You need a Hibira account; the free plan is enough. In your project folder, run:

claude mcp add --transport http hibira https://hibira.io/mcp

The first time Claude Code uses the server, it opens a Hibira page in your browser. Sign in, choose read only or read and write, and approve. If it doesn't open on its own, run /mcp in Claude Code and choose to authenticate the hibira server. Setting up a new app needs write access.

Step 2: ask for what you want

Be specific about your stack and where you'll run it. For a Laravel app with a Vite front end:

Add Hibira realtime to this Laravel app. Create an app called "shop-dev" that allows http://localhost:5173, put the keys in .env, set up Laravel Echo, and broadcast OrderShipped on a private orders channel.

What happens next is the agent's own plan, but it usually goes like this:

get_account to see the plan and the WebSocket host.
create_app with the name and allowed origin. The secret comes back once, and the tool tells the agent to write it straight into your git-ignored .env.
get_integration_guide for laravel, which returns the Echo configuration, the .env keys and the steps for private channels, with your values filled in.
Edits to .env, config/broadcasting.php, resources/js/echo.js and routes/channels.php, and a new broadcast event.

Review the diff as you would any other change. The edits are ordinary Laravel; nothing in your code depends on the agent afterwards.

Step 3: prove an event arrives

Publishing is not the same as delivery. Seeing an event in watch_debug_events confirms that Hibira observed the publish or subscription, but it does not prove that a specific browser received and handled the event. Verify the client-side handler with a real subscriber and, for important state, confirm it again through your application's API.

This is where the debug console earns its keep. Ask:

Open the app in the browser, then send a test OrderShipped event to private-orders.1 and tell me whether a subscriber received it.

The agent calls send_test_event, which publishes like your server would, and watch_debug_events, which listens to the app's debug console for up to 30 seconds and reports connections, subscriptions and messages. If nothing was subscribed, it can see that too, which usually points at the auth endpoint or the allowed origins.

On the Free plan the debug console shows connections, subscriptions and published messages; paid plans add client events, webhooks and errors.

Day-to-day questions

Once connected, the server is useful beyond setup:

"How close are my apps to their daily message limit?" uses get_usage.
"Why are browsers on staging.example.com refused?" uses get_app to read the allowed origins, and update_app to fix them if you agree.
"Turn on client events for shop-dev so typing indicators work" is one update_app call.

Keeping it safe

Understand what the agent can see. create_app returns a new app secret once to the connected agent so that it can write your local configuration; existing secrets are not returned by read tools. That one-time exposure is still access to a credential: use a trusted agent, review its changes, keep secrets out of browser bundles and commits, give the minimum necessary scope, and revoke an agent token when it is no longer needed.

Read only when you can. Grant read and write while you set things up, and read only for everyday questions.
Tokens for agents without a browser. CI jobs and remote agents can use a personal access token instead of signing in. Make one on the AI agents page, limit it to one app, and give it an expiry date:

claude mcp add --transport http hibira https://hibira.io/mcp \
  --header "Authorization: Bearer hkb_pat_..."

Revoke at any time. The AI agents page lists every connected agent and token; revoking one takes effect immediately.
Test events are real messages. They count toward your plan's daily limit like any other publish, and the server allows a few per second per account.

Try it

Sign up for the free plan, add the server, and ask your agent to wire up the framework you use. If it gets stuck, the integration guides show the same setup by hand.

Originally published on the Hibira blog. Hibira is a hosted, Pusher-compatible WebSocket service with servers in Hong Kong; the Free plan needs no card.