Community Cloud app crashes with ~9 simultaneous submissions — need to support ~62 students

Community Cloud
, , ,
1

Hi, I’m using Streamlit Community Cloud for a classroom attendance and reflection app.

Hi, I’m using Streamlit Community Cloud for a classroom attendance and reflection app.

1. Public app link

https://journey-to-quantum-world-ta-9xrffqcomykgbgme8jpesl.streamlit.app/

2. Public GitHub repository

https://github.com/olr-or/Journey-to-quantum-world-TA

The app is used by approximately 62 students, and several students may submit within the same short time window.

During a class session, when roughly 9 students were actively using the app and submitting attendance at around the same time, the Community Cloud app became unavailable and showed the Streamlit “Oops” screen.

Each attendance submission currently involves:

  • st.camera_input
  • image compression with PIL
  • uploading the photo to Google Drive
  • writing attendance information to Google Sheets with gspread

Google Sheets writes are already batched using a queue and append_rows().

I have also modified the photo upload pipeline so that image processing and Google Drive uploads are limited to only a few workers at a time instead of processing all simultaneous submissions at once.

However, I ultimately need the app to support approximately 62 students, so I would like to know whether this workload is realistic on Streamlit Community Cloud.

In particular:

  • Can Community Cloud reasonably handle around 60 simultaneous active Streamlit sessions?
  • Could multiple users holding images from st.camera_input cause significant memory pressure even if image processing and uploads are queued?
  • Is limiting image processing / Drive uploads to 2–3 workers a reasonable approach, or would it be better to move the upload/storage workload to a separate backend such as Google Cloud Run?
  • I also have a Class Reflection page that only submits short text responses and does not use photos. Would approximately 62 near-simultaneous text submissions generally be much safer?

I also submitted a request for increased Community Cloud resources because this is an educational app, but I have not received a response or resource increase yet.

3. Full error message

Unfortunately, I no longer have the logs from the actual failure.

When approximately 9 students were using/submitting through the app at around the same time, users saw the Streamlit “Oops” / app unavailable screen.

I manually rebooted the app shortly afterward, so the currently available Community Cloud logs only start from that manual reboot. I did not see a Python traceback or explicit error message before rebooting.

The logs I have now only show normal application startup after the manual reboot and some use_container_width deprecation warnings.

4. Streamlit and Python versions

Streamlit: 1.63.0
Python: 3.14.7

Any advice on the best architecture for this type of classroom workload would be greatly appreciated. Thank you.

2

Welcome to the Streamlit community and thanks for the detailed question! :tada: Supporting 60+ students submitting images and text nearly simultaneously is a classic resource challenge on Streamlit Community Cloud, especially with image uploads and external API calls.

It seems likely that Community Cloud can struggle with 60+ concurrent sessions involving image uploads, as each session consumes memory and CPU, and st.camera_input images can be large. Even with batching and limiting workers, memory pressure from multiple users holding images in memory can cause the app to exceed the 2.7GB RAM limit, leading to the “Oops” error. Limiting image processing/upload to 2–3 workers helps, but offloading uploads to a separate backend (like Google Cloud Run) is a more scalable approach. Text-only submissions (like your reflection page) are much less resource-intensive and should be safer for 60+ users. For educational/nonprofit apps, resource increases are possible but not guaranteed and may take time to process. For more, see the official resource limits and forum discussions on concurrency and scaling.

Would you like a step-by-step breakdown of architectural recommendations or code-level optimization tips?

Sources: