Support web sockets

[gsogol]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do * not help prioritize the request
  If you are interested in working on this issue or have submitted a pull request, please leave a comment

Tell us about your request
Ability for the automatic load balancer to support web sockets

Describe alternatives you've considered
Using Beanstalk and enabling web sockets support in application load balancer

[gsogol]

Just curious if there's an update. It's been over 16 months. Close to 200 people votes on this.

[nebbles]

Similarly, very keen to see even a brief word about where this is being prioritised from AWS team (@amitgupta85 please forgive the tag). Just to note (very selfishly), this is the one outstanding piece of functionality that prevents my team from migrating from Heroku, since our application uses websockets for GraphQL.

The top seven upvoted issues in this repo are all extremely desirable in my view, but this is the only one that outright blocks us from even experimenting with App Runner for our main app.

Top 7

[bnicholl]

Is there any update to this? My team wants to use App Runner for our streamlit applications, and this is a huge blocker for us

[gsogol]

I opened a support case, got the "No plans to support this". Isn't the idea to prioritize based on likes? You would think so but the team seems to be operating using their own prioritization and not Community.

[bnicholl]

Yea this seems like something a lot of people would need. Unfortunate they're not people their customers needs first.

[amitgupta85]

@gsogol @bnicholl @nebbles
We don't have native support for web sockets at this point. However, it is possible to place CloudFront and API Gateway in front of an App Runner service which has support for Web sockets.

For CloudFront, you can put a CloudFront distribution in front of a public App Runner service. For API Gateway, you have couple options

1. API Gateway in front of public App Runner service - You can use API Gateway HTTP proxy integration feature and put App Runner service behind an API Gateway. The traffic will flow from API Gateway -> public App Runner service.
   https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-create-api-as-simple-proxy-for-http.html

2. API Gateway in front of private App Runner service - Make the App Runner service private (accessible within a VPC) and use API Gateway VPCLink with HTTP proxy integration feature to put private App Runner service behind an API gateway. For VPCLink, you will have to set a NLB with targets as IP address of PrivateLink VPC endpoint. The traffic will flow from API Gateway -> NLB -> VPC endpoint -> private App Runner service. You can share the same API Gateway, NLB and VPC endpoint to access multiple private App Runner services so the cost of non App Runner infrastructure components (API Gateway, NLB and VPC endpoint) is shared as well as it is their one time setup and does not need to be repeated with every App Runner service - https://docs.aws.amazon.com/apigateway/latest/developerguide/getting-started-with-private-integration.html

[haversnail]

For CloudFront, you can put a CloudFront distribution in front of a public App Runner service.

IIRC I did this very thing for Server-Sent Events, but to no avail. While yes, CloudFront does support WebSockets, the fact that the Envoy proxy used by AppRunner limits requests to 30 seconds means that this point is moot.

+1 to the AWS team prioritizing this.

[wordiodev]

I guess the App Runner team is very short-handed, making me worried in thinking to host my application with it.

[henricook]

Updates here would be much appreciated AWS team. I've just finished moving all my apps to app runner, spun up a test environment and only now realise there's no web socket support. I moved from a more complex (to manage) ALB/EC2 setup that supported it, so I expected it to be supported here.

Basically, I now have to move off App Runner to something else after spending hours/days moving my apps here - it's super infuriating.

[henricook]

@amitgupta85 All my hopes are on your post to save lots of wasted work. I've put a Cloudfront distribution in front of my public app runner service URL - but my app still seems to be getting a 403 when trying to open a wss:// connection - have I missed something?

[amitgupta85]

We are taking a look at the CloudFront issue and will post updates soon. In the meantime, you can also try out the API Gateway option by following putting API Gateway in front of App Runner (as discussed above) and enabling web sockets on API Gateway - https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-websocket-api-integration-requests.html

[gsogol]

@amitgupta85 or you can prioritize web sockets in AppRunner and call it a day. Community over internal priorities should always take precedence 🤔

[henricook]

