[!WARNING] Pre-1.0. 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.

The badge above is the released one. This README describes main, which may be ahead of it.

Why FastFort?

Every FastAPI project rebuilds the same things from scratch: an admin panel, a sign-in form, password hashing, a token endpoint, refresh rotation, CSRF, an upload field that cannot be tricked. Django ships that. FastAPI does not.

FastFort does — for an async stack, with no build step and no Node.js. What it does not ship yet is listed below, plainly, rather than left for you to find out after installing.

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.

And a token API for the rest of your application

One setting, and the same user model and password hashes the admin uses are behind four routes in OAuth 2's shapes:

FastFortSettings(project_name="Shop", auth={"api_enabled": True})

POST /auth/token     identity + password  ->  access + refresh
POST /auth/refresh   refresh              ->  a new pair, retiring the old
POST /auth/logout    refresh              ->  204
GET  /auth/me        Bearer access        ->  who that is

The dependency is worth having even without the routes:

from fastfort.auth import bearer_user

current_user = bearer_user(fort)


@app.get("/orders")
async def orders(user: Annotated[User, Depends(current_user)]) -> list[Order]:
    return await orders_for(user)

It hands your route the user row, and rejects an account deactivated since the token was issued -- which a signature check alone would keep admitting until the token expired.

Features

How it is put together

UI (Jinja2 · CSS · vanilla JS)  ─┐
Admin (ModelAdmin, forms)       ─┤
Auth (sessions, tokens, CSRF)   ─┼──►  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 second ORM never touched the admin or the UI — fastfort/orm/tortoise/ was written without a change anywhere above fastfort/orm/, and a conformance suite asks both backends the same questions so that "the second one behaves the same" is a test rather than a claim.

There is no front-end framework. ui/static/js/ is one IIFE, no modules, no build step, and every control works with JavaScript switched off — sorting and filtering are links, everything else is a form. The script upgrades them in place; it never owns them.

Not in the box yet

fastfort/contrib/ is a placeholder. Roles and permissions beyond is_staff/is_superuser and soft delete are not implemented — the spec layer carries the ChangeSet an audit log would store and the field-masking it would need, but nothing writes one. Earlier versions of this README listed them as features. They were a plan.

Sign-in records are the one half of an audit log that now exists: fort.record_sign_ins(...) writes every attempt against a table your project owns. What it does not record is data changes — who edited which row.

Inline editing of related rows is the other gap worth naming — Django's InlineModelAdmin, editing an invoice's lines on the invoice's own page. A related model is reachable, and editable, on its own page.

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