Interactive AI application framework

How to use
Gradio.

Rapidly turning Python functions, models, agents, media pipelines, and APIs into interactive demos, internal tools, evaluation interfaces, and production AI web applications.

Open Gradio ↗ Open console ↗
What it isopen-source Python and JavaScript framework for building, testing, sharing, and serving interactive machine-learning and AI applications Workflows2 UpdatedSeptember 2026

Gradio is a open-source Python and JavaScript framework for building, testing, sharing, and serving interactive machine-learning and AI applications. Rapidly turning Python functions, models, agents, media pipelines, and APIs into interactive demos, internal tools, evaluation interfaces, and production AI web applications. This guide covers the whole path in one place: official access, a first session that produces something reviewable, the checks that make output trustworthy, and the permissions worth limiting before you connect real work.

Troiana principle

AI should make the work easier to inspect. If the workflow removes the source, the owner, or the review step, redesign the workflow.

01

Access & setup

Find, install, and sign in to Gradio

Get into the official Gradio experience with the right account and a setup you understand.

  1. 01

    Start at https://www.gradio.app/ and confirm the domain before entering account or payment information.

  2. 02

    Availability: Gradio installs as a Python package for local or hosted applications, with Python and JavaScript clients, browser-based interfaces, temporary share tunnels, Hugging Face Spaces deployment, and self-hosted options.

  3. 03

    A supported Python environment, an application function or model endpoint, pinned dependencies, secret management, production authentication and authorization, file and cache controls, resource limits, monitoring, and a deployment and rollback plan.

  4. 04

    Sign in with the account you intend to keep using, then review plan, data, notification, and permission settings.

  5. 05

    Run one low-risk test task before connecting sensitive files, repositories, or workspace data.

  • Use official download pages.
  • Review permissions during setup.
  • Keep installers and applications updated.
02

First session

Your first useful Gradio session

Learn the interaction loop using a small task with a clear outcome.

  1. 01

    Define the users, task, inputs and outputs, model or API boundary, data classes, authentication, latency, concurrency, file handling, abuse controls, hosting, and rollback requirements.

  2. 02

    Create a virtual environment, pin Gradio and application dependencies, build a minimal Interface or Blocks app, and keep provider credentials in server-side environment or secret storage.

  3. 03

    Test component types, validation, errors, cancellation, queueing, streaming, state, uploads, generated files, simultaneous users, and model failures locally with representative and adversarial cases.

  4. 04

    Deploy behind production identity, TLS, rate and resource limits, monitor errors and queues, verify file cleanup and access boundaries, and retain a pinned prior image for rollback.

  • State the outcome before the background.
  • Provide the real source material.
  • Review the result before expanding the task.
03

Quality control

Check the quality of Gradio output

Establish that a change is safe to run in production and reversible if it is not.

  1. 01

    Restate the intended end state and the blast radius before applying anything.

  2. 02

    Review the generated configuration line by line against the provider's current documentation.

  3. 03

    Apply to a non-production environment first and confirm the observed result matches the intended one.

  4. 04

    Confirm the rollback path works by actually exercising it, not by assuming it exists.

  5. 05

    Check cost, scaling limits, and network exposure before the change reaches production traffic.

  • Test the rollback, do not assume it.
  • Check what a configuration exposes to the public internet.
  • Watch cost and rate limits as closely as correctness.
04

Privacy & permissions

Use Gradio safely

Keep credentials, network exposure, and cost under deliberate control.

  1. 01

    Use scoped, short-lived credentials, and never paste production secrets into a prompt or config file.

  2. 02

    Confirm what each change exposes publicly before applying it, especially storage, databases, and admin endpoints.

  3. 03

    Separate environments so a mistake in development cannot reach production data.

  4. 04

    Set billing alerts and hard quotas before enabling autoscaling or usage-based services.

  5. 05

    Review audit logs and revoke access for integrations that are no longer in use.

  • A Gradio share link makes the locally running app publicly reachable, and uploaded, returned, cached, static, or explicitly allowed files can become URL-accessible. Built-in password authentication is described as a basic layer and lacks controls such as MFA, rate limiting, and automatic lockout. Use production-grade identity at the edge, keep allowed paths minimal, block sensitive paths, cap upload and request size, never turn user text into a returned file path, isolate model execution, expire caches, and do not expose secrets in client code or app state.
  • Follow your organisation's approved-use policy.
  • Never treat fluent output as authorization to act.
05

Core workflows

Step-by-step ways to use Gradio for the work it does best.

Each workflow below has its own outcome, steps and review checkpoints.

01 WorkflowBuild and deploy a production Gradio application

Move from a local model interface to a pinned, authenticated, observable service with bounded queues, resources, state, and failure behavior.

 02 WorkflowSecure Gradio uploads, outputs, and share links

Treat every upload, returned path, cache entry, static directory, allowed path, and temporary public tunnel as an explicit exposure boundary.

Workflow 01

Build and deploy a production Gradio application

Move from a local model interface to a pinned, authenticated, observable service with bounded queues, resources, state, and failure behavior.

Outcome: Serve real users without exposing a development tunnel, cross-user state, unbounded model capacity, or secrets embedded in the browser application.

  1. 01

    Define users, identity, roles, inputs and outputs, model or API boundary, secrets, state, concurrency, latency, cancellation, files, abuse controls, SLO, hosting, and rollback.

  2. 02

    Pin Python, Gradio and model dependencies in a minimal image, run as a non-root identity, keep credentials in server secret storage, and separate temporary, cache, model, and application directories.

  3. 03

    Use typed components and server-side validation, isolate user sessions, bound queue and concurrency, set timeouts and upload limits, handle cancellation and retries, and return safe display values rather than raw paths.

  4. 04

    Place the app behind TLS and production identity with authorization, CSRF and origin controls, request and rate limits, network restrictions, redacted logs, health checks, and resource monitoring.

  5. 05

    Test concurrent users, state isolation, malformed files, slow and failed models, disconnects, exhaustion, restart and upgrade, then canary a pinned image and retain the prior deployment for rollback.

What good use looks like

  • Use production identity at the edge.
  • Bound queues and model concurrency.
  • Keep session state isolated.
06

Official references

Check the current product documentation.

Features, plan limits, availability, and data controls change. These official pages are the starting points used for this guide.

Explore the Troiana AI Hub →