My app is using very simple websocket comms. It works perfectly in local, but on Qovery it won’t make a connection.
I’ve read that websocket has issues with modern load balancers and these types of layers.
Does websocket work on Qovery? Thanks!
Hi @eriksingleton, welcome to the Qovery community 
Qovery does not support other protocols than HTTPS today. But Qovery v2 (announced yesterday in beta) will support WebSocket. You can register for the beta if you are interested or wait for the final release for September 2021.
Thank you Roman. Hoping to hear back about my beta application soon. Thanks!
1 Like
Hi @rophilogene 
In the current UI I do see advanced options but the only protocol I can choose is HTTP.
Is WS still on the table for the near future or rather postponed?
Yes it is still planned but I don’t have an estimated time at the moment. I will see with our product team
Cool, thanks for the uber quick response 
Would really be a handy feature since the framework I am currently switching to (colyseus.io) heavily depends on WS.
Hi @rophilogene - any news on this would be much appreciated 
Hi @hatala91 , from what I know, I don’t think it is yet supported. Poke @Florian_Lepont @Pierre_Mavro
Hi,
It’s not supported yet, I let the product team prioritize it. By the way, if this kind of feature is really important for you, please add/vote for it: https://roadmap.qovery.com/
Thanks
Much appreciated! I added a feature idea re. this to the roadmap: WebSockets | Frill.co
1 Like
Thank you @hatala91 - we’ll prioritize this feature (which is an important one).
Hello @rophilogene, @Pierre_Mavro
Any workaround available for now so our Ruby 2.6.9 application is able to support websocket connections where our webserver is managed on Qovery?
Are we able to point an API gateway to our web server to manage the websocket connection?
Any third party product that we can use to accomplish this?
Thanks!!!
2 Likes
Would love to see this as well. Our app heavily relies on websockets and I didn’t knew this limitation beforehand. I will have to rethink now. I upvoted for this in the roadmap board, but there’s like only 2 votes
@r4881t let me one week and I will find you a valid production ready workaround.
1 Like
Hello @rophilogene - Sorry to bump this up again. But want to check on when can we realistically expect this?
For now, we have deployed our app on AWS Natively and it’s not a blocker, so I am simply curious to know if its like couple of weeks or couple of quarters away.
Hello @rophilogene - circling back to see if this will be picked up anytime soon. Still shows in product backlog in the roadmap.
Hi @r4881t , let me return to you on Monday since it’s normally done. I come back to you. Sorry for the delay. cc @Erebe
1 Like
Hi @r4881t , WebSocket is supported. However, the default timeout is set to 60 seconds. So it means that if your WebSocket connection is idle for 60 seconds, then the connection will be dropped. To prevent this, we’ll add two new advanced settings parameters for next week.
-
nginx.ingress.kubernetes.io/proxy-read-timeoutand nginx.ingress.kubernetes.io/proxy-send-timeout
I will keep you posted once it’s done.
3 Likes
The fact that it’s supported is great. We can have a workaround against the 60s timeout by doing a ping pong every 30-45 sec or so
It’s a valid solution until the option is available 