It's not actually just websockets that's failing on a cloudfront distribution in front of my public apprunner endpoint, it's any request. Are there any special settings required above a normal origin-using-the-public-url? Does it have to be a custom domain? (I'm using my awsapprunner.com subdomain currently)

[henricook]

I guessed my way through a Websockets API API Gateway setup, because your instructions are pretty vague. I used a $request.body.action route selection expression, and in the $default route I connected an HTTP PROXY integration to my awsapprunner.com URL. I deployed to a stage called 'Prod' which gave me a url like this:

https://a1ykizot66.execute-api.ap-southeast-1.amazonaws.com/Prod/@connections

I think that means I should expect
https://a1ykizot66.execute-api.ap-southeast-1.amazonaws.com/Prod/ping to return "Hello World"

to behave the same as https://gx6d3sumsa.ap-southeast-1.awsapprunner.com/ping which returns "Hello World"

.. which it does not. Although I've almost surely missed something because API Gateway is so complicated, any idea what?

[henricook]

For readers. I couldn't get this working with Cloudfront. Using the app runner domain it returned 404s/403s, after configuring a custom domain it only returned 502s.

Instructions are insufficient for API Gateway and I couldn't figure it out.

I've had to bail to Lightsail Containers (LC) until this gets sorted out but with barely any signs of life from the AppRunner team it seems unlikely.

Trade offs:

• No github integration
• LC lets you deploy images from your ECR but unfortunately doesn't have auto-hooks to deploy images on push, it requires a manual jiggle in the AWS UI.
• Also its logs don't integrate with Cloudwatch logs and are fairly cumbersome to use.

[haversnail]

@henricook thanks for sharing your solution here, I appreciate the details. 👏 FWIW, I also had to find another solution for my own WS/SSE-powered containerized app and ended up having to create an entire ALB + Fargate Service just to run it.

IMO it is very disappointing that this issue has remained open for so long, with so many upvotes, with so little communication/guidance from the AWS team. Although I was able to navigate around this issue for a personal project, the lack of WS support in AppRunner has caused our team at work to re-evaluate deploying our service on AWS entirely, as we are currently leveraging multiple cloud providers at the moment. I would think it would be in the AWS team's best interest to prioritize this request, as without it, GCP's Cloud Run will continue to siphon current and potential customers away from AWS. 😞

[pclokcer]

I am working since 2 week. I learned not supported. big mistake for aws 👎

[matteocontrini]

We don't have native support for web sockets at this point. However, it is possible to place CloudFront and API Gateway in front of an App Runner service which has support for Web sockets.

For CloudFront, you can put a CloudFront distribution in front of a public App Runner service.

@amitgupta85 I'm not sure I understand how CloudFront would solve this problem. If the App Runner load balancer doesn't support WebSockets, how would adding an additional layer in front of App Runner enable it? Could you clarify? Thanks!

[emeagenciadigital]

This is something that you already have on ELB , api gateway etc why not just activate it on app runner ? Currently app runner is extremely easy to use but a modern need of apps as real-time is put under appreaciated

[emeagenciadigital]

+1

I know I’m making noise but maybe that is what’s needed .

[pclokcer]

@emeagenciadigital I dont want use ELB. I want to configure as I want

[Harsh4999]

Is there any update on this any way around to use websockets with app runner without adding load balancer

[amitgupta85]

Thank you for having patience on this issue. We would like to get some feedback on maximum request timeout that you would like us to have for Web sockets support in App Runner.

[algoflows]

Still no word from the team, any updates on this?

[algoflows]

I just switched to cloud run. It works how apprunner should work

Will be following you shortly, have been hoping for any updates from the team but nothing from them.

[jwoodlee]

We have been prototyping this behavior but do not have a confirmed roadmap ship date.
Customers seeking this behavior today can use AWS Api Gateway as a front end to a private AppRunner

[henricook]

@jwoodlee Thanks for finally adding some light to this thread - can you please expand on how to use api gateway in front of a private app runner, or link to the docs?

[hariohmprasath]

2. private
Hi @henricook,
You can find some details in this thread and thanks for using App Runner:
#13 (comment)

