How to disable "Network URL"?

Is there a setting that allows you to only make an app accessible through localhost and not a “Network URL”?

1 Like

Hey @zabzug!

That’s an interesting question — I hadn’t thought of that.

Just to make sure I understand your motivation: is the reason you’re doing that you want to make sure people in your local network don’t have access to your Streamlit app?

Right now it’s not possible for Streamlit to block traffic based on its source, but there are ways around it (see below). We could add this as a feature in Streamlit, but since this is used for security purposes we need to think it through a bit more before implementing a solution.

In the meantime, you can use an OS-level solution, though. On Linux you can use the iptables command, and on Mac either ipfw or pw, depending on the OS version. On Windows, I assume you can use Windows Firewall.

From some googling I found these:

In my short Google session I couldn’t find direct answers to this question using pw and Windows Firewall, but let me know if you need some help finding them.

Is this what you’re looking for?

Thanks for the response @thiago!

Yes, your understanding of my motivation is pretty correct. We work with very sensitive data and need to be able to create apps that are only accessible via localhost, so we can guarantee that the only people with access to the app are people with SSH access to the box it is running on (via port forwarding).

This is a pretty critical feature for us, and I’d imagine for many other users too.

Hi @thiago, Zack’s coworker here :slight_smile:

After some digging around the code (yay open source!) I was able to find a solution to address not printing the network URL. I noticed that if you explicitly set the browser address in the config, then that’s the only URL that Streamlit displays when running the app.

st.set_option('browser.serverAddress', 'localhost')

Which exhibits the desired behavior:

jjordan$ streamlit run

  You can now view your Streamlit app in your browser.

  URL: http://localhost:8501

There was some concern that Streamlit was doing firewall traversal to make a public IP available (eg. like ngrok does) but reading the source code it’s apparent that this is not the case. As long as Streamlit doesn’t plan to do something along those lines down the road, we should be fine :+1:

1 Like

Yep. Just confirming that we don’t do that so you’re all good. :+1:

Also, please note that you can set config options in ~/.streamlit/config.toml. :slight_smile:


A related question. Can the network URL be set up to run over https?

1 Like

That’s a great idea. So far we’ve been doing that at the load balancer level, so it didn’t even occur to me to implement support for HTTPS directly at the Streamlit server. Of course, you’d still need to bring your own certificate to the party.

I just created an issue where you can follow progress on this feature. That said, given all the work we have planned for this month, it’s unlikely we’ll get to this soon. Which is another way to say this is a PR we’d glady accept from the community :wink:

PS: In the future, please create a new thread when asking new questions. It makes it easier for others to find the answer later on!

1 Like


I’ve added an nginx reverse proxy to listen to 443 with password protection and SSL termination that reverse proxies to 8501. I also deploy streamlit using the browser.serverAddress option to point to localhost, but I can still see the app by directly accessing from 8501.

streamlit hello --server.enableCORS false --browser.serverAddress localhost


  You can now view your Streamlit app in your browser.

  URL: http://localhost:8501

Then I will go to http://SERVER_IP_ADDRESS:8501 and I can still connect to the app, when I’d like to only see the app from https://SERVER_IP_ADDRESS.

Edit: I can even put something arbitrary (e.g. blabla) and it still connects.
Edit 2: Ah, this is known:

1 Like

Seems to be raised here
We apply exactly the same method when serving Streamlit apps. This is a very common demand for which a config option should possibly be implemented.

+1’d, it’s crucial for us to be able to have control over the network traffic and ensure that local developments stay local. I’ve had an Azure instance up for quite a while and the logs are littered with people randomly trying to connect and execute known exploits, so being forced to have a public page available is really problematic for sensitive data.

Hi @Zylatis, welcome to the forums!

Just to clarify, what specifically are you +1’ing here? This thread talks about a bunch of different things, some of which were already fixed, others which were never issues / just misunderstandings, and others that we’d like to see whether / how to address. So I’m confused :smiley:

In particular,

so being forced to have a public page available is really problematic for sensitive data.

Streamlit doesn’t force you to have a public page. It just shows the URL that would be your public URL if you were to open your network to the world.

If you’d rather not show that prompt at all, you can just bind Streamlit to a specific address with --server.address=123.456.789.876