Deploying Streamlit Apps Yourself
Streamlit is a terrific tool to take data insight and turn that into an application — quickly and easily. One of the most common questions I get from folks who have experimented with Streamlit and built cool apps that they want to share with others is how to stand up that app for others in a more production-quality environment. This blog post is an attempt to share some common deployment scenarios that have resonated with customers as they move things from their laptop to the next level deployment.
Deployment Location
One of the first questions once you have a Streamlit app working on your laptop is “where am I going to put this so other folks can access it”. The short answer is “anywhere you want, really — physical server, virtual machine, container running in a Kubernetes cluster, etc”.
In practical terms, I advise customers to use whatever their organization uses. Very often, IT organizations have a mechanism to deploy containers, so suggesting a Docker container running in whatever mechanism they use generally resonates with them. To aid in converting a Streamlit app to a Docker container, I created a simple tool that helps. But, if your organization does not use Docker, running the Streamlit on some virtual (or physical) machine works just fine, too.
Application Authentication
Regardless of how you connect to the databases and other resources, you may want to restrict who is able to even access the Streamlit app itself. This is particularly true if you are using a “service account” (see below), as anyone who can access the Streamlit is able to use it. Some applications are more sensitive than others, so there are a variety of approaches to consider, but some are not (or less) applicable depending on the scenario. Typically this is enforced at the network layer.
Private Network
Some applications are okay to be accessible by anyone “on the inside”. Here, I mean, anyone on the internal network for my organization — the “intranet”. In this case, you would stand up your Streamlit and make the IP address that the Streamlit is assigned an internal IP address. As such, only folks on the internal network could even reach the IP address for the Streamlit app. This would allow for users to use a VPN to connect to the network from outside, and then have a route to visit the Streamlit app, for example.
Application Load Balancer
Another approach is to put an Application Load Balancer (ALB) in front of the machine or container that the Streamlit app is running on. For example, in AWS you might have your Streamlit app in a container and running in AWS’s Elastic Container Service (ECS) or perhaps using AWS Fargate. This container would have an IP address assigned in a private subnet of a VPC. Then, you could place an ALB in front of that container that listens to a public endpoint and routes to the internal IP address for the container. AWS ALBs allow for integration with an external Identity Provider (IdP) via integration with AWS Cognito. So, you can configure the ALB to use Cognito to validate that the visitor is allowed to be routed to the container by leverage OAuth integration with Cognito. See the AWS documentation for more information on this example setup.
Database Authentication
Most of the applications I encounter involve connecting to a data source or some resource that requires logging in, such as connecting to a Snowflake account. The first thing that you need to determine is if the application will connect to that resource as a single “service account” or if each visitor to the Streamlit application will need to connect to the resource as their own user account.
Service Account
It is very common to architect your application with a single service account, since your application may be giving the same data-focused experience for all visitors. In Snowflake terms, this would mean a single Snowflake user logging into Snowflake. All visitors will see the same data, restricted using Role Based Access Control (RBAC) by an administrator, per the needs of the application. If the visitor can reach the Streamlit application (we’ll get to this next), then they can see the data via the application just like anyone else.
Per good security practice, the credentials for this service account should be rotated periodically. This can be accomplished nicely in Snowflake by using Keypair Authentication. Since it is possible to have two active keys, you can rotate in a new key without disrupting active sessions. See the Snowflake documentation for more details.
Visitor Login
Another alternative is that each visitor will need to provide their own credentials, and the Streamlit application will connect using those credentials — to Snowflake or other resources. One way to do this is to implement a login screen as part of your Streamlit app. The user will need to provide a username, password, etc, that the Streamlit app will use to make the connection(s), and the Streamlit app will not proceed until a connection is successfully made. Care can — and probably should — be made to clear the credentials from Streamlit memory/cache/session state once the connection has been established.
For both the “service account” or the “login screen” method, I created a Python package that has a framework for these patterns, with an implementation for Snowflake. I discussed this topic in more depth in a previous blog post.
OAuth / SSO
Some data systems support connecting using OAuth. For example, Snowflake’s Python Connector and Snowpark packages support OAuth via the “externalbrowser” authentication method. These Python libraries will open a browser for the user to enter their credentials to whatever third party OAuth provider has been configured in Snowflake for their account. In the case of Snowflake, the Python packages will use Python calls to open the default browser for the machine (or virtual machine or container) on which the Python process is running. In the case of your laptop, this works very nicely. If it is running on a remote machine, virtual machine, or container, this would try to open a web browser there, which will not show up on the visitor’s machine.
At this point, Python-based ways of invoking OAuth logins in Streamlit are not supported.
Summary
To sum up, the most common approach to bringing a Streamlit app from your laptop to a more production environment is:
- Dockerize your Streamlit app into a container that is easily deployed in a container service. Leverage community tools (such as this one) to aid in creating the container.
- Stand up your Streamlit app in the container service of choice. Use whatever your organization prefers
- Restrict access to the Streamlit app at the network layer. Either:
– Restrict access to an internal IP address allowing only visitors on the internal network to access; or
– Place an ALB in front of the deployed container and use the ALB’s integration with an identity provider to restrict access - Connect to Snowflake (and other resources) either:
– With a service account that is the same for all visitors. Remember to rotate these credentials regularly, per good security practices; or
– With a login screen where a visitor must provide their own personal credentials for Streamlit to use, and the visitor cannot proceed to the rest of the Streamlit app until a connection to Snowflake has been established.
