Which production server fits a low-traffic Flask app: Gunicorn with gthread, Uvicorn, or serverless?

Direct recommendation

For a low‑traffic, I/O‑bound Flask app that uses before_request/teardown_request hooks and third‑party extensions you haven't audited for async safety, Gunicorn with a single gthread worker is the safest default. It runs on Flask's native WSGI interface, guarantees hook and extension compatibility, and keeps memory predictable. Uvicorn adds an ASGI layer that still executes synchronous code in a thread pool, so you gain no true end‑to‑end async unless every downstream dependency (DB driver, HTTP client) is async‑native. Serverless (AWS Lambda via Zappa) removes idle cost but introduces cold‑start latency, hard payload/timeouts, and packaging constraints that often break Flask assumptions.

Memory footprint at low traffic

At a few requests per minute, the resident memory difference between one Gunicorn gthread worker (e.g., --worker-class=gthread --threads=4) and one Uvicorn process is small — typically tens of megabytes. The gap only becomes meaningful under sustained concurrency. Verify with your actual app:

# Gunicorn gthread
gunicorn -w 1 -k gthread --threads 4 myapp:app &
PID=$!
sleep 2
ps -o rss= -p $PID
kill $PID

# Uvicorn
uvicorn myapp:app --workers 1 &
PID=$!
sleep 2
ps -o rss= -p $PID
kill $PID

Run each under a realistic low‑rate load (1–10 req/min with occasional bursts) using wrk or locust and compare RSS, p50/p99 latency.

Extension compatibility under async views

There is no automated compatibility scanner. The reliable check is running your full test suite (or a smoke script hitting every endpoint) under the ASGI server. Typical risk patterns:

• Extensions that use threading.local or greenlet for request‑scoped state.
• Background threads started at import time.
• Synchronous database drivers (e.g., psycopg2, mysqlclient) or blocking HTTP clients (requests) called from async views — these stall the event loop and perform worse than gthread.

Quick audit commands:

grep -r "threading\.local" . --include="*.py"
grep -r "Thread(" . --include="*.py"
grep -r "import psycopg2\|import mysqlclient\|import requests" . --include="*.py"

Serverless trade‑offs for sporadic traffic

Lambda via Zappa eliminates idle billing but adds:

• Cold‑start latency: typically 300 ms–3 s for Python, varying by package size and VPC configuration.
• Payload limits: API Gateway synchronous invoke caps request/response at ~6 MB (10 MB for async). Large file uploads or responses will fail.
• Timeout ceilings: Lambda max 15 min; API Gateway integration timeout ~29–30 s. Long‑running Flask requests will be cut off.
• Zappa constraints: deployment package size limit (50 MB zipped, 250 MB unzipped), no persistent local disk, ephemeral /tmp. Apps assuming a filesystem or long‑lived processes break.

If your traffic is truly near zero and you can tolerate cold starts, serverless is cheapest. Otherwise, a small VM (e.g., 1 vCPU/1 GB RAM) running Gunicorn/gthread costs a few dollars/month and avoids these limits. Note that AWS quotas change over time — verify current payload and timeout limits before committing.

Verification checklist

1. Run existing test suite under Gunicorn gthread, Uvicorn, and a staging Zappa deploy.
2. Load‑test each at your real request pattern; capture RSS, latency percentiles, and (for Lambda) cold‑start distribution.
3. Audit extensions for thread‑local state, background threads, and blocking drivers using the grep commands above.
4. If considering Lambda, measure cold‑start latency and test near payload/timeout limits with your largest real requests.

One missing detail that could change the recommendation

What is the largest request or response payload your app handles? If it exceeds ~5 MB, API Gateway limits will likely break Lambda/Zappa, making Gunicorn the only viable option.