I made a small command-line wrapper called streamlit-remote that launches streamlit run together with services such as ngrok, Cloudflare Quick Tunnel, and others, so a local Streamlit app can be exposed through a temporary remote HTTPS URL for development and demo purposes.
It starts streamlit run for you, starts a tunnel provider, prints the public URL, and can open it in the browser. It currently supports Cloudflare Quick Tunnel, ngrok, zrok, Pinggy, and localhost.run. It also has options for local HTTPS using self-signed certificates or mkcert.
I originally built this to make local development easier for my own apps using Streamlit-WebRTC, and I still use it for that purpose myself.
Was wondering what the value was in the wrapper and then read that it’ll support HTTPS and also restarting the Streamlit app whilst keeping the external URL stable. That’s a lot of value.
That sounds very useful for quick demos and testing. A tool that exposes a local Streamlit app through a temporary HTTPS URL can make it much easier to share work with teammates or clients without deploying to a cloud service first. The HTTPS support is especially important for avoiding browser security warnings and for testing integrations that require secure connections. I’d be interested to know whether it supports custom authentication, URL expiration controls, and stable performance during longer sessions, as those features can make a big difference for real-world use.
Thank you. Actually I created this as just a thin wrapper of streamlit run and commands such as ngrok to save my time running those two commands in different terminals, handing over all such fine controls to the underlying commands.
However, your comment made me think it’s worth considering to implement such features as first-class ones. I appreciate it.
Thanks for sharing