+1 to this. I didn't realize this wasn't supported, and unfortunately it seems like the type of feature where if we have to implement this ourselves, we'll actually end up fighting the Render environment rather than working with it. We could stand up our own nginx load balancer, but then we'd have to have multiple configured deployment targets with their own instances...at which point it makes one wonder how much ops burden we're saving.

We don't need this immediately but as others have shared, once we implement things like live chat / LLM based chat interactions, this will become a big issue so we're re-evaluating alternative platforms like fly and heroku which seem to offer better primitives out of the box.

We have an enterprise customer and want to purchase a lot of resources. Unfortunately this is a deal breaker for us.

Sidenote: For use with socket.io you dont need sticky sessions in 2024! You can disable the http-longpolling as described in the socketio docs: https://socket.io/docs/v4/using-multiple-nodes/

I need this to enable live inbox support for my backend. We need to keep minimum 2 servers for high availability but then can't use websockets without sticky sessions

This is a deal blocker for a lot of Python data science applications.

They do file uploads (which happens on one instance).

And then perform data analysis on a different one!

I sorely need this. I have a few services I'd like to have on Render but have to run on VPSs until this gets implemented.

This would be great!

Please implement this!

We need this as well for horizontal scaling!

When doing horizontal scaling for web socket servers, this is much needed for client file uploads.

This is needed for horizontally scaling web socket servers eg. socket.io