Laravel Reverb | Laravel 13.x - The clean stack for Artisans and agents

Laravel Reverb brings blazing-fast and scalable real-time WebSocket communication directly to your Laravel application, and provides seamless integration with Laravel's existing suite of event broadcasting tools.
You may install Reverb using the install:broadcasting Artisan command:
Behind the scenes, the install:broadcasting Artisan command will run the reverb:install command, which will install Reverb with a sensible set of default configuration options. If you would like to make any configuration changes, you may do so by updating Reverb's environment variables or by updating the config/reverb.php configuration file.
In order to establish a connection to Reverb, a set of Reverb "application" credentials must be exchanged between the client and server. These credentials are configured on the server and are used to verify the request from the client. You may define these credentials using the following environment variables:
You may also define the origins from which client requests may originate by updating the value of the allowed_origins configuration value within the apps section of the config/reverb.php configuration file. Any requests from an origin not listed in your allowed origins will be rejected. You may allow all origins using *:
Typically, Reverb provides a WebSocket server for the application in which it is installed. However, it is possible to serve more than one application using a single Reverb installation.
For example, you may wish to maintain a single Laravel application which, via Reverb, provides WebSocket connectivity for multiple applications. This can be achieved by defining multiple apps in your application's config/reverb.php configuration file:
In most cases, secure WebSocket connections are handled by the upstream web server (Nginx, etc.) before the request is proxied to your Reverb server.
However, it can sometimes be useful, such as during local development, for the Reverb server to handle secure connections directly. If you are using Laravel Herd's secure site feature or you are using Laravel Valet and have run the secure command against your application, you may use the Herd / Valet certificate generated for your site to secure your Reverb connections. To do so, set the REVERB_HOST environment variable to your site's hostname or explicitly pass the hostname option when starting the Reverb server:
Since Herd and Valet domains resolve to localhost, running the command above will result in your Reverb server being accessible via the secure WebSocket protocol (wss) at wss://laravel.test:8080.
You may also manually choose a certificate by defining tls options in your application's config/reverb.php configuration file. Within the array of tls options, you may provide any of the options supported by PHP's SSL context options:
The Reverb server can be started using the reverb:start Artisan command:
By default, the Reverb server will be started at 0.0.0.0:8080, making it accessible from all network interfaces.
If you need to specify a custom host or port, you may do so via the --host and --port options when starting the server:
Alternatively, you may define REVERB_SERVER_HOST and REVERB_SERVER_PORT environment variables in your application's .env configuration file.
The REVERB_SERVER_HOST and REVERB_SERVER_PORT environment variables should not be confused with REVERB_HOST and REVERB_PORT. The former specify the host and port on which to run the Reverb server itself, while the latter pair instruct Laravel where to send broadcast messages. For example, in a production environment, you may route requests from your public Reverb hostname on port 443 to a Reverb server operating on 0.0.0.0:8080. In this scenario, your environment variables would be defined as follows:
To improve performance, Reverb does not output any debug information by default. If you would like to see the stream of data passing through your Reverb server, you may provide the --debug option to the reverb:start command:
Since Reverb is a long-running process, changes to your code will not be reflected without restarting the server via the reverb:restart Artisan command.
The reverb:restart command ensures all connections are gracefully terminated before stopping the server. If you are running Reverb with a process manager such as Supervisor, the server will be automatically restarted by the process manager after all connections have been terminated:
Reverb may be monitored via an integration with Laravel Pulse. By enabling Reverb's Pulse integration, you may track the number of connections and messages being handled by your server.
To enable the integration, you should first ensure you have installed Pulse. Then, add any of Reverb's recorders to your application's config/pulse.php configuration file:
Next, add the Pulse cards for each recorder to your Pulse dashboard:
Connection activity is recorded by polling for new updates on a periodic basis. To ensure this information is rendered correctly on the Pulse dashboard, you must run the pulse:check daemon on your Reverb server. If you are running Reverb in a horizontally scaled configuration, you should only run this daemon on one of your servers.
Due to the long-running nature of WebSocket servers, you may need to make some optimizations to your server and hosting environment to ensure your Reverb server can effectively handle the optimal number of connections for the resources available on your server.
Laravel Cloud offers fully managed WebSocket infrastructure powered by Laravel Reverb clusters, allowing you to scale and ship Reverb enabled applications without managing infrastructure.
Each WebSocket connection is held in memory until either the client or server disconnects. In Unix and Unix-like environments, each connection is represented by a file. However, there are often limits on the number of allowed open files at both the operating system and application level.
On a Unix based operating system, you may determine the allowed number of open fi