Gradio: Python Web Apps for Machine Learning Models

The gap Gradio fills between a model function and a link

A trained model is usually a Python function: take an image, return a label. Turning that into something a colleague can click requires a front end, a server, a file upload path, and a way to send the result back. Gradio exists to remove that work. The README states the package lets you build a demo or web application for a machine learning model, an API, or any arbitrary Python function, and share a link to it in seconds, with no JavaScript, CSS, or web hosting experience needed.

The audience is narrow and specific. It is the researcher or engineer who already has working Python and needs a UI for a review meeting, a paper artifact, or a stakeholder check. It is also the person who wants to expose a function to another program, since the Interface example in the README sets api_name="predict", which gives the demo a named endpoint rather than only a page. What Gradio is not is a product framework. There is no account system, no billing, and no database in the core package. If your requirement is a multi-user service with authentication and persistence, you are outside the intended use and will spend more time bending Gradio than writing your own routes.

Interface, inputs, outputs: the three arguments that define a demo

The core object is gr.Interface. The README describes three arguments. fn is the function to wrap. inputs is the component or list of components used for input, matching the function arguments in order. outputs is the component or list of components used for the return values. Components can be passed as a string name such as "textbox" or as an instance such as gr.Textbox(). The README says Gradio includes more than 30 built-in components, naming gr.Textbox(), gr.Image(), and gr.HTML() as examples.

That positional matching is the whole contract. If your function takes two arguments and you pass one input component, the mapping is wrong; the README states the number of components should match the number of arguments. The same applies to returns. This is simple when the function is a single prediction call and awkward when it is a stateful object with side effects, because every submission is a call with the declared arguments and nothing else. The launch() call starts a local server. The README says the demo opens in a browser at http://localhost:7860 when run from a file, and appears embedded in the notebook when run inside one. The underlying stack is visible in requirements.txt: fastapi, starlette, and uvicorn, with gradio_client pinned at 2.7.0. Gradio is a web application on top of an ASGI server, not a static generator.

Install Gradio with pip and run a first app

The README states the prerequisite is Python 3.10 or higher, and pyproject.toml sets requires-python to >=3.10. Install with pip, which ships with Python. The README recommends a virtual environment and links to a guide on installing Gradio in one.

pip install --upgrade gradio

Write a file named app.py. This is the README's first example, with a function that takes a name and a slider value and returns a greeting.

import gradio as gr

def greet(name, intensity):
    return "Hello, " + name + "!" * int(intensity)

demo = gr.Interface(
    fn=greet,
    inputs=["text", "slider"],
    outputs=["text"],
    api_name="predict"
)

demo.launch()

Run it with python app.py. The README says the demo opens in a browser at http://localhost:7860 when running from a file. Type a name, drag the slider, press Submit, and the greeting appears on the right. For iteration, the README documents hot reload mode: type gradio before the filename instead of python, so gradio app.py restarts the app when the file changes. The same section documents a --vibe flag, gradio --vibe app.py, which the README describes as providing an in-browser chat for writing or editing the app in natural language. That flag is newer and less conventional than hot reload; treat it as a convenience, not a substitute for understanding the Interface arguments.

Sharing is one parameter. The README's second example keeps the same structure and changes the last line.

demo.launch(share=True)

The README states this generates a public URL in a matter of seconds, in the form https://a23dsf231adb.gradio.live, while the model and all computation continue to run locally on your computer. That is the trade: the page is public, the compute is yours, and the process must stay alive for the link to work.

What share=True actually exposes, and when Gradio is the wrong tool

The share link is the feature most likely to cause an incident. The README is explicit that anyone around the world can try the demo from their browser while computation runs on your machine. There is no statement in the README that the temporary URL is authenticated, rate limited, or tied to an allowlist. If the wrapped function reads private files, calls a paid API, or returns data derived from user records, a public URL is a data path you did not intend to open. The README recommends reading the dedicated guide on sharing your application before relying on it; that guide, not this article, is where the access controls would be documented.

The second limitation is the Interface model itself. Gradio's own repository contains a demo directory with examples such as blocks_essay, blocks_chained_events, and blocks_flag, which signals that anything beyond a single function call moves you from gr.Interface to gr.Blocks and a more manual layout. That is a real step up in complexity, and the README's overview does not cover it.

The third is process lifetime. A launched app is a running Python process. Stop it, and the local port and the share URL both stop responding. There is no built-in restart, queue durability, or persistence described in the README. For a demo this is fine. For anything a user expects to find tomorrow, it is not.

Gradio compared with Streamlit, and what the difference costs you

Streamlit is the comparison people search for, and the two take different routes to the same destination. Streamlit runs a script top to bottom on every interaction and renders widgets as a side effect of that execution, so the page is the program and state lives in the script run. Gradio inverts this. You declare a function and the components that feed it, and Gradio builds the event wiring around that function; the README's Interface example is a function plus an inputs list plus an outputs list, with api_name="predict" naming the endpoint.

The practical consequence is that Gradio treats your function as an API with a UI attached, which is why the same demo can be called programmatically, and why the client package gradio_client is pinned in requirements.txt. Streamlit treats the script as the application, which makes arbitrary layouts and multi-step dashboards easier to express and makes a clean programmatic endpoint less natural. Neither is better in the abstract. If your deliverable is a model endpoint that also needs a page, Gradio's shape matches. If your deliverable is an interactive report with charts, tables, and conditional sections, the script-rerun model fits the problem more directly, and you will fight the Interface abstraction less.

Licence, release cadence, and the cost of upgrading

Gradio is licensed under Apache-2.0, stated in both the README badge block and the license field in pyproject.toml. That is a permissive licence with an explicit patent grant, and it does not require you to publish your own source. It also does not grant trademark rights, and it says nothing about the data your demo processes. If your app sends user input to a third-party model API, the licence of Gradio is irrelevant to that data flow; that is a separate agreement. Nothing here is legal advice.

The project is not archived, and the last push was on 2026-08-24. The release list shows [email protected] on the same date, alongside @gradio/[email protected] and @gradio/[email protected]. The repository layout shows a changeset directory and a ci:version script in package.json that runs changeset version, so versioning and changelogs are automated rather than hand-written. That matters for upgrade cost: releases are frequent and small, which means fewer breaking changes per step but a steady stream of them.

The pin that will bite is gradio_client==2.7.0 in requirements.txt. That is an exact pin, not a range, so the Python client and the server move together. If you call a Gradio app from another service, upgrade the client and the server in the same change or expect a mismatch. The Python floor is the other fixed cost: requires-python is >=3.10 and the classifiers list 3.10 through 3.13, so an environment on 3.9 cannot install the current release at all.

Editorial conclusion

Adopt Gradio when the deliverable is a demo of a Python function and the audience needs a link within minutes. Skip it when you need a custom front end, a multi-tenant product, or a UI whose behaviour is not expressible as inputs and outputs. Before committing, verify the Python version against the requires-python floor of 3.10, check that gradio_client 2.7.0 is the client you intend to pin, and confirm whether the temporary gradio.live URL is acceptable for your data.

Frequently asked questions

Official sources

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