[!WARNING] Early stage. 0.1.0 is the first release and the public API is not stable yet — before 1.0, a minor release may contain breaking changes, each one listed under a Breaking heading in the changelog. Pin a version.

Why FastFort?

Every FastAPI project rebuilds the same things from scratch: an admin panel, login, refresh tokens, roles, an audit trail. Django ships all of that out of the box. FastAPI does not.

FastFort fills that gap.

uv add "fastfort[sqlalchemy]"

# main.py
from fastapi import FastAPI
from fastfort import FastFort, FastFortSettings
from fastfort.orm.sqlalchemy import SQLAlchemyBackend

from app.db import Base, session_factory
from app.models import User

app = FastAPI()

fort = FastFort(
    settings=FastFortSettings(project_name="Shop"),
    backend=SQLAlchemyBackend(session_factory=session_factory, base=Base),
)
fort.set_user_model(User, identity_field="email")
fort.autodiscover("app")
fort.mount(app)

# app/products/admin.py
from fastfort import admin

from app.models import Product


@admin.register(Product)
class ProductAdmin(admin.ModelAdmin):
    list_display = ("id", "name", "price", "is_active", "created_at")
    list_filter = ("is_active", "category")
    search_fields = ("name", "description")
    ordering = ("-created_at",)
    select_related = ("category",)
    icon = "box"  # drawn beside the sidebar entry

    # Offered once rows are selected. "delete" is built in; this adds another.
    actions = ("delete", "archive")

    @admin.action("Archive", icon="box")
    async def archive(self, adapter, objects):
        for product in objects:
            await adapter.update(product, {"is_active": False})
        return f"{len(objects)} products archived."

Create the first account and start the server:

uv run fastfort generate-secret --export      # a signing key
FF_PASSWORD=... uv run fastfort createsuperuser \
    --identity you@example.com --password-env FF_PASSWORD --no-input
uv run uvicorn main:app

Open http://127.0.0.1:8000/admin, sign in, and you have a list, a search box, filters, sortable columns, numbered pagination, row selection with bulk actions, and working create, edit and delete pages. Foreign keys become searchable pickers -- backed by an autocomplete endpoint once the target table outgrows a dropdown -- and many-to-many fields become removable chips.

None of it needs JavaScript to work. Every control is a real form input and every sort header a real link; the browser-side code upgrades them in place and gets out of the way when it is not there.

Field names are checked against the model when the admin is built, so a typo in list_display is a start-up error naming every problem at once -- not a 500 the first time someone opens that page.

Features

How it is put together

UI (Jinja2 · CSS · HTMX)   ─┐
Admin (ModelAdmin, forms)  ─┤
Auth (tokens, permissions) ─┼──►  Spec layer (immutable, JSON-serialisable)  ◄── ORM adapters
Core (settings, registry)  ─┘

Everything above the spec layer is ORM-agnostic, and that boundary is enforced by tests rather than by convention. Adding a new ORM therefore never touches the admin or the UI, and a JSON API for a future SPA front end comes for free from the same specs the templates render.

Installation

uv add "fastfort[sqlalchemy,postgres]"    # SQLAlchemy on PostgreSQL
uv add "fastfort[sqlalchemy,mysql]"       # SQLAlchemy on MySQL
uv add "fastfort[sqlalchemy,sqlite]"      # SQLAlchemy on SQLite
uv add "fastfort[tortoise,postgres]"      # Tortoise on PostgreSQL
uv add "fastfort[all]"                    # everything

Requires Python 3.11 or newer. The ORMs are separate extras and neither is imported at package level, so installing one never pulls in the other.

Tortoise instead of SQLAlchemy

Four lines differ. Everything else — the settings, @admin.register, list_display, actions, export, import — is identical, because everything else is above the ORM layer and never sees a model:

from tortoise import Tortoise
from fastfort.orm.tortoise import TortoiseBackend

await Tortoise.init(
    db_url="postgres://…",
    modules={"models": ["app.models"]},
    # Tortoise 1.1 keeps its connections in a contextvar, and an ASGI server runs
    # the lifespan in a different task from the requests. Without this flag the
    # init above is invisible to every view: start-up looks healthy and the first
    # page that touches the database is a 500. `RegisterTortoise` from
    # `tortoise.contrib.fastapi` passes it for you.
    _enable_global_fallback=True,
)

fort = FastFort(settings=FastFortSettings(...), backend=TortoiseBackend())
fort.set_user_model(User)
fort.mount(app)

Development

The only prerequisite is uv. No Node.js, ever.

uv sync --all-extras          # set up the environment
uv run pytest                 # tests (SQLite)
uv run pytest --db=all        # tests against all three databases (needs Docker)
uv run ruff check .           # linting
uv run mypy fastfort          # type checking
make check                    # every gate at once

Two scratch applications come with the repository, and they are the fastest way to see any of this working:

make sandbox              # test_api/ on PostgreSQL — every column type,
                          #   PostGIS geometry, pgvector, on :8000
make sandbox-tortoise     # test_api_tortoise/ on SQLite — a different schema,
                          #   the same admin, on :8001

Open them side by side. The models, the ORM and the database all differ; the admin does not, which is the whole of what the layering buys.

See CONTRIBUTING.md before opening a pull request, and SECURITY.md to report a vulnerability.

License

MIT © Matnazar