Coming from Django Admin

If you know Django Admin, starlette-admin will feel familiar. Both generate an admin interface from declarative, per-model configuration, and both support inline editing, batch actions, and per-request permissions.

The differences are structural. starlette-admin runs on any ASGI application instead of requiring Django, works with several ORMs, and lets you plug in your own authentication rather than imposing a built-in user model.

This guide maps every major ModelAdmin concept to its starlette-admin equivalent, with side-by-side code.

Mental model

Registering a model

from django.contrib import admin
from .models import Post


@admin.register(Post)
class PostAdmin(admin.ModelAdmin):
    list_display = ["title", "published", "created_at"]
    search_fields = ["title", "content"]

from starlette_admin.contrib.sqla import Admin, ModelView


class PostView(ModelView):
    fields = ["id", "title", "content", "published", "created_at"]
    exclude_fields_from_list = ["content"]
    searchable_fields = ["title", "content"]


admin = Admin(engine, title="Blog Admin", secret_key="change-me")
admin.add_view(PostView(Post, icon="fa fa-newspaper"))
admin.mount_to(app)  # app is your FastAPI or Starlette instance

Two structural differences stand out:

1. One field list drives every page. fields is the single source of truth. You then use exclude_fields_from_list, exclude_fields_from_detail, exclude_fields_from_create, and exclude_fields_from_edit for per-page variations.
2. The Admin instance owns the database engine. You don't pass a session to each view.

List page options

Forms

Fieldsets example

class PostAdmin(admin.ModelAdmin):
    fieldsets = [
        ("Content", {"fields": ["title", "body"]}),
        ("Publication", {"fields": ["published", "created_at"]}),
    ]

from starlette_admin import FieldsetWidget


class PostView(ModelView):
    fields = ["id", "title", "body", "published", "created_at"]
    form_layout = [
        FieldsetWidget(legend="Content", children=["title", "body"]),
        FieldsetWidget(legend="Publication", children=["published", "created_at"]),
    ]

form_layout goes further than fieldsets: you can build tabs, responsive grids, and nested layouts. See Form Layout.

Inlines

class CommentInline(admin.TabularInline):
    model = Comment
    extra = 1


class ArticleAdmin(admin.ModelAdmin):
    inlines = [CommentInline]

from starlette_admin.contrib.sqla import InlineModelView, ModelView


class CommentInline(InlineModelView):
    model = Comment
    fields = ["author", "body"]


class ArticleView(ModelView):
    inlines = [CommentInline]

starlette-admin detects the foreign key when it's unambiguous, and it supports composite foreign keys. See Inline Forms for advanced configurations.

Actions

@admin.action(description="Mark selected articles as published")
def make_published(modeladmin, request, queryset):
    queryset.update(published=True)


class ArticleAdmin(admin.ModelAdmin):
    actions = [make_published]

from starlette_admin import ActionSelection, action, flash


class ArticleView(ModelView):
    actions = ["make_published", "delete"]

    @action(
        name="make_published",
        text="Mark selected articles as published",
        confirmation="Publish the selected articles?",
    )
    async def make_published(
        self, request: Request, selection: ActionSelection
    ) -> None:
        for article in await selection.rows():
            article.published = True
        flash(request, "Articles published")

Where Django Admin passes a QuerySet, the starlette-admin handler receives an ActionSelection object. It resolves rows, primary keys, and active filters lazily, and it behaves the same way when a user selects all matching records.

Actions can also render a custom HTML form inside the confirmation dialog, which in Django Admin means building an intermediate page. For per-row operations, use @row_action and @link_row_action, which have no Django Admin equivalent.

Permissions and authentication

Django Admin delegates to django.contrib.auth. starlette-admin splits the problem in two: an AuthProvider answers "who is this user", and per-view methods answer "what can they do".

The following view restricts deletion to users with the admin role:

class ArticleView(ModelView):
    def can_delete(self, request: Request) -> bool:
        return "admin" in request.state.admin_user.roles

Every can_* method receives the request, so your authorization decisions can read the current user, HTTP headers, or anything else on the request.

Save hooks and signals

Site-wide configuration

What you gain by switching

• End-to-end async: Handlers, lifecycle hooks, and widget callbacks can all be coroutines that run on your existing event loop, next to your FastAPI endpoints.
• Database flexibility: The same admin configuration applies whether you use SQLAlchemy, SQLModel, MongoDB through MongoEngine or Beanie, or Tortoise ORM.
• Export and import built in: CSV, JSON, and PDF, plus Excel and other formats through tablib. Export records directly, or import bulk data through a preview-first wizard that enforces row-level validation and supports optional primary key upserts. See Export and Import.
• Dashboard widgets: Stat cards, ApexCharts, and layout grids compose into index pages and custom views, so you don't need an external theme package to build a dashboard. See Custom Views and Widgets.
• Modern user interface: Tabler (Bootstrap 5) gives you dark mode, column visibility toggles, and search highlighting by default.

What you must bring yourself

• Authentication: There's no bundled user model or permission database. Implement AuthProvider.authenticate() against the data store your application already uses.
• Audit logging: starlette-admin doesn't generate a LogEntry table. Wire the event system to your own audit table.
• Model-level UI configuration: Django conveniences such as model-level choices, verbose_name, and validators don't transfer. Declare them on the starlette-admin field instead, with EnumField, label=, and validators=.