Skip to main content

Introduction

Laravel Cloud WebSocket clusters speak the Pusher protocol, so you may connect to them using Pusher’s official SDKs. You can publish events from PHP, JavaScript, Python, Go, Ruby, and Java applications using Pusher’s HTTP SDKs, then receive those events using Pusher’s WebSocket SDKs. You do not need a Pusher account.

Connection variables

To get started, create a WebSocket cluster, attach a WebSocket application to your environment, and redeploy. Laravel Cloud will inject the following variables into JavaScript, Python, Go, Ruby, and Java applications, as well as PHP applications that don’t use Laravel or Symfony:
Since these variables point to your Laravel Cloud cluster rather than Pusher’s hosted service, you will need to pass PUSHER_HOST to each SDK. Laravel Cloud accepts HTTPS requests for publishing and secure WebSocket (wss) connections for subscribing, both on port 443. For PHP applications, Laravel Cloud writes these variables to an injected .env file, so your application is responsible for loading it. The PHP example below uses PHP dotenv to do so, while the remaining examples read their variables directly from the process environment. Laravel and Symfony applications receive REVERB_* variables instead. If you’re using one of those frameworks, follow the connection instructions for your framework.

Publishing events

Pusher’s HTTP SDKs publish events by sending signed requests from your server to your WebSocket application. Since these requests are signed with PUSHER_APP_SECRET, events should always be published from your server.

PHP

To publish events from PHP, install Pusher’s PHP HTTP SDK along with PHP dotenv:
Then, place the following script in your project’s root directory, next to the injected .env file and your vendor directory:
If your application already loads its .env file, you may remove the Dotenv call and use your existing configuration instead.

Node.js

To publish events from Node.js, install Pusher’s Node.js HTTP SDK:
Then, save the following script as publish.cjs and run it using node publish.cjs:
The pusher package is only used to publish events from your server. To receive events in the browser, use the separate pusher-js package, as shown in the JavaScript WebSocket client example.

Python

To publish events from Python, install Pusher’s Python HTTP SDK:
Then, create a client using the injected variables and trigger an event:

Go

To publish events from Go, install Pusher’s Go HTTP SDK:
The Go SDK expects the port to be included in its Host field, so the following example joins PUSHER_HOST and PUSHER_PORT together:

Ruby

To publish events from Ruby, add Pusher’s Ruby HTTP SDK to your application’s Gemfile and run bundle install:
Then, create a client using the injected variables and trigger an event:

Java

To publish events from Java, add Pusher’s Java HTTP SDK to your Maven dependencies:
Then, configure the client’s host and encryption settings and trigger an event:
You may notice that the example doesn’t configure a port. The Java HTTP SDK doesn’t offer a port setting; instead, it always uses the default HTTPS port of 443, which is the port Laravel Cloud listens on.

Receiving events

While the HTTP SDKs can only publish events, Pusher’s WebSocket SDKs hold open a persistent connection to your WebSocket application and receive events as they are published. The examples below use Pusher’s JavaScript and Java clients, though Pusher also offers WebSocket clients for other platforms, such as Swift and .NET.

JavaScript WebSocket client

To receive events in the browser, install Pusher’s JavaScript WebSocket SDK:
Then, create a client in your browser application. Replace the placeholder key and hostname below with the PUSHER_APP_KEY and PUSHER_HOST values from your attached WebSocket application:
The SDK requires a cluster option, but since wsHost is set and only the ws transport is enabled, mt1 is simply a placeholder and does not select a Pusher or Laravel Cloud region. The forceTLS option ensures the connection uses secure WebSockets. Your application key and hostname are safe to share with the browser. However, unlike Laravel applications, Laravel Cloud does not create frontend variables such as VITE_PUSHER_* for other stacks, so you will need to render these values into your frontend’s configuration or define them through your build tool yourself. Your PUSHER_APP_SECRET, on the other hand, should never leave your server, so take care not to expose your server’s full environment to browser code. Laravel Cloud automatically allows connections from your attached environments. If your browser application is hosted on another domain, add its URL (for example, https://frontend.example.com) to your WebSocket application’s Allowed origins before connecting.

Java WebSocket client

Pusher’s Java WebSocket SDK doesn’t send an Origin header, nor does it provide a way to set one. As a result, Laravel Cloud will reject its connections unless your WebSocket application’s Allowed origins is set to *.
Setting Allowed origins to * allows connections from any origin, including browsers on other sites. Anyone with your public application key will be able to subscribe to your public channels, so use private or presence channels for any data that requires access control.
Once your allowed origins are updated, add Pusher’s Java WebSocket SDK to your Maven dependencies:
Then, connect using your application’s key and WebSocket host and subscribe to the channel:
The CountDownLatch keeps this standalone example running so that it can continue listening for events. Within an existing application, you should tie the connection to your application’s lifecycle instead.

Private and presence channels

The examples in this guide use a public channel, which anyone may subscribe to without authorization. Private and presence channels, on the other hand, require your application to provide an authorization endpoint. This endpoint should authenticate the user, verify that they may access the requested channel, and then use your HTTP SDK to sign and return an authorization response. You will also need to configure your WebSocket client’s authorization options so that it calls this endpoint when subscribing. Pusher’s authorizing users documentation covers the authorization API for each SDK. Remember, your application secret should remain on your server; only the signed authorization response should be returned to the client.