This page provides guidance and best practices for running WebSockets orother streaming services on Cloud Run and writing clients for suchservices.

WebSockets applications are supported on Cloud Run with no additionalconfiguration required. However, WebSockets streams are HTTP requests, which arestill subject to therequest timeout configured for yourCloud Run service, so you need to do the following:

• Increase therequest timeout period to the maximum duration youwould like to keep the WebSockets stream open, for example 60minutes.
• Ensure your clients are able toreconnect.
• Consider usingsession affinity forclients to reconnect as much as possible to the same instance.
• Don't enableHTTP/2 end-to-end.

Thoughsession affinity onCloud Run provides best effort affinity, new WebSockets requestscould still potentially connect to different instances, due to built-inload balancing. To solve this problem, youneed tosynchronize data between instances.

Note that WebSockets on Cloud Run are also supported if you are usingCloud Load Balancing.

Deploying a sample WebSockets service

Use Cloud Shell to quickly deploy a sample whiteboard service that usesWebSockets with Cloud Run:Deploy a sample

Or, if you want to deploy that sample whiteboard service manually:

1. Clone the Socket.IO repository locally using git command-line tool:

   gitclonehttps://github.com/socketio/socket.io.git

2. Navigate into the sample directory:

   cdsocket.io/examples/whiteboard/

3. Deploy a new Cloud Run service by building the servicefrom source code usingthe Google Cloud CLI:

   gcloudrundeploywhiteboard--allow-unauthenticated--source=.

4. After the service is deployed, open two separate browser tabs and navigateto the service URL. Anything you draw in one tab should propagate to theother tab (and vice versa) since the clients are connected to the sameinstance over WebSockets.

WebSockets chat sample full tutorial

If you want a full code walkthrough, additional code samples are available inthe topicBuilding a WebSocket Chat service for Cloud Run tutorial.

Best Practices

The most difficult part of creating WebSockets services onCloud Run is synchronizing data between multiple Cloud Runinstances. This is difficult because of the autoscaling and statelessnature of instances, and because of the limits forconcurrency andrequest timeouts.

Handling request timeouts and client reconnects

WebSockets requests are treated as long-running HTTP requests inCloud Run. They are subject torequest timeouts(currently up to60 minutesand defaults to 5 minutes)even if your application server does not enforce any timeouts.

Accordingly, if the client keeps the connection open longer than the requiredtimeout configured for the Cloud Run service, the client will bedisconnected when the request times out.

Therefore, WebSockets clients connecting to Cloud Run should handlereconnecting to the server if the request times out or the server disconnects.You can achieve this in browser-based clients by using libraries such asreconnecting-websocket or byhandling "disconnect" events if you are using theSocketIO library.

Billing incurred when using WebSockets

A Cloud Run instance that hasany open WebSocket connection isconsidered active, so CPU is allocated and the service isbilled as instance-based billing.

Maximizing concurrency

WebSockets services are typically designed to handle many connectionssimultaneously. Since Cloud Run supportsconcurrentconnections (up to1000 percontainer), Google recommends that you increase the maximumconcurrency setting for your container to a higher value than the default ifyour service is able to handle the load with given resources.

About sticky sessions (session affinity)

Because WebSockets connections are stateful, the client will stay connected tothe same container on Cloud Run throughout the lifespan of theconnection. This naturally offers a session stickiness within the context of asingle WebSocket connection.

For multiple and subsequent WebSockets connections, you can configure your Cloud Run service to usesession affinity, but thisprovides abest effort affinity, so WebSockets requestscould still potentially end up at different instances. Clientsconnecting to your Cloud Run service might end up being serviced bydifferent instances that do not coordinate or share data.

To mitigate this, you need to use an external data storage to synchronize statebetween Cloud Run instances, which is explained in the next section.

Synchronizing data between instances

You need to synchronize data to make sure clients connecting to aCloud Run service receive the same data from the WebSockets connection.

For example, suppose you are building a chatroom service using WebSockets andset yourmaximum concurrency setting to1000. If more than1000users connect to this service at the same time, they will be served by differentinstances, and therefore, they will not be able to see the samemessages in the chatroom.

To synchronize data between your Cloud Run instances, such asreceiving the messages posted to a chatroom from on all instances, you need anexternal data storage system, such as a database or a message queue.

If you use an external database such asCloud SQL, you can sendmessages to the database and poll from the database periodically. However,note that Cloud Run instancesdo not have CPU when the containeris not handling any requests. If your service primarily handles WebSocketsrequests, then the container will have CPU allocated as long as thereis at least one client connected to it.

Message queues work better to synchronize data betweenCloud Run containers in real-time, because the external messagequeues cannot address each instance to "push" data. Yourservices need to "pull" new messages from the message queue byestablishing a connection to the message queue.

Google recommends that you use external message queue systems such asRedisPub/Sub (Memorystore) orFirestore real-time updates thatcan deliver updates to all instances over connections initiated by the containerinstance.

Using Redis Pub/Sub

You can use theRedis Pub/Sub mechanism by creating a Redis instance fromMemorystore. If you areusing the Socket.IO library for WebSockets, you can use itsredisadapter.

In this Redis-based architecture, each Cloud Run instanceestablishes a long-running connection to the Redis channel that contains thereceived messages (using theSUBSCRIBE command). Once the containerinstances receive a new message on the channel, they can send it to theirclients over WebSockets in real-time.

Similarly, when a client emits a message using WebSockets, theinstance that receives the message publishes the message to the Redischannel (using thePUBLISH command), andother instances that are subscribed to this channel will receive thismessage.

If you want a full code walkthrough, additional code samples are available inthe topicBuilding a WebSocket Chat service for Cloud Run tutorial.