fastapi-mvc scaffolds a whole FastAPI service, not just a starter

A generator that produces a deployment, not a library you import

fastapi-mvc describes itself as a developer productivity tool for making high quality FastAPI production-ready APIs, and the key thing to understand is that it is a generator, not a dependency. The project comes with a number of scripts called generators that create everything necessary to start working on a particular task, and the newest one is the application generator, which provides the foundation of a fresh FastAPI application. The template itself lives in a separate repository, the project scaffold at fastapi-mvc/copier-project, and the generated output is a normal repository of your own, illustrated by the example generated project linked from the README. The generator is built on Copier, with copier pinned as the runtime dependency alongside click for the command line, and the CLI is exposed under two names, fastapi-mvc and the shorter fm. The audience is a developer who wants the boring parts of a service skeleton decided for them.

Three commands from empty directory to a running service

The quick path is short enough to follow in a terminal. Creating a project is one command.

$ fastapi-mvc new /tmp/galactic-empire

That creates a project called galactic-empire in the given directory and installs its dependencies using make install. Then you run the development server, which is uvicorn over ASGI.

$ cd /tmp/galactic-empire
$ fastapi-mvc run

The README confirms it works with a request to the ready endpoint.

$ curl 127.0.0.1:8000/api/ready
{"status":"ok"}

Adding endpoints is also a generator call, where the arguments name the controller, its actions and the HTTP method for each.

$ fastapi-mvc generate controller death_star status load:post fire:delete

The generated endpoints then answer on the paths the controller defined, and the server logs show the requests arriving.

What the generated project contains, and how much of it is opinionated

The feature list in the README is the inventory of the generated project, and it is a heavy one. The project is based on the MVC architectural pattern, it comes with a WSGI plus ASGI production server, it ships with Sphinx documentation and 100 percent tests coverage, and it includes a Makefile, GitHub actions and utilities. For deployment there is a Kubernetes deployment with a Redis HA cluster, a Helm chart for Kubernetes deployment, and a Dockerfile with Kubernetes and cloud in mind. Dependency management uses Poetry, and there is a set of Nix expressions. There is also a virtualized reproducible development environment using Vagrant, and a documented way to update an already generated project with changes from a new template version, which is the feature that decides whether this tool is worth the setup. The cost of that inventory is that you are accepting a large set of opinions about directory layout, server choice, documentation tooling and deployment shape on day one.

You can install it three ways, and the Nix path is reproducible

The package is on PyPI and installs with pip.

pip install fastapi-mvc

It also builds from a Nix flake, and the README shows the optional binary cache setup first, which is what makes the build fast rather than slow.

nix-env -iA cachix -f https://cachix.org/api/v1/install
cachix use fastapi-mvc
nix build github:fastapi-mvc/fastapi-mvc#default --profile $HOME/.nix-profile

The Nix route matters more than it might look, because the whole promise of a generator is that two people running it get the same tree, and a flake with a pinned lock file is a stronger version of that promise than a package manager alone. The repository layout backs it up, with a flake.nix, a flake.lock, a build.nix, an image.nix, a .envrc for direnv, a treefmt.toml for formatting and a TAG file holding the current version string. There is a dedicated Nix CI workflow badge alongside the main one, so the Nix build is tested rather than aspirational.

The generated Dockerfile treats reproducibility as a requirement

The Dockerfile in the repository is worth reading on its own, because it shows what the maintainer thinks reproducibility means. The builder stage is pinned to a digest rather than a tag, with a comment noting the digest points to the python:3.13-slim-trixie tag, and the environment sets PYTHONUNBUFFERED, PYTHONHASHSEED to zero, SOURCE_DATE_EPOCH to a fixed value, CFLAGS to -g0 and PYTHONDONTWRITEBYTECODE, along with a pinned uv version. The apt sources are rewritten to a Debian snapshot archive for a specific date with the check-valid-until check disabled, so the package versions cannot drift. The runtime stage is a distroless Python image, also pinned by digest, and the comment explains that the digest is used because that image has no tags for a particular minor version and to lock the Python version at 3.13.5. The uv install options explicitly exclude the test and docs extras. A template that goes this far is making a statement about what a production Dockerfile should look like.

Where the generator is the wrong shape of tool

The main limitation is that all of this value is delivered once, at generation time. A team that already has a FastAPI service, with its own layout, its own test strategy and its own deployment, gets nothing from the generator except the ability to add a controller, and the controller is a code generator over a template rather than a library API. The second limit is the same one every template has, which is that the opinions are frozen. The generated project comes with Sphinx documentation, a Makefile, GitHub actions, Vagrant and Nix expressions, and if your organisation has none of those, or has different ones, you are deleting most of what you just generated. The third is the maturity signal. The package classifiers say Development Status 3, Alpha, the version is 0.29.0, and the release history has a gap between 0.28.1 in July 2023 and 0.29.0 in February 2026. The last push was on 2026-05-11. So the tool is usable and maintained, but it is alpha, and adopting an alpha generator means owning the output afterwards, including the parts you did not want.

Editorial conclusion

fastapi-mvc suits a team that wants a full production skeleton for a FastAPI service on the same afternoon, and it suits anyone who wants to see what a well laid out FastAPI deployment looks like, since the generated project is a working reference rather than a toy. It is the wrong tool for a team that already has a FastAPI service and only wants a few endpoints, because the value is in the initial scaffold, and it is the wrong tool if you cannot accept a Copier based template, since the project is not a library you import but a template you copy into your own repository. Before running it, decide whether the generated layout matches how your team already organises code, and note that the package is marked Development Status 3, Alpha. The last push was on 2026-05-11 and the current release is 0.29.0 from 2026-02-11.

Frequently asked questions

Official sources

1. fastapi-mvc/fastapi-mvc on GitHub
2. License: MIT
3. Project website
4. README
5. Releases