Hey, guys, for anyone who might benefit (or would like to contribute - good starting point for newbies)

For about 2 years I've been developing this boilerplate (with a lot of help from the community - 20 contributors) and it's pretty mature now (used in prod by many). Latest news was the addition of CRUDAdmin as an admin panel, plus a brand new documentation to help people use it and understand design decisions.

• Github: https://github.com/benavlabs/FastAPI-boilerplate

• Docs: https://benavlabs.github.io/FastAPI-boilerplate/

Main features:

• Pydantic V2 and SQLAlchemy 2.0 (fully async)

• User authentication with JWT (and cookie based refresh token)

• ARQ integration for task queue (way simpler than celery, but really powerful)

• Builtin cache and rate-limiting with redis

• Several deployment specific features (docs behind authentication and hidden based on the environment)

• NGINX for Reverse Proxy and Load Balancing

• Easy and powerful db interaction (FastCRUD)

Would love to hear your opinions and what could be improved. We used to have tens of issues, now it's down to just a few (phew), but I'd love to see new ones coming.

Note: this boilerplate works really well for microservices or small applications, but for bigger ones I'd use a DDD monolith. It's a great starting point though.

Hello all. So, I'm a 20+ year vet, and recently, I decided to strike out on my own and make my own future. In that time, I've built some form of the same FastAPI app half a dozen times for various clients. You know how it goes, auth, scheduler, workers, config, Docker, etc.

I got tired of copying/pasting components from projects, so, I built a CLI that will allow you to choose your components and services, and add/delete them later as you see fit.

One command to start (requires uv & Docker):

Don't waste time cloning this repo, or manually installing the CLI. Just run this command, and you'll be up and running:

uvx aegis-stack init my-app

What makes it different:

• Choose your components and services at initialization time

• Add components after init (uvx aegis-stack add worker)

• Remove what you don't need (uvx aegis-stack remove auth)

• Pull template updates into existing projects (uvx aegis-stack update). If I make bug fixes to any core components, you get them by simply running an update.

What's included:

• FastAPI (Backend, API's)

• Flet (Frontend, Overseer real time dashboard)

• Database (SQLite3) + SQLModel/SQLAlchemy

• JWT auth via the Authentication service

• arq workers (async-native)

• APScheduler for cron jobs

• Communication service for support for email, text, and voice calls

• Docker + docker-compose

• Alembic migrations

Built on Copier for templating — that's how the update mechanism works (3-way merge into existing projects).

Would love feedback — especially on the update mechanism and component architecture.

https://github.com/lbedner/aegis-stack

Hey ! 👋 I've created a modern template that combines best practices with a fun superhero theme 🎭 It's designed to help you kickstart your API projects with a solid foundation! 🚀

Features:

- 🏗️ Clean architecture with repository pattern that scales beautifully

- 🔄 Built-in async SQLAlchemy + PostgreSQL integration

- ⚡️ Automatic Alembic migrations that just work

- 🧪 Complete CI pipeline and testing setup

- ❌Custom Error Handling and Logging

- 🚂 Pre-configured Railway deployment (one click and you're live!)

The template includes a full heroes API showcase with proper CRUD operations, authentication, and error handling. Perfect for learning or starting your next project! 💪

Developer experience goodies: 🛠️

- 💻 VS Code debugging configurations included

- 🚀 UV package manager for lightning-fast dependency management

- ✨ Pre-commit hooks for consistent code quality

- 📚 Comprehensive documentation for every feature

Check it out: https://github.com/luchog01/minimalistic-fastapi-template 🌟

I'm still not super confident about how I structured the logging setup and DB migrations 😅 Would love to hear your thoughts on those! Also open to any suggestions for improvements. I feel like there's always a better way to handle these things that I haven't thought of yet! Let me know what you think!

*was created by ai

(cross-post from r/python here https://www.reddit.com/r/Python/comments/pawqhw/sqlmodel_sql_dbs_based_on_python_type_hints_the/)

I just released SQLModel ✨

https://github.com/tiangolo/sqlmodel

This is the biggest thing I've built since FastAPI and Typer... 😅

SQLModel is a library for interacting with SQL DBs, based on Python type hints.

Each model is both a Pydantic and SQLAlchemy model, and it's all optimized for FastAPI. 🚀

More info in this Twitter thread: https://twitter.com/tiangolo/status/1430252646968004612

And the docs are here: https://sqlmodel.tiangolo.com/

I've been running production FastAPI apps on ultra-cheap VPS ($2-5/month) with the same reliability as expensive platforms.

Here's my complete stack:

Backend: • FastAPI + Uvicorn workers • Systemd for process management (auto-restart on crashes) • Gunicorn as process manager

Infrastructure: • Nginx reverse proxy (handles SSL termination) • Let's Encrypt for free HTTPS certificates (auto-renewal) • UFW firewall + fail2ban • Ubuntu 22.04 LTS

Deployment process:

1. Git push to VPS

2. Systemd restarts service automatically

3. Nginx serves with zero downtime

4. SSL cert renews via cron

Performance: My production app (shiolplus.com) runs on a $2/month Contabo VPS:

• Handles Stripe webhooks

• Serves ML predictions

• 99.9% uptime over 6 months

• <100ms response times

Cost comparison:

• Heroku Eco: $5/month (sleeps after 30min)

• Heroku Basic: $7/month (no sleep)

• Render: $7/month

• Railway: $5/month

• My setup: $2/month (IONOS VPS) - always on

I documented my full deployment checklist if anyone's interested. Happy to share the Nginx config or systemd service file if helpful.

Questions I can answer:

• SSL certificate automation

• Zero-downtime deployments

• Database setup on same VPS

• Horizontal scaling strategies

Hey everyone 👋

I just published a detailed, beginner-focused guide for getting started with FastAPI.

It covers:

• Installing FastAPI & Uvicorn

• Writing your first async endpoint

• Pydantic-based request validation

• Path vs query parameters

• Auto-generated Swagger docs

• Project folder structure (based on official best practices)

• Comparison with Django (performance & architecture)

• Tips & common mistakes for newcomers

I also included a GitHub repo with a clean modular project layout to help others get started quickly.

Medium Link Here: https://medium.com/@inandelibas/getting-started-with-fastapi-a-step-by-step-beginners-guide-c2c5b35014e9

Would love any feedback, corrections, or suggestions on what to cover next, especially around DB integration, auth, or testing!

Thanks to Sebastián Ramírez and the FastAPI team for such a great framework 🙌

I'm very happy to share this with you all, FastAPI Cloud is now generally available: https://fastapicloud.com/blog/fastapi-cloud-generally-available/

New to FastAPI, I read about concurrency and async/await from fastapi. The way it expressed is so cool.

I've tried to document my thought process for picking a dependency injection library, and I ended up with a bit of a rant. Followed by my actual thought process and implementation. Please let me know what you think of it (downvotes are fine :)) ), I'm curious if my approach/thought process makes sense to more experienced Python devs.

To tell you the truth, I'm a big fan of dependency injection. One you get to a certain app size (and/or component lifetime requirements), having your dependency instances handled for you is a godsend.

I just don't like how it works in FastAPI

You see, in FastAPI if you want to inject a component in, say, an endpoint you would do something like def my_endpoint(a=Depends(my_a_factory)), and have your my_a_factory create an instance of a or whatever. Simple, right? And, if a depends on, say, b, you then create a my_b_factory, responsible for creating b, then change the signature of my_a_factory to something like def my_a_factory(b=Depends(my_b_factory)). Easy.

But wait! What if b requires some dependencies itself? Well, I hope you're using your comfortable keyboard, because you're gonna have to write and wire up a lot of factories. One for each component. Each one Depends-ing on others. With you managing all their little lifetimes by hand. It's factories all the way down, friend. All the way down.

And sure, I mean, this approach is fine. You can use it to check user permissions, inject your db session, and stuff. It's easy to get your head around it.

But for building something more complex? Where class A needs an instance of class B, and B in turn needs C & D instances, and (guess what) D depends on E & F? Nah, man, ain't nobody got time for that.

And I haven't even mentioned the plethora of instance lifetimes -- say, B, D, & E are singletons, C is per-FastAPI-request, and F is transient, i.e. it's instantiated every time. Implement this with Depends and you'll be working on your very own, extremely private, utterly personal, HELL.

So anyway, this is how I ended up looking at DI libraries for Python

There's not that many Python dependency injection libraries, mind you. Looks like a lot of Python devs are happily building singletons left and right and don't need to inject no dependencies, while most of the others think DI is all about simplifying unit tests and just don't see the point of inverting control.

To me though, dependency inversion/injection is all about component lifetime management. I don't want to care how to instantiate nor how to dispose a dependency. I just want to declare it and then jump straight to using it. And the harder it is for me to use it, i.e. by instantiating it and its "rich" dependency tree, disposing each one when appropriate, etc, the more likely that I won't even bother at all. Simple things should be simple.

So as I said, there's not a lot of DI frameworks in Python. Just take a look at this Awesome Dependency Injection in Python, it's depressing, really (the content, not the list, the list is cool). Only 3 libraries have more than 1k stars on Github. Some of the smaller ones are cute, others not so much.

Out of the three, the most popular seemed to be python-dependency-injector, but I didn't like the big development gap between Dec 2022 and Aug 2024. Development seems to have picked up recently, but I've decided to give it a little more time to settle. It has a bunch of providers, but it wasn't clear to me how I would get a per-request lifetime. Their FastAPI example looks a bit weird to me, I'm not a fan of those Depends(Provide[Container.config.default.query]) calls (why should ALL my code know where I'm configuring my dependencies?!?).

The second most popular one is returns, which looks interesting and a bit weird, but ultimely it doesn't seem to be what I'm after.

The third one is injector. Not terribly updated, but not abandoned either. I like that I can define the lifetimes of my components in a single place. I..kinda dislike that I need to decorate all my injectable classes with @inject but beggars can't be choosers, am I right? The documentation is not nearly as good as python-dependency-injector's. I can couple it with fastapi-injector to get request-scoped dependencies.

In the end, after looking at a gazillion other options, I went with the injector + fastapi-injector combo -- it covered most of my pain points (single point for defining my dependencies and their lifetimes, easy to integrate with FastAPI, reasonably up to date), and the drawbacks (that pesky @inject) were minimal.

Here's how I set it up to handle my convoluted example above

Where class A needs an instance of class B, and B in turn needs C & D instances, and (guess what) D depends on E & F

First, the classes. The only thing they need to know is that they'll be @injected somewhere, and, if they require some dependencies, to declare and annotated them.

# classes.py
from injector import inject

@inject
class F
    def __init__(self)
        pass

@inject
class E
    def __init__(self)
        pass

@inject
class D
    def __init__(self, e: E, f: F):
        self.e = e
        self.f = f

@inject
class C:
    def __init__(self)
        pass

@inject
class B:
    def __init__(self, c: C, d: D):
        self.c = c
        self.d = d

@inject
class A:
    def __init__(self, b: B):
        self.b = b

say, B, D, & E are singletons, C is per-FastAPI-request, and F is transient, i.e. it's instantiated every time.

The lifetimes are defined in one place and one place only, while the rest of the code doesn't know anything about this.

# dependencies.py

from classes import A, B, C, D, E, F
from fastapi_injector import request_scope
from injector import Module, singleton, noscope

class Dependencies(Module):
    def configure(self, binder):
        binder.bind(A, scope=noscope)
        binder.bind(B, scope=singleton)
        binder.bind(C, scope=request_scope)
        binder.bind(D, scope=singleton)
        binder.bind(E, scope=singleton)
        binder.bind(F, scope=noscope)

        # this one's just for fun 🙃
        binder.bind(logging.Logger, to=lambda: logging.getLogger())

Then, attach the injector middleware to your app, and start injecting dependencies in your routes with Injected.

# main.py

from fastapi_injector import InjectorMiddleware, attach_injector
from injector import Injector

app = FastAPI()

injector = Injector(Dependencies())
app.add_middleware(InjectorMiddleware, injector=injector)
attach_injector(app, injector)

@app.get("/")
def root(a: A = Injected(A)):
    pass

Not too shabby. It's not a perfect solution, but it's quite close to what I had gotten used to in .NET land. I'm sticking with it for now.

(and yes, I've posted this online too, over here)

I've been building a discovery engine for solo-built software — think of it as intent-based search where users type a problem ("I need to send invoices") and get matched to tools, instead of browsing by product name or upvotes.

The stack is FastAPI + SQLite. No Postgres. No Redis. No managed database service. Just a single .db file.

I wanted to share what I've learned after a few weeks in case it helps anyone evaluating the same choice.

Why SQLite

• Zero operational overhead. No connection pooling, no database server to monitor, no Docker Compose dependency. The app and the data live together.

• Reads are absurdly fast. My use case is read-heavy (search queries) with infrequent writes (new tool submissions, maybe 10-20/day). SQLite handles this without breaking a sweat.

• Backups are cp. I rsync the .db file nightly. That's the entire backup strategy. It works.

• Deployment is simple. One process, one file, one VPS. I deploy with a git pull and a systemd restart. The calm tech dream.

The tradeoffs I've hit

• Write concurrency. SQLite uses a file-level lock for writes. With WAL mode enabled, concurrent reads are fine, but if you have multiple processes writing simultaneously, you'll hit SQLITE_BUSY. My solution: a single FastAPI worker handles all writes via a background task queue. If you're running Gunicorn with multiple workers, this is something you have to think about.

• Full-text search. SQLite's built-in FTS5 is surprisingly capable. I'm using it for intent-based search with custom tokenizers. It's not Elasticsearch, but for a catalog of a few thousand items, it's more than enough. The main limitation: no fuzzy matching out of the box. I handle typo tolerance at the application layer.

• No native JSON operators (sort of). SQLite has json_extract() and friends, but they're not as ergonomic as Postgres's -> and ->> operators. I store structured metadata as JSON blobs and parse in Python when needed. Minor annoyance, not a blocker.

• Schema migrations. There's no ALTER COLUMN in SQLite. If you need to change a column type, you're rebuilding the table. I use alembic with the batch mode for this, which wraps the create-copy-drop-rename dance. Works fine, just feels clunky.

Where the line is

I think SQLite stops being the right choice when:

• You need concurrent writes from multiple services (microservices, multiple API servers)

• Your dataset exceeds ~50GB and you need complex analytical queries

• You need real-time replication to a read replica

For a solo-built SaaS serving hundreds or even low thousands of users with a read-heavy workload? SQLite is underrated. The operational simplicity alone is worth it.

Happy to answer questions about the setup. I'm using Python 3.12, FastAPI with async endpoints, and SQLAlchemy 2.0 with the synchronous SQLite driver (async SQLite drivers exist but add complexity I don't need).

Hey folks! FastAPI Cloud is now in public beta. 🚀

This is made by the same team building FastAPI (I created FastAPI, we now have an amazing team building all this).

Here's the announcement post: https://fastapicloud.com/blog/fastapi-cloud-public-beta/

A year ago I launched fastapiinteractive.com - an interactive FastAPI course where you write and run real Python in the browser. No installs, no backend, it's Pyodide plus a small ASGI server running FastAPI in WebAssembly. I've posted about it here a couple of times, last one ~6 months ago.

I'll be honest, I didn't expect it to get this much use. I got busy and didn't touch it for a few months, and when I came back people were still going through the lessons every day and sending me bug reports. That got me back into it. A lot has changed since, so here's the update.

What's new:

• WebSockets truly work now. There's no network socket in WASM, so the connection goes over the worker's message channel, but past the ASGI layer it's the real Starlette WebSocket running your handler. Embarrassing detail: previously, the two websocket lessons used to be graded by a GET /health check, so the code they taught had never once run as a websocket. Now they're graded on a real exchange of messages, including a broadcast between two connections, and there's a socket console to try your endpoints manually.

• Streaming responses, file uploads and form bodies work.

• Infinite loops don't kill the tab anymore. Your code gets compiled through a guard with a time budget per request, so while True: raises inside your own code with your line number instead of hanging everything.

• New UI, VS Code style: lesson list with progress in the sidebar, editor in the middle, console/tests/theory as output tabs, status bar showing what the runtime is doing.

• Accounts. Sign in with GitHub and your progress and code sync between devices. Without an account it works exactly like before, everything stays in your browser.

• Certificates. When you finish a track you can get a certificate of completion - PDF, an image for LinkedIn, and a verification page with a serial anyone can check. Optional, the lessons themselves are free.

• 61 lessons now: 45 basics following the FastAPI tutorial, the 6-lesson blog+auth project as a proper multi-file package, 10 advanced patterns.

Try it: https://www.fastapiinteractive.com/

Bug reports, feedback and ideas for lessons are very welcome, here or via the contact form on the site.

Thank you!

I'm absolutely not affiliated with them, but wanted to share a real enthusiasm about this project, because I think they deserve to reach their audience.

I always thought it was a pain in the ass when deploying a project to production to use multiple tools with dedicated roles for monitoring. I've always wanted an all-in-one observability platform which is easy to use.

Here is what I'm thinking of:

• Made with python in mind (native integrations with FastAPI, SQLALchemy, Celery, and many others).

• With these examples in mind, I can replace at least 5 tools with a single one:

  • Sentry (error management)

  • New Relic (perf)

  • logDNA (logs)

  • Celery flower (background task results)

  • Even local packages like debug toolbars can be replaced (I used to use them to see details of my database queries) and then have the same tools in local and remote environment.

• I'm not used to see such top-notch design quality in Python world (no offense..)

• UI is deadly easy, 4 tabs: live view, dashboard with KPIs, logs exploration, and alert settings. No options everywhere, submenus, hiden checkboxes, etc. I don't feel I need to be a devops engineer to monitore my app.

• It works already well while being very young (some feature are missing, but not that much)

• More than decent free plan (let's hope it won't change over time)

• They are fast to answer on issues on Github

• I tend to trust a team that built (the amazing) Pydantic and know open source, more than other ones.

I wish this team and this project the best!

Hi r/FastAPI,

I was looking for a fun weekend hacking project and decided to build a chess game with FastAPI.
The project was a lot of fun to build, especially the game communication logic.

Sharing here for anyone interested:

Live demo:
NOTE: You need another player online. If the wait is too long and you just want to play alone like a psycho explore the game, you could open two browser windows, or use two machines / devices.

https://chess.olzhasar.com/

Source code:

https://github.com/olzhasar/pyws-chess

Cheers

Been frustrated with debugging FastAPI apps in development, so I built this.

You add Radar(app, db_engine=engine) and get a full monitoring dashboard at `/__radar/`.

Shows all requests, SQL queries with timing, and exceptions with stack traces. Everything updates in real time.

It's on PyPI: pip install fastapi-radar

GitHub: https://github.com/doganarif/fastapi-radar

Thank you so much! Just crossed 65 ⭐ !!!

What do you guys think?

I believe it’s a very exciting addition to the FastAPI community backed by one of the biggest venture capitals and created by Tiangolo!

Amazing news!

I recently decided to open-source my FastAPI backend for a social map app I've been working on for the past few years called Jimo. I'm not actively developing it anymore, but I thought some of you might find it interesting or useful as a reference for larger FastAPI projects.

Here's the repo link: https://github.com/Blue9/jimo-server.

Here’s the App Store link: https://apps.apple.com/us/app/jimo-be-the-guide/id1541360118.

The iOS app is also open source. More details here: https://www.reddit.com/r/SwiftUI/comments/1fq20na/just_opensourced_my_swiftui_social_map_app/.

Overview:

• Uses PostGIS for map queries, which might be helpful if you're working on location-based apps

• Implements Firebase authentication, showing how to integrate third-party auth with FastAPI

• Uses SQLAlchemy for db queries and Alembic for managing database migrations

The codebase is organized into 'core' and 'features' folders, which helped keep things manageable as the project grew.

There's definitely room for improvement, but I learned a ton building it. If you're curious, feel free to check out the GitHub repo. The README has setup instructions and more details. Hope people find it helpful!

Hey everyone. I'm a backend dev writing code in Python FastAPI. I don't have much experience in frontend other than basic HTML/CSS/JS.

I'm exploring different frontend tools/frameworks for my backend. The first obvious answer is React/Nextjs. But I don't want to delve into that complexity.

Other options I've explored are HTMX, Reflex, Astro, Sveltekit, etc. I'll mainly use the frontend for doing UIs for the backend (because testing in Swagger feels dull sometimes), make MVPs, and participate in hackathons (where quick development matters)

Which frontend would you recommend learning as a backend dev?

I have been making projects in FastAPI for a while now, I want to know about the best industry standard fastAPI project directory structure.

Can you people share good FastAPI open source projects? Or if you are experienced yourself, can you please share your open source projects? It will really help me. Thanks you in advance.

Plus what's your directory structure using microservice architecture with FastAPI?

Yes, I'm really loving fastapi. It's so nice and smooth and convenient

Hey r/FastAPI,

I've created an open-source project generator built around FastAPI for quickly setting up production-ready full-stack AI/LLM applications. If you're working with FastAPI and need to skip the boilerplate for things like auth, databases, background tasks, and AI integrations, this might be useful.

Repo: https://github.com/vstorm-co/full-stack-fastapi-nextjs-llm-template
(Install via pip install fastapi-fullstack, then generate with fastapi-fullstack new – interactive CLI for selecting features)

FastAPI-centric features:

• High-performance async API with Pydantic v2 for type-safe schemas and validation

• Clean architecture: Versioned routes, dependency injection, middleware for security (CORS, CSRF, rate limiting with slowapi)

• Authentication: JWT with refresh tokens, API keys, OAuth2 (Google) – all integrated seamlessly

• Databases: Async support for PostgreSQL (SQLAlchemy), MongoDB, or SQLite, with Alembic migrations

• Background tasks: Plug-and-play with Celery, Taskiq, or ARQ for distributed queues

• AI/LLM integration: PydanticAI agents with tool calling, WebSocket streaming, and persistence – built on FastAPI's async strengths

• Observability: Logfire instrumentation for tracing requests, queries, and agent runs; plus Sentry/Prometheus

• Django-style CLI: Custom management commands with auto-discovery for FastAPI apps (e.g., my_app db migrate, my_app user create)

Optional Next.js 15 frontend (React 19, Tailwind) with real-time chat UI, but you can generate backend-only if preferred. Over 20 configurable integrations to mix and match.

Inspired by tiangolo's full-stack-fastapi-template, but extended for AI focus, modern stacks, and more flexibility.

Screenshots, demo GIFs, architecture diagrams, and docs in the README.

Feedback from the FastAPI community would be awesome:

• How does this compare to your go-to setups for larger FastAPI projects?

• Any FastAPI-specific pain points it misses (e.g., more advanced deps or middleware)?

• Ideas for new integrations or improvements?

Contributions welcome – let's make FastAPI even better for AI apps! 🚀

Thanks!