[algoflows]

We have been prototyping this behavior but do not have a confirmed roadmap ship date. Customers seeking this behavior today can use AWS Api Gateway as a front end to a private AppRunner

How can you not have a target date, that screams to me that this isn't a priority on your roadmap. This feature is the most requested feature in your entire roadmap from user feedback. Unbelievable. We don't want to hack API gateway in front of the service, we've been asking for years for native socket support. Literally years.

Would the apprunner team please show us a feature request with more demand than this????

[dhavaln]

If it helps anyone, instead of waiting further we recently updated our Websocket logic to use AppSync Generic Pub/Sub over WebSocket, our use case was to only subscribe for data updates.

We are using AppRunner as our pre-prod environment, for a while Websocket not working was a non-issue, but more recently we had only two options 1) fix it 2) switch to EC2 or ECS. Using AppSync is not affecting our development and deployment process flow, plus it has low cost footprint.

[application: Angular JS 1.4.12 (outdated) and AppRunner NodeJS with ExpressJS]
https://docs.aws.amazon.com/appsync/latest/devguide/real-time-websocket-client.html

[ChihweiLHBird]

I thought AWS had "Customer Obsession", "Insist on the Highest Standards" and "Deliver Results"? lol

[algoflows]

Its apparent to me this team doesn't care about customers, doesn't follow their own AWS mantra of "Customer Obsession" as their communication is absolutely terrible and the delivery of web sockets, a feature that so many have been asking for years, has taken so long, I've long ago with many others I know moved to other services outside AWS. Good luck everyone, we'll have scaled two new startups by the time they deliver on this feature.

[temmyjay001]

This is ridiculous, almost 3 years, and no solution.

[algoflows]

Hey peeps, if you are looking an alternative to the big cloud providers who are unable to deliver on customer demands here's an alternative solution that has been working well for me. https://www.koyeb.com/

[hambro]

This is ridiculous, almost 3 years, and no solution.

I imagine Amazon is dragging out any decision and development for AppRunner, slowly asphyxiating it until they can sunset the service citing poor customer adoption rate, below expectations, blah blah.

For anyone coming from Google

If you want to use Django with websockets (django-channels), Flask with SocketIO, self served data science projects with streamlit, Jupyter notebooks, or anything with websockets:
Look further! AWS AppRunner will not work. Use koyeb, Heroku, GCP Cloud Run, that Raspberry PI you got in a drawer, whatever.

[backnol-aws]

Thanks for your patience as we've researched this feature. We've designed and built App Runner as a great place to run request/reply based workloads. It's not meant to support persistent connections like TCP. We suggest evaluating ECS/Fargate with an Application Load Balancer to address the needs of applications needing persistent connections.

[chai3]

@backnol-aws Thank you for the latest information.
But I think it's better to reopen issue and remove Just shipped in roadmap.

[psnehanshu]

As mentioned by @backnol-aws, supporting websockets is a non-goal for App Runner because it requires long running service, whereas it is meant only for serverless type workloads.

So it makes sense to close it and even remove it from roadmap.

[algoflows]

Epic fail, no consideration of what customers have been asking for. You've designed the service for what you think we want or need. You had an excellent opportunity to work with customers on a much requested feature and deliver a win for you, aws and everyone involved. Instead, the apprunner team took another route; It's bewildering how you just completely decided against servicing the most popular feature request. Wild stuff. Never in my life have I seen the most requested feature for a service just been shut down, isn't the entire premise of a business to service what your customers actually need and are asking for?!!?

[kosakt]

AppRunner is very suitable for meeting the many demands of frameworks such as Streamlit (which require WebSockets) in creating generative AI apps and simple operational apps. It would be a great waste not to implement it after making people wait so long, and I think it would be a disappointment.

[Tolulade-A]

It's crazy that apprunner doesn't support web sockets

[qcaudron-soundag]

I'll add to this thread just to say that :

