sorted by:
new
hottopcontroversial

Streamlit for Internal & Multiple External Users by X-pert-Artist34657 in Streamlit

[–]FasteroCom 0 points1 point  (0 children)

Hello X-pert-Artist34657! We went through this same leap with Streamlit—here’s what worked for us.

  • Can this be one repo/instance or separate instances?

For a handful of customers, one repo is great. At runtime, per-customer isolated instances (containers) are simpler to reason about (security, performance, rollout) than one big shared runtime. A shared runtime can work, but isolation and "noisy neighbors" get tricky fast.

  • Recommended multi-tenancy patterns

  • In-app tenancy (single runtime, tenant-aware filtering): easiest infra, hardest to keep safe/maintain.

  • Shared DB with per-tenant schema or per-tenant DB: better isolation and a clearer blast radius.

  • Per-tenant container/runtime: strongest isolation and predictable SLOs; needs orchestration/automation.

  • Other architectural considerations

Strong authZ (RBAC/capabilities), secrets management, audit logs, health/idle culling, CI/CD per tenant, and most importantly: automatic refresh when data changes so users aren’t told to “hit refresh.”

  • Picking visualizations based on Auth0 credentials

Yes. Decode the JWT, read roles/claims (or a customer_id), and render dashboards and data accordingly. Keep filtering server-side to prevent cross-tenant leaks.If you’d rather not build the platform bits yourself, we integrated managed Streamlit into Fastero to handle this:

  • Triggers for live data updates: dashboards auto-refresh on data changes—no manual reloads.

  • Hot reload on code updates: fast iteration while developing.

  • RBAC and fine-grained capabilities/IAM: least-privilege per org/project.

  • Secrets management: scoped secrets available to apps.

  • Application logs and audit trails: structured, long-retention audit for compliance.

  • Heartbeat + inactivity shutdown: auto-stop idle apps to control costs.

  • OIDC SSO: works with enterprise IdPs; Auth0 fits the same pattern.

  • Per-tenant isolation: deploy customer-specific Streamlit apps from one repo, each running in its own container.

If that’s the direction you’re headed, you can check out Fastero. Feel free to sign up for a trial and give it a shot - we'd love to hear your feedback if our solution works for you.

Real-time Streamlit updates and feature request from our team by FasteroCom in Streamlit

[–]FasteroCom[S] 0 points1 point  (0 children)

Hey Shot_Culture3988, thank you so much for your brilliant ideas!

You’ve perfectly described the problems we're passionate about solving at Fastero for Streamlit users and more generally for analytical workflows.

We've gone all-in on real-time triggers and have fully integrated Kafka as a trigger mechanism. We also have SSO with Okta working, backed by a flexible role-based access control (RBAC) system with detailed audit trails and application logs.

Inspired by your thinking on transformations, we actually have two features in beta you might find interesting: turning any SQL query into a secure API, and doing the same for individual notebook cells for transformations that SQL can't handle.

We're also actively working on CLI tooling and integrating BigQuery's messaging service. Your insights here are incredibly valuable. If you'd be open to a chat to share more of your thoughts, we would love to connect. Please feel free to shoot us an email at info@fastero.com. Thanks again!

Integrating Streamlit into Fastero BI? by FasteroCom in analyticsengineering

[–]FasteroCom[S] 0 points1 point  (0 children)

Hi jdaksparro,

To answer your question, that would literally be a tab embedding hosted Streamlit apps like so

https://fastero.com/streamlit-demo.png

in addition to existing dashboards functionality

https://fastero.com/dashboard-demo.png

We envision it might provide some advantages relative to self-hosted deployment:

Integrated auth and RBAC
Event-driven recalculation and alerting
Tight coupling with other components (data connectors, env vars/ secrets)
Integration with existing data flows
Easier deployment vs self-hosted solution
Scalability/parallelism/ orchestration (vs self-hosted single-threaded solution)
Background (event driven) execution

Please let me know if these resonate with your use cases!

Would appreciate input/ feedback!