Link Robins Warble — Realtime that works on Shared Hosting

Karl · 2026-07-03T01:36:03+00:00

Your forum, live. Warble is a hosted realtime service for Flarum: replies appear the moment they're posted, typing indicators, presence — no page refreshes. There's now a free tier, so you can put your forum live without a credit card. It's built around flarum/realtime, which does all the live UI. Warble simply runs the websocket server for you: install the free flarum-warble extension, paste one key from your linkrobins.com dashboard, and the connection is configured automatically — no hosts, ports, or daemons. Realtime's own settings (typing indicators, discussion-list updates, notification toasts) stay yours to tune. Free — your own dedicated realtime server, no card 100 concurrent connections Unlimited messages, never metered A dedicated endpoint of your own, not a shared pool One free app per account Idle free endpoints pause after 30 days with zero connections — your keys and address are kept, and one click brings them back. Paid — flat yearly pricing, unlimited messages; the tier is just a concurrent-connection cap: Starter: 250 concurrent connections @ $49/yr Growth: 1,000 concurrent connections @ $99/yr Max: 2,000 concurrent connections @ $179/yr Paid plans start with a 14-day free trial and never pause. For comparison: Pusher's free sandbox also stops at 100 connections, but caps you at 200,000 messages a day on shared infrastructure — Warble's free tier is a dedicated server with no message cap at all. And where Pusher's entry paid plan is $49 a month, Warble's is $49 a year. Outgrow 2,000 connections? Then you're ready to self-host — run flarum/realtime's stock bundled daemon on your own server. No lock-in, ever. Get started → linkrobins.com/warble Install: composer require linkrobins/flarum-warble

Karl

SpikeNit thanks for the detailed post. As far as I can see, you're the only one with this specific issue. Could you provide additional information to how your infrastructure is laid out? Maybe we can see from there.

SpikeNit

Karl can you be a little more specific as to what info you would like me to provide?

Karl

SpikeNit how is Flarum running on your setup? What's holding it, housing it, harboring it? This gives me a way to test it moving forward, as you're the only one I see this issue with lol.

SpikeNit

It's currently installed in a subdirectory on Hostinger Shared Hosting.

Karl

SpikeNit cPanel, Hestia? Database, etc.

SpikeNit

Hpanel, the database, php and flarum version is listed above in "Environment" section.

Karl

Thanks for the write-up, @SpikeNit — that's a textbook diagnosis and you nailed it.

What's happening: Flarum's realtime rebuilds the entire discussion, serialized with each connected recipient's permissions, and sends it to the realtime server on every reply. When you're logged in as admin, that serialization pulls in admin-only data — per-user GeoIP, moderator fields, SEO metadata — which tips the payload past the server's default request-size limit. The server returns a 413, and because your forum is on the sync queue driver the broadcast runs inside the reply request, so it surfaces as a 500 (the post already saved, which is why it's there on refresh). Log the admin out and there's no admin-permission payload to overflow — exactly what you observed.

Two things:

On my side — I'm raising the request-size limit on the Warble servers so these large discussion payloads go through. Ships to every tenant on the next rollout; nothing for you to change.
On your side, worth doing regardless — move off the sync queue driver. Realtime is meant to broadcast in the background; sync runs it inline in the web request, which is what turns any broadcast hiccup into a 500. On shared hosting the reliable route is the database queue driver plus a cron running * * * * * php flarum queue:work --stop-when-empty (a Redis-backed worker is even better if your plan offers persistent Redis and long-running processes). Either way the broadcast leaves the request and the 500 is gone today — and it's the recommended realtime setup anyway.

I'll follow up here once the server-side change is live. There's a real upstream angle too: broadcasting the whole discussion per recipient is unbounded by design, so I'll raise a case with flarum/framework for a slimmer payload. Appreciate you isolating this so cleanly.

SpikeNit

Karl slowly re-emerges from the "safe place" he he

Karl

SpikeNit in the meantime, I can see about extending Redis into Warble, so you don't need further dependencies or complications. Make adoption easier. Would that be preferred?

SpikeNit

Karl hey, whatever is easier and not an imposition to you. Shared hosting is so limited and I/we so appreciate you providing this to us. I created a custom cron job with a bash script (hostinger AI assisted). I know I wasn't able to set it up as recommended on flarum documentation and I can't remember the reason why.

Karl

SpikeNit refrain from doing anything further then. Let me see what I can do to make this as seamless as possible for you and others. Make sure everything is flat as you had it before you pursued any of this. This way we can make sure adoption works clean slate ground zero.

SpikeNit

@Karl Just an update:

I moved from the sync queue driver to the built-in database queue, while keeping my existing every-minute scheduler. The previous user-facing 500 error is gone. I tested with both regular-member accounts replying to administrator-created discussions while the administrator was logged in. Replies submitted immediately, and the realtime update appeared on the administrator side. I also saw no new 413 entries in the logs after testing.

Karl

Status: FIXED, shipped, live-verified.

Server-side: REVERB_MAX_REQUEST_SIZE=256KB — live on all 6 tenants.
Extension: slim-broadcast fix shipped as flarum-warble v0.7 (v0.6 = the fix; v0.7 = the "may take a minute to activate" note). Sends a light realtime payload → removes the 413 at the source AND is cheap enough to run on the stock sync queue (no worker/Redis/cron).
Verified live E2E on BOTH sync and database queues — ₁.3 KB payload (no post stream) delivered through a real Warble server; on the DB queue the jobs queued to queue_jobs and drained via queue:work with the broadcast firing fine from the worker.

Had to recreate the extension on a NEW repo (GitHub issues). Mid-work, GitHub disabled karl-bullock/flarum-warble — every push 403'd ("repository is disabled"), even though the API reported it as normal and only that one repo was affected. On top of that, the retired linkrobins/flarum-warble name blocked transferring it into the org. So the extension was recreated at linkrobins/warble (org, public): full history + all tags pushed, the Composer package name kept as linkrobins/flarum-warble (repo name ≠ package name), and Packagist repointed. Customers' composer require/update is unchanged — fully seamless.

linkrobins/warblev0.7

navindra

Out of curiosity, what data is sent to Warble? I'm a little ignorant on realtime, etc, so just curious.

luceos

Realtime (used to, not sure it's still the case since adopted by core) generates a payload per user based on their permission for every user active on the socket. Admins will have all relations and information added in the json payload sent to the socket.

SpikeNit

Karl successfully completed version update (v0.7). No errors when posting. Everything works as designed.

Karl

7 Communities use Warble!

Just a quick update! No new issues have risen and I can see stable connections running on 7 Flarum Communities currently. (If you have any issues, please don't be shy to surface them. This is how things get refined 🙂)

dragsugur

Karl i really wanna try this and if it does what pusher already does and even more i wanna subscribe to paid plans because my active users are more than 100 and pusher hits the limit easiy. but im having the same problem as
foros and didnt try since then.

« Previous Page Next Page »