A product skeleton, not a FastAPI tutorial
Full Stack FastAPI Template answers a question that appears after a team chooses FastAPI: what surrounds the API? Its answer is specific. SQLModel talks to PostgreSQL, Pydantic handles validation and settings, and Alembic manages migrations. A React and TypeScript frontend uses Vite, TanStack Query, TanStack Router, Tailwind CSS, and shadcn/ui. The repository adds login, secure password hashing, JWT authentication, email recovery, an admin area, sample item management, API documentation, and dark mode.
That scope is the reason to choose it. A new product can begin with users, database migrations, browser screens, generated API calls, local email capture, backend tests, end-to-end tests, and CI already connected.
It is also the reason to walk away. Templates save work only when their decisions match yours. Replacing PostgreSQL, React, the authentication model, or the same-domain deployment will cut across settings, tests, workflows, and documentation. A developer who needs three API routes and no browser application will spend more time deleting machinery than writing a small FastAPI project directly.
Local development has several moving parts
The documentation offers two useful workflows. For quick editing, Docker Compose starts PostgreSQL and Mailcatcher, then the backend runs locally through uv and the frontend through Bun. The sequence is explicit: sync Python dependencies, run the prestart script to prepare the database, start FastAPI, install frontend packages, and start Vite in another terminal. Swagger UI appears on port 8000, the frontend on 5173, and captured mail on 1080.
The assembled path uses Compose watch after a one-time backend prestart command. It exposes the combined application, API docs, Adminer, Traefik's dashboard, and Mailcatcher. The guide warns that the first start may take a minute and that a locally running FastAPI server will conflict with the Compose backend on port 8000. These are small details, but documenting them makes the setup much less mysterious.
This still is not a one-command starter. Contributors need Docker, uv, and Bun, plus enough familiarity to understand which process owns each port. The tracked .env contains development defaults, while deployment secrets must live elsewhere. Email templates add another loop: edit React Email components, preview them with a Bun command, export HTML, and avoid editing generated templates by hand.
An open pull request describes a current wrinkle in local Playwright runs. Changes under the saved authentication directory can trigger backend reloads during Compose watch and lead to random test failures. Another open fix addresses a mobile logout sequence that can leave the login page unclickable. Neither makes the template unusable, but both are reminders to test the inherited application before treating starter code as finished product code.
The backend and frontend fit together well
The strongest technical choice is the generated frontend client. Backend routes and schemas can feed a typed client rather than leaving developers to duplicate request shapes by hand. The backend README also gives a clear map: models, API routes, CRUD helpers, migrations, tests, and editor configuration each have an obvious home. Pytest coverage is integrated, and GitHub Actions runs the tests automatically.
On the frontend, TanStack Query is a sensible match for a separate API and TanStack Router keeps routes typed. Playwright covers user flows, while shadcn/ui provides components that teams can own and modify. The sample login, admin, user, and item screens are enough to show how data and permissions move through the stack. They are scaffolding, not a design system or a finished account platform. Multi-factor authentication, social login, billing, organizations, and detailed authorization are product decisions left to the adopter.
SQLModel offers an approachable bridge between Pydantic models and SQLAlchemy, and Alembic is already configured around the included models. The documentation correctly tells developers to generate and commit a migration whenever a model changes. Removing the sample data model is possible, but it should happen early, before real migrations and client code accumulate around it.
Deployment is credible, not automatic
Version 0.12.0 added FastAPI Cloud deployment and fixed frontend assets in the Docker build context. The hosted workflow builds the frontend, prepares the database, creates the first superuser, and deploys on pushes to the master branch. It requires a FastAPI Cloud application, a PostgreSQL integration or connection URL, application variables, secrets, and GitHub deployment credentials. The database must be reachable from GitHub-hosted runners because migrations run there.
The self-hosted option is more portable but asks more of the operator. A remote server needs Docker Engine, DNS records, application variables, secure generated credentials, and Traefik for HTTPS. The included manual GitHub Actions deployment uses a self-hosted runner with Docker access, which means repository contributors and workflow changes must be trusted. That warning is present in the guide and deserves attention.
These deployment paths are valuable because they are complete enough to learn from and modify. They do not replace backups, database monitoring, secret rotation, mail deliverability, observability, or a rollback plan. Sentry is configurable, but operations remain the adopting team's responsibility.
Healthy, current, and intentionally opinionated
The repository was pushed on August 12, 2026, the same day version 0.12.0 shipped. Two other releases landed the previous day, and the 11 open items include actively discussed pull requests rather than a quiet pile of old bug reports. The project also benefits from FastAPI's visibility and a very large GitHub audience.
Documentation is unusually good for a template. Separate guides cover backend work, frontend work, local composition, FastAPI Cloud, self-hosted Compose, migrations, tests, email generation, environment variables, and automation. The tradeoff is maintenance inheritance: once copied, the application is yours, and upstream changes do not magically merge into a customized product.
This is the best default for a team that can say yes to nearly every item in its stack. It offers disciplined plumbing and enough sample code to expose the intended patterns. Teams still debating their database, frontend runtime, or deployment shape should make those choices first. A template this complete accelerates alignment, but magnifies disagreement.