This session is for anyone who has built a Streamlit (or Dash, R Shiny, FastAPI, React) prototype and then hit the wall when it needed to be shared with real users: access to live data, SSO, permissioning, deployment, and operational guardrails.

We will present the workflow and the architecture from both sides: as a data scientist shipping an app, and as a platform admin operating the service safely at scale.

What we will demo

We will demo the end-to-end workflow from zero to a running app using our internal app service. The platform includes a web console for self-service provisioning and configuration and the deployment runtime managing the state of the application.

• Using the web console to create and configure a new app from a framework template (Streamlit, Dash, R Shiny, FastAPI, React).
• How a Git repository is created and the first version is deployed behind the scenes, including a working starter app with example pages.

Key design decisions (the parts that are usually hard)

• Identity propagation: the app receives the signed-in user identity from SSO and uses it for downstream authorization.
• Authorization at the data layer: dataset permissions are scoped to use-case resource, making sure tokens can not be exploited.
• Safe multi-tenancy: per-app isolation plus resource limits to prevent noisy-neighbor problems.
• Repeatable delivery: templates plus CI/CD conventions so a new app starts from a working, deployable baseline.
• Day-2 operations: guardrails like quotas, rate limiting, and idle shutdown to keep the platform reliable and cheap.

Running at scale

• Production usage: 750+ active apps and 8k+ unique end users (2025).
• Infrastructure run rate under 10k USD per month (excluding engineering time).

Who should attend

• Data scientists and analysts who want to ship apps beyond a demo.
• Data platform and DevOps engineers building self-service tooling for governed environments.
• Teams standardizing how internal data & AI products are delivered to business users.

Takeaways

• For data scientists: what a good internal app hosting platform should provide, and which requirements you should ask your platform team for (governed on-behalf of data access, templates, CI/CD, guardrails).
• For platform teams: a blueprint you can adapt beyond AWS, including the architecture and tradeoffs necessary to operate fine-grained authorization and a multi-tenant runtime at scale.

If you do not have such an app platform in your company yet, use this talk as a checklist to start the conversation with your IT or platform teams. :-)