Key takeaways
- FastAPI is a Python web framework for building APIs with type hints, automatic validation and interactive docs.
- It is used for REST APIs, ML and LLM model serving, RAG backends, microservices and internal tools.
- Run it with fastapi dev during development and fastapi run or Uvicorn workers in production.
- Any ASGI server works, not only Uvicorn; in notebooks, use TestClient or run the server in a background thread.
- A production setup adds configuration, logging, migrations, tests and a container image.
FastAPI is a Python framework for building web APIs: you write functions with type hints, and FastAPI turns them into HTTP endpoints with automatic request validation, JSON responses and interactive documentation. It is widely used to serve machine learning models and LLM features, and it is the backend I used for RAG.NextUpgrad and my other NextUpgrad applications. This page explains what it is used for, shows examples, covers running it with and without Uvicorn and in notebooks, and gives a Dockerfile and production template guidance.
What is FastAPI in Python?
FastAPI is an open-source Python web framework for building APIs quickly and correctly. It uses standard Python type hints with Pydantic models to validate inputs and shape outputs, and runs on ASGI servers for asynchronous performance.
You define endpoints as functions decorated with the HTTP method and path, such as @app.get("/items/{item_id}"). FastAPI reads the type hints to parse path, query and body parameters, rejects invalid requests with clear errors, and documents everything automatically at /docs. It also provides dependency injection, which handles shared resources such as database sessions and authentication cleanly. The result is less boilerplate and fewer bugs than hand-written validation.
What is FastAPI used for in Python?
FastAPI is used to build REST and JSON APIs, serve machine learning and LLM models, power retrieval-augmented generation backends, create microservices, handle webhooks, and build internal tools and admin backends.
Common examples:
- An inference endpoint that runs a model and returns predictions.
- A RAG API that retrieves passages and streams a cited answer.
- A backend for a React or Next.js front end.
- Webhook receivers for payment or messaging services.
- Data and automation APIs that other teams call.
Its async support suits I/O-heavy work, such as calling databases and external APIs; for heavy CPU work, pair it with background workers. Because it is plain Python, the code that loads a model or a vector index in a notebook moves into an endpoint with little change, which is why data scientists and ML engineers adopt it quickly.
How do I use FastAPI in Python?
Install it, create an app, define endpoints with type hints and Pydantic models, and run it with the FastAPI CLI. The interactive docs at /docs let you test endpoints immediately.
Also asked as: how to use fastapi in python
from fastapi import FastAPI
from pydantic import BaseModel
app = FastAPI()
class Question(BaseModel):
text: str
top_k: int = 5
@app.post("/ask")
def ask(q: Question):
return {"question": q.text, "top_k": q.top_k, "answer": "stub"}
pip install "fastapi[standard]"
fastapi dev main.py
Send an invalid body, such as a string for top_k, and FastAPI returns a clear 422 error explaining what is wrong.
What are some FastAPI examples in Python?
Typical examples are a CRUD API with a database, a file upload endpoint, an authenticated endpoint with dependencies, a streaming response for LLM output, and a background task. Here is a streaming example.
Also asked as: fastapi examples python
from fastapi import FastAPI
from fastapi.responses import StreamingResponse
import time
app = FastAPI()
def tokens():
for word in "Retrieval augmented generation grounds answers in documents".split():
yield word + " "
time.sleep(0.1)
@app.get("/stream")
def stream():
return StreamingResponse(tokens(), media_type="text/plain")
Streaming like this is how chat interfaces show answers as they are generated. The FastAPI documentation has tutorials for each pattern, from path parameters to security.
How do I run a FastAPI server?
During development, run fastapi dev main.py, which starts a server with auto-reload on port 8000. In production, run fastapi run main.py or Uvicorn with several worker processes, usually behind a reverse proxy.
Also asked as: how to run fastapi server
Production basics: set the host to 0.0.0.0 inside containers so the server is reachable, choose the number of workers based on CPU cores, configure timeouts, and run behind a proxy or load balancer that handles HTTPS. Keep settings in environment variables. Add a health endpoint for monitoring and container orchestration.
How do I run FastAPI with Uvicorn?
Install Uvicorn, then point it at your app object with module:variable syntax, for example uvicorn main:app --reload for development or with workers for production.
Also asked as: how to run fastapi with uvicorn
uvicorn main:app --reload # development
uvicorn main:app --host 0.0.0.0 --port 8000 --workers 4 # production-style
The FastAPI CLI uses Uvicorn under the hood, so fastapi run and uvicorn give similar results; the CLI just picks sensible defaults. Use --reload only in development, since it watches files and restarts. In containers, a single Uvicorn process per container with scaling handled by the platform is a common pattern.
Can I run FastAPI without Uvicorn?
Yes. FastAPI is an ASGI application, so any ASGI server can run it, such as Hypercorn or Granian. Uvicorn is simply the most common and the default used by the FastAPI CLI.
Alternative servers may offer features such as HTTP/2 or different performance characteristics; benchmark with your workload before switching. For testing, you do not need a server at all: FastAPI's TestClient calls your app directly in Python, which is how unit tests usually work. Serverless platforms that support ASGI can also host FastAPI through adapters. Whichever server you choose, keep application code independent of it, so switching servers later is a one-line change in your start command or container configuration rather than a rewrite.
Can I run FastAPI in a Jupyter notebook or Colab?
Yes, with care. For testing logic, use TestClient in the notebook to call endpoints without a server. To run a real server, start Uvicorn in a background thread so it does not block the notebook's event loop.
Also asked as: can i run fastapi in jupyter notebook
from fastapi.testclient import TestClient
client = TestClient(app)
print(client.post("/ask", json={"text": "What is RAG?"}).json())
For a live server in Colab, you would also need a tunnel to reach it from outside, which exposes your app publicly, so protect it and stop it afterwards. For anything beyond quick experiments, move the code into a .py file and run it with the FastAPI CLI locally or in a container.
What is a good Dockerfile example for Python FastAPI?
A simple, production-friendly Dockerfile uses a slim Python base image, installs dependencies first for caching, copies the app, and runs it with the FastAPI CLI on all interfaces.
Also asked as: dockerfile example python fastapi
FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 8000
CMD ["fastapi", "run", "main.py", "--port", "8000"]
Add a .dockerignore to keep virtual environments and secrets out of the image, pass configuration through environment variables, and run as a non-root user for better security. Build with docker build -t myapi . and run with docker run -p 8000:8000 myapi.
What is a production-ready FastAPI template?
The FastAPI team maintains a full-stack template with FastAPI, SQLModel, PostgreSQL, a React front end, Docker Compose, authentication, migrations and tests, which is a good reference for production structure.
Also asked as: production-ready fastapi template (python
What a production setup should include, whether from a template or your own:
- Structure: routers by feature, separate schemas and models, a settings module.
- Database: SQLModel or SQLAlchemy with Alembic migrations.
- Security: authentication, CORS configuration, input limits, secrets in environment variables.
- Observability: structured logging, metrics, health checks.
- Quality: tests with TestClient, linting and CI.
- Deployment: Dockerfile, Compose for local services, and a platform for production.
Start from a template, but understand every piece; delete what you do not need.






