How do you deploy a FastAPI app to production?

Question

Accepted Answer

FastAPI is an **ASGI** application, so production deployment uses an ASGI server — typically **Uvicorn** (often managed by **Gunicorn** for multiple workers), behind a reverse proxy like nginx. Containerization (Docker) is the common modern approach.

## The production server stack

```bash
# ❌ the dev server (with --reload) is NOT for production
uvicorn main:app --reload

# ✅ production: Gunicorn managing multiple Uvicorn workers (uses all CPU cores)
gunicorn main:app -w 4 -k uvicorn.workers.UvicornWorker --bind 0.0.0.0:8000
# -w 4 → 4 worker processes (rule of thumb: ~2 × CPU cores)
```

```text
Client → NGINX (reverse proxy: TLS, static files, load balancing)
           → GUNICORN (process manager) → UVICORN workers (run the ASGI app)
Multiple workers let FastAPI use multiple CPU cores (each worker = one process).
```

## Dockerizing the app (common)

```dockerfile
FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["gunicorn", "main:app", "-w", "4", "-k", "uvicorn.workers.UvicornWorker", "--bind", "0.0.0.0:8000"]
```

A container packages the app and its dependencies for consistent deployment across environments (then run on Kubernetes, ECS, or a PaaS like Railway/Render/Fly).

## The production checklist

```text
1. Config & secrets via environment variables (not in code); validate at startup
2. Multiple workers (Gunicorn + Uvicorn workers) for CPU utilization
3. HTTPS/TLS (at nginx or the platform/load balancer)
4. A real database (PostgreSQL) + connection pooling; run migrations (Alembic)
5. CORS configured to an allowlist (not "*") for browser clients
6. Logging + error monitoring (Sentry) + health-check endpoint
7. A separate worker service (Celery/ARQ) + broker (Redis) for background jobs
8. Horizontal scaling: multiple instances behind a load balancer — keep app STATELESS
   (sessions/state in Redis, not process memory)
```

## Async and statelessness

```text
✓ Each worker runs its own event loop → workers give parallelism, async gives concurrency
✓ Keep the app STATELESS so you can run many instances behind a load balancer
```

## Why it matters

Deploying FastAPI correctly is essential for taking applications to production, and it involves important considerations specific to its **ASGI** nature that differ from the development setup.

Understanding the production server stack is foundational: the development server (`uvicorn --reload`) is not for production, so you run the app via an ASGI server — **Uvicorn workers managed by Gunicorn** for multiple processes (utilizing all CPU cores, since each worker runs its own event loop), typically behind nginx for TLS and load balancing. **Containerization (Docker)** is the common modern approach for consistent, portable deployments.

Beyond the server setup, the production checklist covers security- and reliability-critical concerns: configuration and secrets via environment variables (never in code), HTTPS, a real database with migrations and pooling, proper CORS, logging and monitoring, separate worker services for background jobs, and — for scaling — running **multiple stateless instances** behind a load balancer (keeping state in Redis, not process memory).

Knowing how to deploy FastAPI with the right ASGI server stack, containerization, multiple workers, and production hardening is important senior-level knowledge, since every real FastAPI application must be deployed correctly to be performant, secure, and scalable — making this a frequently-relevant, professionally-essential topic for shipping production APIs.