When I started working with FastAPI, I quickly realized one thing:
Project structure matters.
A messy project becomes hard to scale, hard to maintain, and hard to debug β especially when youβre working on real-world APIs or collaborating with a team.
Over time, I settled on a project structure that keeps things organized, clear, and ready to grow. In this post, Iβll walk you through the structure I use and why it works for me.
βΈ»
π FastAPI Project Structure Example
Hereβs what my folder structure looks like for a typical FastAPI project:
app/
βββ admin/ β Admin operations (separate logic for admins)
βββ models/ β SQLAlchemy database models
βββ schemas/ β Pydantic request & response schemas
βββ crud/ β Database operations (clean, reusable functions)
βββ routes/ β API endpoints, cleanly separated by feature
βββ core/ β Auth logic, password hashing, reusable dependencies
βββ database.py β Database connection & session setup
βββ config.py β App settings & environment variables
alembic/ β Database migrations (optional, recommended)
env/ β Virtual environment folder (optional)
.env β Secrets like DB URI, JWT keys
requirements.txt β Project dependencies
π‘ Why I Like This Structure
βοΈ Separation of Concerns β Each folder has a clear responsibility
βοΈ Easy to Scale β As features grow, everything stays organized
βοΈ Cleaner Routes β No messy logic inside route files
βοΈ Team Friendly β Easy for new devs to onboard and understand
βοΈ Good with Extensions β Works well with JWT auth, Alembic, etc.
π¦ Quick Notes on Key Folders
β’ models/ β Pure database models using SQLAlchemy
β’ schemas/ β Pydantic schemas for validation and serialization
β’ crud/ β Handles database queries so routes stay clean
β’ routes/ β Your API endpoints organized by feature (e.g., auth.py, coffee.py)
β’ core/ β Authentication logic, password hashing, reusable dependencies like get_current_user
β’ admin/ β Optional, useful for admin-specific operations
β Conclusion
A clean project structure wonβt solve all your problems β but it definitely saves you time and headaches down the road.
This structure works for me on both small and growing FastAPI projects, and Iβm always open to improving it.
How do you structure your FastAPI apps?
Iβd love to hear your suggestions, ideas, or different approaches in the comments! π
Top comments (0)