Does FastAPI still need Gunicorn?

Question

For a long time Gunicorn+Uvicorn was the default setup for running FastAPI in production. However, I recently came across a blog post saying:

In the meantime, this combination of Gunicorn and Uvicorn is no longer needed, as Uvicorn now also handles worker management itself

I haven't found any other sources to verify this statement. Beside this, the official documentation only mention that the tiangolo/uvicorn-gunicorn-fastapi base Docker image is deprecated, but say nothing about Gunicorn+Uvicorn setup itself

So:

1. Does modern FastAPI need Gunicorn?
2. Is there any difference between fastapi run --workers 4 main.py and gunicorn main:app -w 4 -k uvicorn.workers.UvicornWorker now?

• Charles Duffy: Upstream uvicorn (not FastAPI!) no longer recommends gunicorn. That said, yes, absolutely there's "any difference"; they're very different implementations. (The main reason I would give to use gunicorn today is its systemd integration, which goes as far as support for inheriting listen sockets, and fully implements the sd_notify protocol when started as a service of Type=notify).
• Charles Duffy: ...that said, I don't think this is on-topic here; Stack Overflow is for questions about developing code, not deploying it -- system administration is a Server Fault topic.

Answer 1

No. Since Uvicorn 0.30 (released May 2024), it's no longer necessary. That version introduced a built-in multi-process supervisor that supports:

• --workers to launch multiple processes

• Automatic restart of crashed workers

• Request limits via --limit-max-requests for leak mitigation

Shortly after, FastAPI’s creator deprecated the tiangolo/uvicorn-gunicorn-fastapi Docker image, stating:

Now that Uvicorn supports managing workers with --workers, including restarting dead ones, there's no need for Gunicorn.

Starting with FastAPI 0.110, the fastapi run CLI is just a thin wrapper around this new Uvicorn supervisor. So the official recommendation is now plain uvicorn or fastapi run for most use cases.

• Charles Duffy: True as far as it goes, but I wouldn't call this complete. There are still good reasons to use guvicorn, even if they're niche and don't apply to everyone.
• RayB: Can you give an example of what such a reason would be?
• Charles Duffy: systemd integration, for one. I can have systemd .socket units trigger gunicorn service startup, and gunicorn will inherit the listen sockets created by systemd instead of opening new ports itself. That means clients can connect much earlier at boot time -- before your services and their dependencies have finished starting up -- and their connections just stall for a bit until the server is ready, instead of having the connections fail.