Has anyone deployed to Google Cloud Platform?

Hey Juan.

Thanks for this. Worked for me as well.

I’m getting into another issue and was wondering if I can get some guidance.

So I can do a manual gcloud app deploy, but now I want to do it in CI/CD with Cloud Build. Unfortunately the build runs, but the app does not respond on the weblink.

Here is the repo I am using for this…

Would be great if can get some guidance.

##Streamlit Deployment on Google Cloud Run (Updated July 2021)
Streamlit on GCP Cloud Run

thanks! this helped unblock me. For anyone else stumbling onto this thread:

I was able to accomplish App Engine deployment by using a Dockerfile and this app.yaml:

runtime: custom
env: flex

instance_class: F2

  session_affinity: true


FROM python:3.9.3
COPY requirements.txt ./requirements.txt
RUN pip3 install -r requirements.txt
RUN find /usr/local/lib/python3.9/site-packages/streamlit -type f \( -iname \*.py -o -iname \*.js \) -print0 | xargs -0 sed -i 's/healthz/health-check/g'
COPY main.py ./main.py
CMD streamlit run --server.port 8080 --browser.serverAddress --server.enableCORS False --server.enableXsrfProtection False main.py

/healthz was an existing endpoint in streamlit that conflicted with GCP’s internal expectations, so I needed to run the sed one-liner.

Cloud Run seems to work as well, pointed to the image published to the google cloud registry associated with the most recent App Engine build (in the same project), and had it up and running quickly (image didn’t need to be rebuilt).

Digital Ocean Apps deployment worked well (started playing with it while waiting on GCP deployment with the above combo, which was taking much longer once I started using the flex environment with the Dockerfile…). For Digital Ocean, defaults from dockerhub as the app source worked great. I only needed to configure the health check from default TCP to HTTP at /health-check and it worked with the same Dockerfile above.

1 Like

Turns out the fact of streamlit running on websockets complicates autoscaling, so … I suggest you don’t deploy streamlit this way (on elastic beanstalk, cloud run, app engine, etc).

After “request timeout” is reached, or if scaling happens behind the scenes, the client may be routed to a different backend worker, meaning the app resets, state is lost, etc. leading to a bad user experience.

Deploying into a single VM on digital ocean (or the equivalent non-scaled solution on gcp/aws/azure) is the way to share (besides streamlit sharing) but can’t quite handle scaling (except vertical).

Definitely learned the hard way that the proper way to build apps that can scale on these managed platforms is to decouple front/back end. streamlit helped prototype the interface / experience but can’t be what I use to go to production. As far as I can tell, the only way to scale is to go the “binder” route (kubernetes under the hood) and assign a single VM to each user, which can get expensive quickly.