Deploying Streamlit apps on Kubernetes

Deployment
1

I have been building the OpenRun open-source project GitHub - openrundev/openrun: Internal tools deployment made easy. Deploy web apps declaratively, on a single-node or on Kubernetes. · GitHub . OpenRun is a platform for teams to deploy internal tools. OpenRun makes it easy to deploy Streamlit apps with a declarative interface.

OpenRun now supports deploying apps on Kubernetes. The regular process to deploy on Kubernetes is documented at Deploy Streamlit using Kubernetes - Streamlit Docs . That works fine if you have just one Streamlit app. If you have multiple apps, you need to setup a build job for each app (Jenkins), CD using ArgoCD etc and an IDP like Backstage to monitor your deployments. If you use OAuth2-Proxy, setting up OAuth for each app will require new OAuth clients per app. Even with all that work, there is no way to control which user has access to each app (RBAC). Using Helm to templatize your app setup does not actually reduce the complexity when adding new apps.

With OpenRun, you install OpenRun on your Kubernetes cluster, setup your RBAC rules and configure a sync to implement declarative deployments. After that, adding a new app just requires adding an app config line for the new app, like below. You just say what path to install the app at, where to get the source code from and what name to use for the app.

sl_args = {"container_opts": {"cpus": "2", "memory": "512m"},
   "spec": "python-streamlit"}

app("/streamlit/spirals", "github.com/streamlit/streamlit-example",
   git_branch="master", params={"app_name": "Spirals"}, **sl_args)

app("/streamlit/uber", "github.com/streamlit/demo-uber-nyc-pickups",
   params={"app_name": "NYC Uber Ridesharing Data"}, **sl_args)

OpenRun handles the container builds, the zero downtime rolling deployments using Kubernetes Pods, secrets management, TLS certs and setting up access controls using OIDC/SAML with RBAC. Apps are automatically scaled down to zero when idle.

The same OpenRun config works on a single-node when you do not need Kubernetes scale-out.

2

Hey, thanks for sharing your work with OpenRun and for the detailed comparison! :rocket: You’re absolutely right: the standard Kubernetes approach for deploying multiple Streamlit apps involves a lot of manual setup—separate build jobs, CI/CD pipelines, OAuth2-Proxy configs, and Helm templating, none of which natively provide per-app RBAC or easy scaling. This can quickly become complex and hard to manage as the number of apps grows.

OpenRun streamlines this by letting you declaratively define apps in a single config, handling container builds, rolling updates, secrets, TLS, and fine-grained RBAC (via OIDC/SAML) out of the box. It also supports auto-scaling to zero for idle apps and works both on Kubernetes and single-node setups. This approach significantly reduces operational overhead compared to vanilla Kubernetes + Helm + OAuth2-Proxy, especially for teams managing many internal Streamlit tools. For reference, see the official Streamlit Kubernetes deployment guide for the standard process, and the OpenRun repo for your project’s capabilities.

Sources: