Let’s say I have a streamlit app running on port 5801, but somehow want it behind a proxy to be served at /myapp
So going to /myapp should show me the root of the app (just as at localhost:5801/)
How can I instruct the streamlit app that it is running at the subfolder level, so static files should be requested from /myapp/static etc? There might also need to be mappings of websockets and other URLs.
I have played around with browser.serverAddress and server.baseUrlPath but haven’t had any success. Any thoughts on configuring streamlit like this? (I appreciate exactly how to configure the proxy depends on my server etc - so to start with I’m just asking about configuring the app itself…)
If I’m understanding you correctly, what you’re trying to do is set up /myapp to be accessible on a normal domain name that potentially serves other things, right? Like http://greatdomain.com/myapp
To do this you’ll need to configure the web server, not Streamlit, actually. Streamlit will still run as usual, but the web server (Apache2? Nginx? whatever you have running) will be configured as a reverse proxy to redirect all requests for /myapp to the service running on port 5801.
We have some resources on our newly-created FAQ to help with this. It would mean a lot in terms of helping out Streamlit and the community if you would check out the FAQ and see if you can get help there.
Feel free to return here for more help, to comment on the usefulness of the FAQ, suggest improvements, etc. Thanks!
@nthmost Thank you very much for your reply, and for pointing me to the new FAQ page.
This has led closer to the answer, although I think there is still something missing: how can streamlit be configured to access static assets at a relative URL - /myapp/static instead of /static? By contrast, when behind the reverse proxy, the stream is accessed by the streamlit app at /myapp/stream instead of /stream (which is what I would hope). /static is still requested from /static instead of /myapp/static though - is this different treatment of the two URLs by design?
Thanks for getting back to me. Yes, the webserver config was something I should really have included in my last post, but it always makes the post look a bit overwhelming so I decided to leave it until really needed!
I’m running nginx, currently just in a Docker container with streamlit in another container, just for proof of concept.
(I’m not too sure where vendor needs to sit at the moment - it isn’t being requested)
The above all works correctly, as in the app functions correctly.
However, I think it would make sense for /static to really be requested by the browser at /myapp/static instead. This is likely to be by design in streamlit since you might want static to be treated globally and perhaps served through something more efficient for static files, or a content delivery network or something. Even/especially if there were multiple streamlit apps at different subfolders. By contrast the / and /stream endpoints have to be application specific.
But it would be even better if this can be configured in streamlit - just being able to tell it the base URL to access static files.
As I’ve moved beyond proof-of-concept using nginx, I’m no longer seeing Streamlit request /static from absolute rather than relative paths. i.e. the app at /myapp does now seem to be requesting static files from /myapp/static. Not sure what has changed in my config though, sorry. I still think something in streamlit config can affect this.
These ideas are now also used in a ‘streamlit launchpad’ utility that I built:
It allows you to ‘run a folder’ as a launchpad for any streamlit apps within it. So it presents a web page listing all .py files in the folder and you can click on any of them to launch directly in a new tab.
Ideally this functionality could be built directly into streamlit. At the moment the launchpad spawns a separate streamlit command line process for each app.
It’s very much an experimental alpha but please take a look if you are interested. It demonstrates the reverse proxy ideas discussed in this thread. Thoughts/feedback welcome!
This is a workaround for dev environments, but in production you’d probably want a more substantial setup, or even better if incorporated into Streamlit itself as per the issue you raised.
Anyway, I’d be really interested in your thoughts if you get a chance to try it out, and meanwhile I’ll take a look at the issue.
This actually looks awesome and very much as what I need.
As far as I can see from the code when looking on my phone you run each app/ Python file on a separate port and then provide them on a common port using a reverse proxy. Is that correct?
One thing I would need for my use case is to specify the server address to 0.0.0.0 instead of localhost to run inside a Docker container.
Another thing that would be nice to have would be the ability to start the launchpad from python code and specify the apps and endpoints via a dictionary like
All your ideas make sense and could certainly be implemented.
Please do take a closer look and try it out if you get a chance. It would be great to hear how you get on!
I think the biggest question is really understanding the possible use cases. As I said, scalability is a bit of an unknown - as soon as you might need multiple servers, it would probably make more sense to ‘load balance’ at a network configuration level, although then the dynamic functionality of picking up any new .py script would be lost.
Thanks for stopping by! We use cookies to help us understand how you interact with our website.
By clicking “Accept all”, you consent to our use of cookies. For more information, please see our privacy policy.
Cookie settings
Strictly necessary cookies
These cookies are necessary for the website to function and cannot be switched off. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, logging in or filling in forms.
Performance cookies
These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site. They help us understand how visitors move around the site and which pages are most frequently visited.
Functional cookies
These cookies are used to record your choices and settings, maintain your preferences over time and recognize you when you return to our website. These cookies help us to personalize our content for you and remember your preferences.
Targeting cookies
These cookies may be deployed to our site by our advertising partners to build a profile of your interest and provide you with content that is relevant to you, including showing you relevant ads on other websites.