Streamlit deployed app "loses" uploaded images

I was excited to finally deploy my app at today but then disappointed to see that is too slow and crashes. The app does neural style transfer from a user provided image - either from a file or URL. First problem is as the neural style transfer runs - very slowly - the uploaded image “disappears” so the neural style transfer fails from not having an image to convert.

Then as I tried again the app crashed with this error:
# Argh.

This app has gone over its resource limits. Common causes for this are memory leaks in the app logic, using caching without a TTL, or leaving large datasets in memory even after they are no longer needed. Please update and reboot this app to try again.

If you still have questions, leave a message in our [forums]( and we’ll get back to you ASAP.

Did you try @st.cache to reduce the re-runs and memory leak? or is your code not suitable for caching?

Thanks for the suggestion - let me look into the st.cache operation, how to use it, and try it.

If I had to guess, I would say that Torch needs more than the 800MB of RAM allocated for Streamlit sharing. Torch is a huge library, which then in turn imports large ML models.

Could very well be - my app is doing neural style transfer, which uses the VGG19 pretrained model. How can I tell how much RAM memory is being used when my app runs?

Thank you Berk and Randy for your feedback. I did try the @st.cache decorator. Doing that did provide a bit more info. From the log messages I suspect the uploaded image gets crowded out as streamlit tries to download the VGG19 model to do the neural style transfer. So looks like I’m out of luck to run any significant functions of my app using Streamlit Sharing. Too bad, deployment was easy.

Downloading: "" to /home/appuser/.cache/torch/hub/checkpoints/vgg19-dcbb9e9d.pth
[manager] Error checking Streamlit healthz: Get "http://localhost:8501/healthz": dial tcp connect: connection refused

Yeah, looks like that model is 548MB in a binary serialization format, which I’m sure Python blows up to a much more heavy in-memory representation.

In general, this is something we’re trying to evaluate, how we can provide this sort of support to the community, without also making the hosting costs untenable. If I had to guess, an app like this probably takes 4x the resources that we’re currently providing in the free tier, which would be a significant cost upgrade to do for all users :frowning: