How to Share Streamlit Apps with Non-Technical Users

You built a Streamlit app. It does something useful — maybe it pulls sales data from Postgres and generates a weekly cohort analysis, or it lets your ops team upload a CSV and run a segmentation model. It works beautifully on localhost. You show it to your manager, they say "this is great, can you share it with the team?"

That question is where the pain begins.

The gap between "this works on my laptop" and "the finance team can open this in their browser" is enormous compared to the time it took to build the app itself. Authentication, deployment, HTTPS, process management, secret handling — none of these are Streamlit problems, but they're all problems you inherit the moment you want someone else to use your app.

The Streamlit Community Cloud trap

The obvious first answer is Streamlit Community Cloud. It's free, it's official, and it deploys directly from a GitHub repo. For personal projects and open-source demos, it's perfectly fine.

For sharing with a business team, it breaks down fast.

The GitHub SSO problem. Community Cloud's only access control mechanism is GitHub-based. To restrict app access, you add users to your GitHub organization, and they authenticate via GitHub. Your VP of Finance does not have a GitHub account. Your marketing coordinator does not have a GitHub account. Asking non-technical stakeholders to create a GitHub account and join your organization just to view a dashboard is a non-starter in most companies.

No role-based access. Even if everyone magically had GitHub accounts, there's no concept of "this person can view but not interact" or "this team sees these pages but not those." It's all or nothing.

No custom domains. Your app lives at your-app.streamlit.app. Not a big deal for internal use, maybe, but it doesn't exactly scream "production tool."

Resource limits. 1 GB of RAM per app. Apps sleep after inactivity and take 30-60 seconds to cold-start. The first person to visit each morning gets a loading spinner. For a demo, tolerable. For a tool your ops team opens at 9am every day, frustrating.

Community Cloud is a great deployment target for Streamlit's open-source community. It was never designed to be an enterprise app hosting platform, and trying to use it as one leads to predictable frustration.

DIY auth: the approaches and their trade-offs

If Community Cloud won't work, the next instinct is to bolt authentication onto your Streamlit app yourself. Here are the common approaches, with an honest assessment of each.

streamlit-authenticator

The streamlit-authenticator library is the most popular community solution. It adds a login form to your app with hashed password storage in a YAML file.

import streamlit as st
import streamlit_authenticator as stauth
import yaml
from yaml.loader import SafeLoader
 
with open('config.yaml') as file:
    config = yaml.load(file, Loader=SafeLoader)
 
authenticator = stauth.Authenticate(
    config['credentials'],
    config['cookie']['name'],
    config['cookie']['key'],
    config['cookie']['expiry_days'],
)
 
authenticator.login()
 
if st.session_state['authentication_status']:
    authenticator.logout()
    st.write(f'Welcome *{st.session_state["name"]}*')
    # your actual app goes here
elif st.session_state['authentication_status'] is False:
    st.error('Username/password is incorrect')
elif st.session_state['authentication_status'] is None:
    st.warning('Please enter your username and password')

And here's what the config.yaml looks like:

credentials:
  usernames:
    jdoe:
      email: jdoe@example.com
      name: Jane Doe
      password: $2b$12$hashed_password_here
cookie:
  expiry_days: 30
  key: some_signature_key
  name: auth_cookie

This works for a proof of concept, but the problems compound quickly:

Password management. You're now managing passwords. Adding a user means generating a bcrypt hash and editing a YAML file. Resetting a password means editing the file again. There's no "forgot password" flow. At 5 users this is tedious. At 20 it's unsustainable.

Secrets in repos. That config.yaml with hashed passwords and the cookie signing key — it ends up in your repo. You can use Streamlit's secrets management, but then you're stuffing a YAML blob into a text box and praying you don't break the formatting.

No SSO integration. Your company uses Google Workspace or Azure AD for everything else. streamlit-authenticator doesn't integrate with any of them. You're creating a separate identity silo.

Session state fragility. The auth state lives in st.session_state, which is subject to Streamlit's rerun model. Edge cases around tab duplication, session expiration, and concurrent access surface eventually.

OAuth wrappers (Google, Azure AD, Okta)

You can implement OAuth 2.0 directly in your Streamlit app using libraries like authlib or msal. This gets you real SSO — users log in with their existing corporate credentials.

The problem: it's a significant engineering project. You need to register an OAuth application with your identity provider, handle the authorization code flow, manage token refresh, store session state securely, and handle edge cases (expired tokens, revoked access, multiple tabs). This is 2-3 days of work for an experienced developer, and it's work that has nothing to do with the data app you're trying to build.

If you're doing this for one app, it's painful but defensible. If you're doing it for every Streamlit app your team builds, you're now maintaining a custom auth library.

Reverse proxy with external auth

The most robust DIY option: put an authentication proxy (OAuth2 Proxy, Authelia, or Cloudflare Access) in front of your Streamlit app. Users authenticate against your identity provider before they ever reach the app. Streamlit doesn't know authentication exists.

This is architecturally clean but operationally heavy. You're now running nginx with WebSocket proxy support (Streamlit requires it — miss the Upgrade header and you get an infinite "Connecting" spinner), an auth proxy, SSL termination, and probably Docker Compose to tie it all together. If you already have this infrastructure for other services, adding a Streamlit app behind it is incremental. If you don't, you're standing up DevOps infrastructure to share a Python script.

For a detailed walkthrough of the self-hosted approach (including the nginx WebSocket configuration that trips up most people), we wrote a full guide to deploying Streamlit with authentication.

Hosted platforms with auth built in

If you've read this far and thought "I just want to share a Streamlit app with 10 people and have them log in," the hosted platform category exists specifically for you.

Ploomber Cloud supports Streamlit, Dash, Panel, and Flask. The free tier gives you 2 apps with 512 MB RAM. The Pro plan ($20/month) bumps that to 10 apps and 2 GB RAM with custom domains. The Teams plan ($50/month) adds password protection and team management with 4 GB RAM. It's a solid option if you're running multiple frameworks, not just Streamlit.

Hugging Face Spaces hosts Streamlit apps (among other frameworks) with a generous free tier — 2 vCPU and 16 GB RAM. The catch: free Spaces sleep after 48 hours of inactivity, and there's no built-in authentication. Paid upgrades ($0.60/hour for CPU, more for GPU) keep apps always-on but get expensive for persistent use. Spaces are best for ML demos and prototypes, not internal business tools.

Railway deploys any Dockerized app, including Streamlit, starting at $5/month plus usage-based billing (roughly $10/GB RAM per month). It handles SSL and deployments cleanly. No built-in auth — you'd still need to implement one of the DIY options above or use a service like Clerk or Auth0.

Render has a similar model: web services from $7/month (512 MB RAM, Starter tier). Auto-deploy from Git, managed SSL. No built-in auth. Free tier web services sleep after 15 minutes of inactivity, which is even more aggressive than Community Cloud.

Fastero takes a different approach — it's built specifically around Streamlit hosting with authentication as a core feature, not an add-on. Every deployed app sits behind login gating by default. You can generate shareable links that either require authentication or allow open access. Secrets are stored in an encrypted vault and accessed via the standard st.secrets API, so your app code doesn't change. Compute tiers range from 1 GB (free) to 16 GB RAM per app, with paid plans starting at $20/month. The trade-off: no custom domains yet, and apps currently cold-start in 5-15 seconds on first visit (always-on is in development).

Choosing the right approach

Here's how to decide:

Use Community Cloud if: your app is open-source or you don't need access control, you can tolerate cold starts, and 1 GB RAM is enough.

Use streamlit-authenticator if: you have fewer than 5 users, you're comfortable managing passwords in a YAML file, and this is a one-off internal tool.

Self-host with an auth proxy if: you already have container infrastructure, you need to integrate with your corporate identity provider, and you have DevOps capacity to maintain it.

Use a hosted platform if: you want auth without building auth, you're deploying more than one app, and you'd rather spend time on the app itself than on infrastructure.

The underlying question is always the same: is the time you're spending on authentication and deployment proportional to the value of the app? If you're spending 20 hours setting up auth for a Streamlit app that took 2 hours to build, something is wrong with the ratio. The app is the valuable part. The infrastructure is the tax.

Try Fastero free — deploy Python data apps with built-in auth, scheduling, and always-on hosting — no infrastructure to manage. No credit card required.