I’m thinking of running Streamlit on serverless infrastructure, e.g. AWS Lambda. Has anyone tried this, and is this possible?
Hi @keanekwa, thanks for your questions. We haven’t tried so far, but it would not work as it is. I am personally not an expert, but Streamlit is based on a Webasocket server which I am not sure how it would fit in a serverless architecture. Many people deployed on Heroku, GKE and various flavors of Azure, but not on Serverless that I am aware of.
For tutorials on deployment take a look at the resources tagged deployment at awesome-streamlit.org
Would it be possible to use https://erm.github.io/mangum/ (adapter for using ASGI applications with AWS Lambda & API Gateway) to run Streamlit? Some people were able to run FastAPI this way: https://iwpnd.pw/articles/2020-01/deploy-fastapi-to-aws-lambda.
Thanks for the question.
Streamlit is currently built using Tornado, which does not natively support the ASGI interface. If Tornado were to include an ASGI adapter, then we’d likely do so as well.
If you’re finding ASGI support to be an important aspect of whether you want to use Streamlit or not, I would recommend filing an enhancement request on our github repo. We are working on making Streamlit a lot easier to deploy over the course of this year, especially with our Streamlit4Teams rollout.
API Gateway supports websockets. Conceptually, package streamlit’s python script in a lmabda handler, then install streamlit dependencies in a lmbda layer - finally connect the lambda to an API Gateway with websocket enabled - do you still see issue with this approach ?
One of the major issues for data scientist is the hassle for provisioning infrastructure and deploying their code. If this can be deplyed in a serverless environment , that is one less concern to worry for them. Hence my preference to prove out an API-GW-Lambda approach.
An article was just published about using Streamlit with AWS Fargate:
thats a great article, and i’m not knocking it, but using ECS means you’re still running a service 24x7. So i would argue that’s not really serverless.
I would envisage a way to expose some sort of data api, and then a lambda (?) where necessary to perform the functions that the streamlit server currently does.
Maybe the current architecture is not yet ready for this? be good to consider for the future though. And in reality the above really sounds to me like you need a client side tool, and a data api and then mash them together. i.e. push all the streamlit logic to the client.