The generated app seeds admin123, and the package calls itself alpha

Bootstrap seeds a password that is printed in the readme

The three-step quickstart ends with an admin account whose credentials are on the page:

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

The explanation of what that target does lists the last step as seeding `[email protected]` / `admin123`, and the access table repeats the same pair against the admin URL. So the credential is not a hidden default you discover after installation, it is stated twice in the documentation.

What makes it stick is the idempotence. `make seed` is a one-shot admin creation that is a no-op if the admin exists, and `make dev` is documented as bootstrapping or restarting with no admin re-seed. Re-running either will not repair a password you left alone, and nothing in the day-to-day list prompts you to change it. The feature list also advertises an admin panel, so the seeded account is a real login rather than a placeholder nobody can reach.

The honest summary is that this is the right default for a template you run locally and the wrong default for one you deploy. Changing it is your job, and the readme does not say so.

The readme says production-ready, the classifier says alpha

The subtitle calls this a production-ready FastAPI plus Next.js project generator, and the packaging description ends with Ship AI apps fast. Two hundred lines down, in the same file, the packaging metadata carries the classifier `Development Status :: 3 - Alpha`.

Those are different claims about different things, and both are load-bearing. The readme line is about the shape of what you get, which is fair, since the generated project does carry auth, background jobs and container definitions. The classifier is the standard field that package indexes and tooling read, and Alpha on PyPI is a statement that you should not put this in front of end users yet.

The version tells the same story as the classifier. The last three releases are 0.2.19 and 0.2.18 on the same day, 2026-08-01, and 0.2.17 on 2026-07-25, and the packaging version is 0.2.19. A zero-series version with a daily bump cadence is a project shipping quickly to early users, which is what Alpha means. The readme's word and the version's meaning are not reconciled anywhere.

The rest of the metadata is consistent with the packaging rather than the pitch. `requires-python` is `>=3.11` and the classifiers name only 3.11 and 3.12, so a 3.13 interpreter is outside the declared range even though the floor is open-ended.

The generator's dependencies are kept minimal on purpose

The dependency list in `pyproject.toml` carries a comment that is the most useful engineering note in the project. It says the runtime dependencies are those of the generator only, that anything the generated project needs belongs in the template's own backend pyproject at `template/{{cookiecutter.project_slug}}/backend/pyproject.toml`, and that declaring it in the generator makes every `uvx fastapi-fullstack` install it too.

That path is also how the templating is disclosed. The generator is a cookiecutter project, and the rendered output is materialised under a `{{cookiecutter.project_slug}}` directory inside `template/`, so the same file holds the generator's package `fastapi_gen/` and the thing it emits.

The visible generator dependencies are `click` for the command line, `cookiecutter` for the templating, `pyyaml` and `packaging` for config and versions, `rich` and `questionary` for the terminal wizard, `pydantic` for validation, and `ruff`, which has its own comment explaining that it is shelled out to by the post-generation hook to format the rendered project. So the formatter is a runtime dependency rather than a dev one, because the tool formats your code at the moment it writes it, and the list ends with a comment beginning Required at, which is where the visible text stops.

One of the five agent frameworks is not in the package

The feature block names five agent frameworks: PydanticAI, PydanticDeep, LangChain, LangGraph and DeepAgents. The RAG pipeline offers four vector stores, Milvus, Qdrant, pgvector and ChromaDB. Alongside that sit Next.js 15 with WebSocket streaming and a real-time chat UI, conversation sharing through direct sharing, public links and an admin browser, and an enterprise row of JWT, OAuth, an admin panel, Celery, Docker and Kubernetes.

The DeepAgents option is the exception. The ecosystem section states that the runtime behind the template's agents lives in a different repository, and that it powers the `deepagents` framework option and can be installed on its own with a command that pipes a remote install script into a shell. So a fifth framework in the list of five requires a second install from a second project, and the way that install is invoked is a piped script rather than a package manager entry.

The same ecosystem table is worth reading for what it says about the author's centre of gravity. Of the five sibling projects, four are extensions for Pydantic AI, covering guardrails, subagent orchestration, context compression and sandboxed execution, and the fifth is the agent runtime itself. So the organisation's depth is concentrated on one framework while the template offers five, and the option most aligned with the surrounding work is the one that is not bundled.

Three ways in, and a frontend that needs a second terminal and bun

The installation block covers the Python side only:

# pip
pip install fastapi-fullstack

# uv (recommended)
uv tool install fastapi-fullstack

# pipx
pipx install fastapi-fullstack

Beyond the wizard there is a flags form, a preset form, a `--minimal` form that produces a bare-bones PostgreSQL project with no Docker, Redis or CI, and a browser configurator that produces a ZIP with no CLI install at all. The flags name a `--database` and a `--frontend` option directly, and the three presets are an AI agent with streaming, a full production setup, and a SaaS setup with billing, teams and admin.

The frontend is where the three steps stop being three. It runs with `cd frontend && bun install && bun dev` in a second terminal, or through `make dev-frontend` in Docker, and the access table lists both. `bun` appears nowhere in the installation section, so the Node toolchain is an unstated prerequisite for a quickstart that claims three steps.

One more detail carries over. `make dev-rebuild` is annotated as force-rebuilding the backend image after pyproject.toml changes, which tells you the image is not invalidated by a dependency edit on its own. Change a backend dependency, re-run `make dev`, and the old code serves the request until you remember the fourth command.

Upgrades are a three-way merge, and UPGRADES.yaml is what would drive it

The most interesting problem in a template generator is not generation, it is what happens eighteen months later when the template has moved and your copy has not. This project has an answer, and the answer is a real merge rather than a re-scaffold: your project is not stranded on the template version you generated from, and the latest improvements are pulled in with a three-way merge that preserves your customizations.

That claim needs a base, and the base is `UPGRADES.yaml` at the repository root. A three-way merge needs to know what the template looked like when you branched, what it looks like now, and what you changed since. A single data file at the root is the plausible place to record the first of those, and the sentence explaining the mechanism is cut off partway through, so how the three inputs are assembled is not on the page.

The rest of the root is a governance surface worth noting: `GOVERNANCE.md`, `DCO`, `SECURITY.md`, `CLAUDE.md`, `AGENTS.md`, `CHANGELOG.md`, `CONTRIBUTING.md`, a `renovate.json` for dependency updates, a `uv.lock`, and an `.actrc` for running GitHub Actions locally. A DCO sign-off requirement plus a governance file plus renovate is a project that expects outside contributions and automated dependency bumps, which is a reasonable posture for something whose output other people maintain as their own codebase.

Editorial conclusion

Use this template when you want a FastAPI and Next.js application with auth, a RAG pipeline and background jobs already wired, and you are prepared to own what it generates, because the output is a fork of the template rather than a dependency on it. Four things to settle on day one. `make bootstrap` seeds `[email protected]` with the password `admin123`, and since the target is idempotent and the account already exists on later runs, nothing will ever prompt you to change it, so deal with that before the port is reachable by anything but localhost. The production-ready line in the readme and the `Development Status :: 3 - Alpha` classifier in the packaging metadata are not the same claim, and the second is the one the release tooling can act on. If you pick the DeepAgents framework option, know that it is not in this package at all and needs a separate install from a sibling repository. And if you edit backend dependencies, run `make dev-rebuild`, because the bootstrap image is not rebuilt when pyproject changes and your edit will look like it did nothing. The 3-way merge upgrade path is the strongest idea in the project, and it rests on `UPGRADES.yaml`, so read that file before you generate rather than after.

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