FastAPI CLI: the fastapi command that wraps Uvicorn and finds your app object

A command that arrives with the framework

FastAPI CLI is not a separate tool you hunt down and configure. The README states that when you install FastAPI with pip install "fastapi[standard]", that install includes a package called fastapi-cli, and that package provides the fastapi command in the terminal. The project description puts it plainly: run and manage FastAPI apps from the command line.

That packaging choice defines the audience. Anyone already writing FastAPI gets the CLI as a side effect of the standard install, which means the decision to use it is not a separate dependency decision but a habit decision. The people it serves are application developers who want to start, restart and serve their service without remembering how Uvicorn wants its import string spelled, and people who deploy the same codebase in a container and want one command shape in both places.

The repository is small and focused. The root holds pyproject.toml, a src/ directory, tests/, scripts/, a uv.lock file and a release-notes.md, with no documentation site of its own but a Documentation link pointing to the FastAPI documentation.

Internally the README says FastAPI CLI uses Uvicorn as the ASGI server. The tool is a front end over a server you could also call yourself, which is the key to understanding both its value and its limits.

How the app object gets found and imported

This is the part of the tool that saves the most typing. The README says FastAPI CLI takes the path to your Python program and automatically detects the variable with the FastAPI, commonly named app, and how to import it, and then serves it.

The development output in the README shows the mechanics. FastAPI CLI searches for the package file structure from directories with __init__.py files, imports from the working directory, then imports the app object with the line from main import app and records the result as the import string main:app. In other words, the CLI resolves a module path plus an attribute name, which is exactly the pair Uvicorn expects, and it derives it for you from the filename you passed.

$ fastapi dev main.py

The same output shows the server reporting that it will watch for changes in the directory it imported from, and the reloader running on WatchFiles. So in development the CLI does two things at once: it figures out the import target and it keeps the process alive across edits.

The convention is the dependency. If your app object is not a module-level variable in a file you point at, the auto-detection has less to work with, and the README documents no override flag for naming the attribute explicitly.

dev and run differ in exactly two visible ways

The two commands are the same machinery with different defaults, and the README is specific about both.

fastapi dev runs in development mode. Auto-reload is enabled by default, and the README is blunt about the cost: it is resource intensive and could be less stable than without it, so it should only be used for development. The default bind address is 127.0.0.1, which the README explains as the address a machine uses to talk to itself alone, so the server is not reachable from the network.

fastapi run runs in production mode. Auto-reload is disabled by default, which is the whole point of having two commands. The default bind address becomes 0.0.0.0, meaning all available IP addresses, which the README describes as the normal production arrangement, for example inside a container.

That second change is the one that deserves attention. Binding 0.0.0.0 exposes the service to anything that can reach the machine, and the README is explicit that in most cases you would, and should, have a termination proxy handling HTTPS on top. It also points out that the proxy may be supplied by your provider, or may be something you set up yourself, and refers to the FastAPI deployment documentation. The CLI does not terminate TLS, and reading the two commands as interchangeable is the most common way to get this wrong.

FASTAPI_ENV is set by dev and left alone by run

The environment variable handling is the most easily missed detail, and it is the one that will bite an application whose startup code branches on configuration.

Before importing your app, fastapi dev sets the FASTAPI_ENV environment variable to development. If FASTAPI_ENV is already set, its existing value is preserved. The README frames this as a way to let app startup code choose development-friendly behavior while still allowing you to supply an app-specific environment such as staging.

The asymmetry matters. fastapi run currently leaves FASTAPI_ENV unchanged, and the README says to set it explicitly if your app needs to detect production mode. So the presence of the flag in your codebase is not a signal that the process is running in development, because a run under an unset environment has no value at all, and a dev under a preset staging value reports staging. The conventional values are development and production.

The ordering is also worth noting: the variable is set before the app is imported, so startup code that reads it at import time sees the value. Application code that caches the environment at import time will not observe a later change to the variable.

If your service has separate staging and production deployments that both use fastapi run, the flag has to come from your process manager or container environment, not from the CLI.

What pyproject.toml pins and what the extras add

The packaging metadata tells you the compatibility envelope and where the tool actually gets its features.

The project requires Python 3.10 or newer, and the classifiers list 3.10 through 3.14, so 3.9 and older are outside the supported range. The runtime dependencies are typer >= 0.26.1 for the command line interface, uvicorn[standard] >= 0.15.0 for the server, rich-toolkit >= 0.14.8 for the formatted terminal output, and tomli >= 2.0.0 only when running on Python older than 3.11. The MIT license is declared in the metadata with the LICENSE file included.

The optional dependency groups are where the extra tooling lives. The standard group adds fastapi-cloud-cli >= 0.1.1 alongside uvicorn[standard], and there is a separate standard-no-fastapi-cloud-cli group that keeps uvicorn[standard] without that package, which exists for environments where the cloud CLI is unwanted. A third group, new, pulls in fastapi-new >= 0.0.2.

Those names explain a lot. The tool is built on Typer, which is why the command structure and help output look the way they do, and rich-toolkit is why the dev output in the README is formatted into aligned labels rather than plain lines. A related group also points at project scaffolding through fastapi-new, and the README does not describe its behaviour, so treat it as an undifferentiated extra unless you read its own documentation.

A 0.0.x version number and a beta status

The release record is short and the version numbers are small. Recent published releases include 0.0.30 on 2026-07-15, 0.0.31 on 2026-07-16 and 0.0.32 on 2026-07-16. The repository is not archived and the last push was on 2026-10-05, so work continued after those tags.

The metadata classifies the project as Development Status :: 4 - Beta, and the version scheme has not reached 1.0. That combination tells you the command surface may still shift between patch releases. If you bake fastapi dev or fastapi run into a Dockerfile entrypoint or a Makefile, an unpinned upgrade can change behaviour under you. Pinning the fastapi-cli version is the cheap insurance here, and release-notes.md in the repository root is where to check what changed in a given release.

The tool is also a thin wrapper, and that has consequences for when to reach for something else. If your deployment already runs a specific ASGI server with specific options, or relies on a process manager that owns the command line, the wrapper removes flexibility rather than adding it. A team that wants uvicorn invoked directly, with its own flags and its own reload strategy, gains nothing by adopting the CLI and loses the ability to see exactly what is being launched.

Editorial conclusion

FastAPI CLI is a sensible default for teams that already run FastAPI on Uvicorn and want one command that locates the app object, handles the reload difference between development and production, and keeps the binding address straight. It is the wrong choice for a service that does not follow the app variable convention, for a deployment where a process manager or a different ASGI server already owns the command line, or for a project that needs the production environment flag set automatically. Before standardising on it, confirm that fastapi run leaves FASTAPI_ENV unchanged in your setup and set that variable yourself, keep the terminating proxy in front of the 0.0.0.0 bind, and read release-notes.md, since the published versions are still in the 0.0.x series.

Frequently asked questions

Official sources

1. fastapi/fastapi-cli on GitHub
2. Issues
3. License: MIT
4. README
5. Releases