• Fargate is more complicated, certainly; I have my app deployed there and behind an ALB, but I have huge issues with app load times. Three+ minutes just randomly before the app will run through ALB -- and it runs fine directly using the Fargate task's private IP, but I can't target that easily in Route53
• AppRunner would be just perfect, except it took me a good while to discover why my Streamlit app was hanging on load.

Supporting websockets would be a huge value prop for many of us. Thanks.

[Mugane]

Well why didn't you just say you wouldn't ever support websockets or long-running processes to begin with? What a thoroughly disrespectful waste of time. I for one will never recommend AWS for any cloud services again.

[dbish]

adding a note here for data for the apprunner PM. I started to use app runner to test and deploy a new service/app with flask, found this thread, and will not be using it. if it had websockets support I would have. initially seemed like an easier way to deploy a flask app, but nowadays websockets are pretty important for anything interacting in nearish real time, especially streaming responses or data back from things like an LLM.

[EliteXCoder1]

What a disappointment honestly. I spent so much time working on supporting web sockets for my app since using SSE will hold up a gunicorn worker for long periods of time and this is not ideal when scaling up. I wish I had saw this sooner because i wasted so much time. Funny, i can use SSE to serve a response from the server to the client, but I can't use web sockets?

[jigar87]

What a waste of time. I am currently in analysis mode to decide on which cloud provider to use for my clients. I deployed a public container like n8n to AWS App runner and Azure Container Apps. I was considering AWS for its better pricing...but after wasting 2 days on why the app kept failing on websocket connection I found this github issue and I am so disappointed.

Overall Azure experience was so much better. It allows you to connect to public docker repos like dockerhub and straightaway deploy images from there...but AWS won't, you have to pull images locally and then push it to ECR and then deploy....and then I wasted 2 days figuring out that it was a websocket issue on AWS Apprunner.

I might avoid AWS and look at Azure or GCP.

[fabiobeoni]

In my experience AWS Copilot CLI is the fastest way to push a container online, you get easy deploy like for App Runner and you can deploy to Fargate having web socket support. Eg.: ```bash copilot app init --domain string.services copilot env init --name prod copilot svc init --name reverse copilot svc deploy --name reverse --env prod ``` Just have look, copilot is awesome. https://aws.amazon.com/blogs/containers/automatically-deploying-your-container-application-with-aws-copilot

…

On Sat, Oct 19, 2024, 8:57 AM jigar87 ***@***.***> wrote: What a waste of time. I am currently in analysis mode to decide on which cloud provider to use for my clients. I deployed a public container like n8n to AWS App runner and Azure Container Apps. I was considering AWS for its better pricing...but after wasting 2 days on why the app kept failing on websocket connection I found this github issue and I am so disappointed. Overall Azure experience was so much better. It allows you to connect to public docker repos like dockerhub and straightaway deploy images from there...but AWS won't, you have to pull images locally and then push it to ECR and then deploy....and then I wasted 2 days figuring out that it was a websocket issue on AWS Apprunner. I might avoid AWS and look at Azure or GCP. — Reply to this email directly, view it on GitHub <#13 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEAZTKMAMZITGKX6IKVPXADZ4H7EBAVCNFSM45D3LC7KU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TENBSGM3DENBYGQYQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[timn-ncl-uni]

I gave up on App Runner and websockets. I needed a solution sooner rather than later so I moved my container application to ECS Fargate. Took me a day to figure out Fargate and move the dockerised blazor-server application from App Runner to Fargate (using AWS CDK). Fargate supports websockets without issue. I was going to look at Azure but I'm quite invested in the CDK and generally like AWS however this App Runner issue is a real pain!

[skylarmb]

oops, just spend multiple days getting my stack deployed to AWS with Copilot + AppRunner etc, only to figure out this limitation at the last second. Damn, will have to choose a different solution.

[algoflows]

Just checking back in to shiz talk the app runner team for not listening to customers and implementing web sockets and ignoring user demands for over 5 years. This constitutes a monumental, idiotic short sited L from the current team. I am going to try and escalate this to the wider AWS organisation to get whoevers made this decision face accountability from leadership and customers.