Realtime for Laravel: Reverb in your own Scaleway account

Realtime is new and in beta: it works and is measured on Scaleway, but its limits and defaults may still change.

Laravel broadcasting needs a WebSocket server, and a WebSocket server is the one thing serverless hosting is least built for: it holds connections open, while a serverless container is made to answer a request and go back to sleep.

Brewless now has Realtime: Laravel Reverb in a container of its own, in your own Scaleway account. This post explains how that works, where the limits are and why they are there, and the two things your frontend should do to live with them.

Can Laravel Reverb run on a serverless container?#

Yes, within limits. Scaleway Serverless Containers accept WebSocket connections, and each open connection counts as a request in flight until it closes. So a connection lives at most as long as the container's timeout, which is an hour at most, and one container holds as many connections as its concurrency allows, at most 80.

Those two numbers shape everything below. Within them, Reverb runs as it does anywhere else.

What Brewless sets up#

You switch it on per environment:

environments:
  production:
    realtime: true

On the next deploy Brewless does four things:

1. It makes a Serverless Container named realtime in the environment's namespace, next to web and worker, with a timeout of an hour and at most one instance.
2. It makes the Reverb app id, key and secret once, in a secret in your own Secret Manager. Brewless keeps the reference, never the values.
3. It gives your web, release and worker containers REVERB_APP_ID, REVERB_APP_KEY, REVERB_APP_SECRET, REVERB_HOST, REVERB_PORT=443 and REVERB_SCHEME=https, and BROADCAST_CONNECTION=reverb when your app sets no connection of its own.
4. It makes a DNS record for ws. in front of your app's own host and attaches that hostname to the container, which gets its own certificate. Until that address is ready, the container's own scw.cloud address is used.

All settings, with their defaults:

environments:
  staging:
    realtime:
      image: app        # or brewless (closed beta)
      memory: 512       # MB; 512 on your app's image, 256 on the Brewless image
      min: 0            # 0 sleeps while nobody is connected, 1 is always on
      timeout: 3600     # seconds a connection may stay open, 10 to 3600
      host: true        # ws.<your host>, a hostname of your own, or false

Straight to the container#

Browsers connect over wss:// to the Reverb container itself. Brewless is never a hop for your visitors, and Realtime does not change that.

There is no bunny.net pull zone in front of it either. A CDN earns its place by keeping responses at the edge, and a WebSocket has nothing to keep. A pull zone would only add a charge per connection minute and an idle timeout of its own.

What goes through the WebSocket stays between your app, your container and the browser. No hosted WebSocket service of another company is in that chain.

Two images to start from#

With image: app, the default, the Reverb container runs your app's own release image, started as php artisan reverb:start. It gets all of your app's variables plus the Reverb ones, and follows every deploy and every rollback. It needs laravel/reverb in your composer.json.

Warning

If your app has its own docker/entrypoint.sh, it has to hand other arguments on to php artisan, as the Brewless base entrypoint does. Otherwise the container starts the web server instead of Reverb.

With image: brewless, the container runs a small image Brewless maintains: a bare Laravel skeleton with laravel/reverb. It gets only the Reverb keys and the origins that may connect, and starts in 256 MB. This one is in closed beta; you request it in the console, on the Realtime page of an environment.

The cache that would keep your database awake#

php artisan reverb:restart works by putting a timestamp in the cache. A running Reverb server looks for it every five seconds, and restarts when it finds a newer one.

That is fine with Redis. With the cache in the database it is a query every five seconds, all day. A Scaleway Serverless SQL Database falls asleep five minutes after its last query, so a Reverb container with the database cache would keep it awake, and billed, all month.

So unless your app's cache store is Redis, Brewless starts the Reverb container on your app's image with CACHE_STORE=array (a cache in Object Storage would be asked just as often). The restart signal then never reaches it, and does not need to: every deploy replaces the container anyway. The Brewless image does not touch your database at all.

One hour, then reconnect#

A connection is closed when the container's timeout is up, an hour at most, and when a deploy replaces the container. Neither is a failure. pusher-js, which Laravel Echo uses for Reverb, connects again by itself, usually within a second.

What does not come back is what happened in between. Reverb sends an event to whoever is connected at that moment and keeps nothing for later. A browser that was reconnecting missed it.

The fix is the same as for a laptop that wakes from sleep: when the connection comes back, ask your app for the current state.

import Echo from 'laravel-echo';
import Pusher from 'pusher-js';

window.Pusher = Pusher;

window.Echo = new Echo({
    broadcaster: 'reverb',
    key: import.meta.env.VITE_REVERB_APP_KEY,
    wsHost: import.meta.env.VITE_REVERB_HOST,
    wsPort: import.meta.env.VITE_REVERB_PORT ?? 80,
    wssPort: import.meta.env.VITE_REVERB_PORT ?? 443,
    forceTLS: (import.meta.env.VITE_REVERB_SCHEME ?? 'https') === 'https',
    enabledTransports: ['ws', 'wss'],
});

// After every reconnect, not the first connect: load what may have been missed.
let connectedBefore = false;

window.Echo.connector.pusher.connection.bind('connected', () => {
    if (connectedBefore) {
        window.dispatchEvent(new Event('echo:reconnected'));
    }

    connectedBefore = true;
});

A page then listens for that event and fetches what it shows:

window.Echo.private('orders').listen('OrderShipped', (event) => {
    showOrder(event.order);
});

window.addEventListener('echo:reconnected', async () => {
    const response = await fetch('/orders/latest', { headers: { Accept: 'application/json' } });

    showOrders(await response.json());
});

The first half of that file is what php artisan install:broadcasting writes. Brewless gives the build VITE_REVERB_APP_KEY, VITE_REVERB_HOST, VITE_REVERB_PORT and VITE_REVERB_SCHEME, so it works without changes. Because those values differ per environment, they are part of what marks a built image: an image built with the keys of staging is never reused for production.

Tip

Private and presence channels are authorised by your own app at /broadcasting/auth, an ordinary request to your web container. Nothing about that changes on Brewless.

A Content-Security-Policy#

If your app sends a Content-Security-Policy, the browser refuses a WebSocket to an address that connect-src does not name. Add the Reverb address:

Content-Security-Policy: connect-src 'self' wss://ws.example.com

Check it in a browser, not with curl: curl ignores the header, so a page can look fine there and still have no live updates for every visitor.

What it costs, and when it sleeps#

The Reverb container is billed by Scaleway like your other containers, per second for processor and memory, on your own Scaleway bill. At Scaleway's list prices in fr-par before VAT (November 2026), €0.0000100 per vCPU-second and €0.0000020 per GB-second:

Always on is min: 1; sleeping when idle is min: 0.

With min: 0, the default, the container scales to zero after the last browser disconnects. The first visitor after a quiet spell waits for it to start; pusher-js keeps trying until it is up.

One thing to keep in mind: an open tab is an open connection. While somebody leaves your dashboard open, the container runs and is billed, also when nothing is being sent.

The limits#

For live notifications, a dashboard that updates, or a status page for a team, that is plenty. For thousands of open connections per app, it is not, and it is better to know that now.

The settings are in the brewless.yml reference, and the overview is on the Realtime page. Why other things keep a Laravel container awake is in Why your Laravel container never scales to zero.