fastapi-fullstack: a project generator for FastAPI and Next.js AI agent apps

What fastapi-fullstack generates, and who the wizard is aimed at

The repository is a generator, not a framework you import. Its published package is named fastapi-fullstack, and the README describes it as a "Production-ready FastAPI + Next.js project generator with AI agents, RAG, and 20+ enterprise integrations." Running the CLI produces a new directory containing a backend, a frontend and deployment files; the template itself lives under template/ in the repository, and the generator code lives in fastapi_gen/.

The intended user is a small team that has decided on FastAPI for the API and Next.js for the UI and does not want to wire authentication, migrations, WebSocket streaming and a vector store from scratch. The README's feature list names JWT, OAuth, an admin panel, Celery, Docker and Kubernetes among the pieces the template brings in. That is a lot of surface area to assemble by hand, which is the actual argument for the project.

It is a poor fit for anyone who wants a library to depend on, or who has already committed to a different backend language. The generator emits Python and TypeScript; nothing about it helps a Go or Rails codebase.

How the generator works: cookiecutter, a post-gen hook and a Docker stack

The mechanism is conventional for this class of tool. pyproject.toml lists cookiecutter as a runtime dependency of the generator, alongside click, questionary, rich, pyyaml and ruff. The CLI collects answers through a questionary wizard, renders the cookiecutter template, and then runs a post-generation hook that shells out to ruff to format the rendered project. The comment in pyproject.toml is explicit that ruff is declared as a generator dependency for exactly that reason.

That dependency split is worth noting. The file states that anything the generated project needs belongs in template/{{cookiecutter.project_slug}}/backend/pyproject.toml, not in the generator's own dependency list, because declaring it in the generator "makes every `uvx fastapi-fullstack` install it too." If you are auditing what the CLI pulls onto your machine, the generator's dependency list is short by design.

At runtime the generated project is a two-process stack. The README's quick start brings up the backend and PostgreSQL through docker-compose.dev.yml, waits on pg_isready, applies Alembic migrations and seeds a default admin account. The frontend is a separate Next.js 15 app started with bun. Chat traffic moves over WebSocket, which is what the streaming chat UI consumes.

Installing fastapi-fullstack and generating a first project

The README gives three install paths. uv is marked as recommended, and pipx is offered for an isolated install. All three put the same fastapi-fullstack command on your PATH.

# pip
pip install fastapi-fullstack

# uv (recommended)
uv tool install fastapi-fullstack

# pipx
pipx install fastapi-fullstack

With the command installed, run it with no arguments. The README's step one is literally `fastapi-fullstack`, followed by answering the wizard's prompts; the wizard is where you pick the agent framework, the vector store and the integrations. The README also points at a browser-based configurator for people who would rather download a ZIP than install the CLI.

# 1. Generate your project — just answer the wizard's prompts
fastapi-fullstack

After the wizard finishes you have a project directory. The README's example names it my_ai_app. From inside it, a single make target brings up the backend, PostgreSQL, migrations and a seeded admin account.

# 2. Backend + PostgreSQL up, migrations applied, default admin seeded
cd my_ai_app
make bootstrap

The README defines make bootstrap as make dev plus make seed: it builds the backend Docker image, starts the stack via docker-compose.dev.yml, waits for PostgreSQL with pg_isready, applies Alembic migrations and seeds admin@ex... (the README truncates the seeded address). The frontend runs in a second terminal.

# 3. Frontend (in a second terminal)
cd frontend && bun install && bun dev

If make bootstrap returns without a healthy database, the likely cause is a port conflict on the PostgreSQL container rather than a migration error, since the target waits on pg_isready before running Alembic.

Agent frameworks, RAG stores and the choices you cannot undo

The README advertises five agent frameworks: PydanticAI, PydanticDeep, LangChain, LangGraph and DeepAgents. The topics list on the repository also carries crewai and langchain, so the option set has moved around. For RAG it names four vector stores: Milvus, Qdrant, pgvector and ChromaDB.

This is the part of the wizard worth slowing down for. The framework and vector store selections are baked into the rendered project, so changing your mind afterwards means editing generated code rather than flipping a config value. A team that picks LangGraph to prototype and later wants Pydantic AI's typed outputs is rewriting the agent layer, not reconfiguring it.

There is also a coupling between the framework choice and the rest of the Vstorm ecosystem. The README states that the deepagents framework option is powered by the separate pydantic-deepagents project, which is installed standalone rather than bundled. That means the deepagents path adds a second dependency with its own release cycle to track. The other four options do not carry that note.

pgvector deserves separate mention because it collapses a service. If you already run PostgreSQL for the application database, pgvector keeps embeddings in the same instance and removes a container from your compose file. Milvus and Qdrant are the opposite trade: more operational surface, but purpose-built indexes.

Where the template stops helping

The generated project is a starting point, and the README does not claim otherwise. Everything after scaffolding is yours. The generator has no update command that re-renders an existing project against a newer template, and the README does not document rollback for a bad generation. If a wizard answer turns out to be wrong, the recovery path is deleting the directory and starting over, or hand-editing the result.

The presence of UPGRADES.yaml at the repository root suggests the project tracks upgrade concerns, but the README does not explain how a generated project consumes it. Treat that file as something to read in the repository rather than a mechanism you can rely on from the README alone.

Maturity is the other honest caveat. pyproject.toml carries the classifier "Development Status :: 3 - Alpha" even though the description calls the output production-ready. Those two statements sit in the same file. The release history is consistent with alpha: 0.2.17, 0.2.18 and 0.2.19 all landed within about a week in late July and early August 2026. A fast 0.2.x cadence on the generator means the template can change underneath you between generations.

Finally, the tool is opinionated about the stack. FastAPI, Next.js 15, PostgreSQL and Docker are assumed. If your team runs Django or a non-Node frontend, the generator's value drops to near zero because you would be deleting most of what it produced.

Compared with starting from a bare FastAPI template or a coding agent scaffold

The closest alternative is a general-purpose FastAPI project template, the kind that gives you an app skeleton, settings management and a test layout. The difference is scope. A generic FastAPI template has no opinion about agents, no WebSocket chat transport, no vector store wiring and no Next.js frontend. You would add each of those yourself, which is exactly the work fastapi-fullstack front-loads into a wizard.

The trade runs the other way too. A minimal FastAPI template leaves you with a codebase small enough to read in one sitting. The generated project here includes Celery, an admin panel, OAuth and Kubernetes manifests, and the README does not document a way to generate a reduced variant: the wizard's prompts are the only pruning mechanism described.

A second comparison point is the coding-agent scaffolding pattern, where a tool generates a repository already wired for an agent workflow. Those tend to target the agent's own tooling rather than a user-facing web application with authentication and a chat UI. fastapi-fullstack sits closer to application scaffolding: the deliverable is a deployable product surface, with the agent as one component inside it.

Editorial conclusion

Adopt it if you want a FastAPI plus Next.js agent app scaffolded in an afternoon and you are willing to own the generated code afterwards. Skip it if you need a stable API surface: pyproject.toml marks the project as Development Status 3 - Alpha, and the generator's own release cadence (three 0.2.x releases in July and August 2026) tells you the template output can shift between versions. Before committing, run the wizard once, read UPGRADES.yaml in the generated tree, and confirm your chosen agent framework and vector store are both in the option list, because you cannot swap them later without editing the generated project by hand.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. vstorm-co/full-stack-ai-agent-template on GitHub