Streamlit: turning a Python script into a data app with streamlit run

What problem Streamlit solves, and for whom

The README states the goal plainly: it "lets you transform Python scripts into interactive web apps in minutes, instead of weeks." The intended output is a dashboard, a generated report, or a chat app. The intended author is someone who already has the Python logic and does not want to build a frontend, an API layer, and a session store to show it to five colleagues.

That framing matters more than any feature list. Streamlit is not a general web framework with a Python binding. It is a rendering layer that assumes the program is a script, that the script runs top to bottom, and that the browser is a view onto the result. If your work fits that shape, the amount of code between a pandas result and a visible table is close to zero. If it does not, you will spend your time fighting the execution model rather than using it.

The README also points at Community Cloud for deploying, managing, and sharing an app once it exists. That is the second half of the pitch: local script, hosted URL, no container work in between.

The rerun model: how a script becomes a UI

The Quickstart example is the whole architecture in four lines. A slider is created, and its value is written back out. There is no callback, no event handler, and no explicit state object. When the user moves the slider, Streamlit reruns the script from the top, and the widget call returns the new value on that pass. The UI is a function of the script's execution, not a tree you mutate.

This explains most of Streamlit's behaviour and most of its constraints. Because the script reruns, anything expensive inside it runs again unless it is cached. The documentation covers caching as a first-class concept for exactly this reason. It also explains why widget identity is tied to position and arguments rather than to a variable name you assign: the framework has to match widgets across runs, and it does so from the call site.

The repository layout reflects a split runtime. The Python side lives under lib/, the browser bundle under frontend/, and the wire format between them under proto/. The root pyproject.toml is explicit that the published package metadata is not there: "The streamlit package itself is defined in lib/pyproject.toml." So the root file you see first is a development environment definition, not the thing you install. That is a small trap for anyone reading the repository to understand the shipped artifact.

One consequence worth stating directly: the rerun model makes simple things simple and stateful things awkward. A multi-step wizard with partial validation, or a form that must not lose input while a background job runs, needs care. Streamlit gives you tools for this, but the default mental model is against you.

Installing Streamlit and running a first app

The README gives the install as a two-command sequence. The first installs the package from PyPI, the second launches a built-in demo app.

$ pip install streamlit
$ streamlit hello

The README says that if this opens the Streamlit Hello app in your browser, you are set. If it does not, it points to the docs at docs.streamlit.io/get-started for platform-specific installs. That conditional is doing real work: the README does not enumerate the platform cases itself.

For an actual app, the README instructs you to create a file named streamlit_app.py in your project directory and write this:

import streamlit as st

x = st.slider("Select a value")
st.write(x, "squared is", x * x)

Then run it with the command the README gives:

$ streamlit run streamlit_app.py

What you should see: a browser tab with a single slider. Drag it, and the line below updates to the new value and its square. There is no save step and no restart. The README describes this as live editing, where the app updates as you edit the script.

Two things the README does not document, and you should not assume: the port the server binds to, and any flag for headless or remote access. Neither appears in the README. If you need those, they are a docs question, not a README question.

The README also lists the element families it considers the next step after the slider: input widgets, dataframes, charts, layout, and multi-page apps, each linked from the docs. Multi-page apps are called out as their own concept rather than a folder convention you infer, which is worth knowing before you invent your own routing.

Where the script-as-app model fails

The clearest limitation is the one the architecture implies: every interaction is a full script run. A dashboard that loads a large frame at module level will reload that frame on every widget change unless the load is cached, and caching is something you add, not something the framework does for you. For a small CSV this is invisible. For a query against a warehouse it is the difference between a usable tool and an unusable one, and the fix is a decorator you have to remember to apply.

The second limitation is scope. Streamlit renders what its element set supports. The README's own list of element categories is finite: widgets, dataframes, charts, layout, multi-page apps. Anything outside that vocabulary, such as a highly custom interaction with its own client-side state machine, means either a custom component or a different framework. The README acknowledges the component route and links to the components page, but building one is a frontend project, which is precisely what you were avoiding.

The third is contribution shape. The README states that the project has "paused accepting pull requests from outside the Streamlit maintainer team." Bug reports, feature requests, upvoting existing issues, commenting on open specs, custom components, and streamlit-extras are listed as the open paths. If your adoption plan assumes you can upstream a fix for a behaviour you depend on, that plan needs revising. You can report and you can build around it; you cannot patch it into the mainline yourself.

Finally, there is no rollback story in the README. Nothing there describes downgrading a version, pinning a release, or reverting a deployment. That is not evidence that no such path exists; it is evidence that the README is not where you will find it.

Streamlit compared with a general web framework

The honest alternative is a conventional Python web stack: a framework such as Flask or FastAPI for the server, and a JavaScript frontend for the interface. The difference is not cosmetic. In that stack you write explicit routes and explicit state, you control exactly when data is fetched, and the browser holds the interaction state that Streamlit reconstructs on each rerun. You pay for it in code volume and in the need for someone who can work on both sides.

Streamlit inverts the trade. You give up control over the request cycle and the client state, and in exchange you stop writing the frontend. For an internal tool with a handful of users and a Python-literate author, that exchange is usually correct. For a public product where a slow rerun is a lost user, or where the interaction does not map onto widgets and charts, the conventional stack is the better fit and Streamlit is a detour.

There is a middle case worth naming: a notebook. If the goal is exploration rather than a shareable interface, a notebook already does the job and Streamlit adds a deployment step. The search data around using Streamlit inside Jupyter and Colab suggests people try to bridge the two. The README does not describe a notebook integration, so treat that as an open question rather than a supported path.

Maintenance, licence, and what an upgrade costs

The repository is not archived, and the last push was on 2026-08-19, which is under a month before the date this was written. The most recent release in the repository metadata is 1.62.0, dated 2026-08-19, following 1.61.1 on 2026-08-05 and 1.61.0 on 2026-08-04. That cadence, roughly a minor release every few weeks with patch releases between, is the practical maintenance fact to plan around. It means the version you pin will be behind within a month or two, and it means release notes are the place to check before you upgrade rather than a changelog you read once.

Licensing is Apache-2.0, stated in the README and in the LICENSE file at the repository root. Apache-2.0 is a permissive licence with an explicit patent grant, and the source files carry the standard Apache header with a copyright line reading "Streamlit Inc. (2018-2022) Snowflake Inc. (2022-2026)." The NOTICES file at the root is where third-party attributions live. None of this is legal advice; if you redistribute Streamlit inside a product, read the licence text and NOTICES yourself rather than relying on a summary.

One cost that is easy to miss: the repository is a two-language build. There is a frontend/ directory and a lib/ directory, and the root pyproject.toml describes itself as development environment configuration only. If you build from source rather than installing the published package, you are taking on both toolchains. For most teams the published package is the right choice, and the README's install line reflects that.

Editorial conclusion

Adopt Streamlit when the deliverable is an internal dashboard, a report, or a chat-style tool whose state can live in a Python script and whose audience tolerates a full rerun per interaction. Do not adopt it for a public, high-traffic product surface with fine-grained client state, or as a substitute for a general web framework. Before committing, verify the version you install against the 1.62.0 release notes, check whether the rerun cost of your slowest data call is acceptable with st.cache_data, and confirm on the issue tracker whether the behaviour you depend on sits inside the maintainer-only contribution boundary described in CONTRIBUTING.md.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes