Several custom Streamlit components, including st-theme (and streamlit_shadcn_ui, st_bridge, st_aggrid, streamlit_image_select) fail to load in deployed environments (except Streamlit Community Cloud), though they work correctly in local development. The issue seems related to network latency or proxy settings affecting frontend asset access in the deployment environment.
Examples were people -including me- have such problems:
and lastly it happens to my deployment in Google Cloud Run with st-theme component
Reproducible Code Example
I haven't been able to reproduce the issue locally; it only occurs when I deploy it to Google Cloud Run. Could this be due to the serverless nature of the platform, where multiple container instances are spun up to serve the streamlit app? I've read that using session affinity (https://cloud.google.com/run/docs/configuring/session-affinity) in Google Cloud Run deployments is recommended to ensure requests are routed to the same instance, especially since Streamlit relies on WebSockets. Could this be causing the problem? Does Streamlit really needs such a feature to work correct?
Steps To Reproduce
Deploy the app on a cloud platform (e.g., Google Cloud Run).
Include any of the mentioned custom components (e.g. st-theme).
Run the app and observe the error when trying to load the components.
See the error message indicating trouble loading the frontend assets for the components.
Expected Behavior
The app should load the custom components without any issues, just as it works in local development. The frontend assets should be accessible in the deployment environment.
Current Behavior
When deploying the app, the custom components fail to load. The error message indicates that the app is having trouble accessing the component frontend assets, which may be due to network latency or proxy issues. The components work fine locally but fail when deployed.
Your app is having trouble loading the [component_name] component.
If this is an installed component that works locally, the app may be having trouble accessing the component frontend assets due to network latency or proxy settings in your app deployment.
Is this a regression?
[ ] Yes, this used to work in a previous version.
Debug info
Streamlit version: 1.38.0
Python version: 3.10
Operating System: Docker container based on python:3.10-slim
Summary
Several custom Streamlit components, including
st-theme
(andstreamlit_shadcn_ui
,st_bridge
,st_aggrid
,streamlit_image_select
) fail to load in deployed environments (except Streamlit Community Cloud), though they work correctly in local development. The issue seems related to network latency or proxy settings affecting frontend asset access in the deployment environment.Examples were people -including me- have such problems:
Reproducible Code Example
I haven't been able to reproduce the issue locally; it only occurs when I deploy it to Google Cloud Run. Could this be due to the serverless nature of the platform, where multiple container instances are spun up to serve the streamlit app? I've read that using session affinity (https://cloud.google.com/run/docs/configuring/session-affinity) in Google Cloud Run deployments is recommended to ensure requests are routed to the same instance, especially since Streamlit relies on WebSockets. Could this be causing the problem? Does Streamlit really needs such a feature to work correct?
Steps To Reproduce
Expected Behavior
The app should load the custom components without any issues, just as it works in local development. The frontend assets should be accessible in the deployment environment.
Current Behavior
When deploying the app, the custom components fail to load. The error message indicates that the app is having trouble accessing the component frontend assets, which may be due to network latency or proxy issues. The components work fine locally but fail when deployed.
Your app is having trouble loading the
[component_name]
component.If this is an installed component that works locally, the app may be having trouble accessing the component frontend assets due to network latency or proxy settings in your app deployment.
Is this a regression?
Debug info
Additional Information