Empowering Data Scientists with Zero Platform Friction: Deploying Streamlit & Friends in 3 Minutes
In this presentation, Bernhard Schäfer, Senior Data Scientist at Merck, and Nicolas Renkamp, Global Head of Platform Product Portfolio at Merck, address the common "wall" data scientists hit when transitioning a Streamlit or Dash prototype into a production-ready application. Bernhard and Nicolas demonstrate how to eliminate platform friction by showcasing Merck's self-service app service, which enables teams to deploy governed applications in just three minutes. By examining a platform that powers over 750 active apps for 8,000 users, the speakers explain how to integrate essential enterprise requirements—such as SSO, CI/CD, and scoped data access control—without slowing down the development cycle.
The session features a live demo of the end-to-end workflow, from using a web console for provisioning to the automatic generation of deployable Git repositories. Viewers will learn about a cost-effective AWS-based reference architecture and the specific design decisions required for safe multi-tenancy, identity propagation, and "Day-2" operations like rate limiting and idle shutdowns. Whether you are a data scientist looking for a blueprint to request from your IT department or a platform engineer building self-service tooling for a governed environment, this talk provides practical patterns for balancing central control with decentralized freedom. Attendees will walk away with a clear framework for shipping data and AI products at scale while maintaining strict security and reliability standards.
This description was generated by Open-Source AI using the transcript of the session and the original submission contents.
This session took place in track MLOps & DevOps and was classified suitable for intermediate domain / intermediate python by the speaker.
Submission
The proposal as submitted by the speaker before the conference.
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. :-)
