Stacks vs Django

Django got there first on the admin. Stacks generates one too, in your language.

Django has been the batteries-included argument for twenty years, and its admin is still the single best reason to choose it. Stacks makes the same argument for TypeScript teams, and adds the parts Django leaves out, which are the background workers, the interactive front end, and the deploy.

What Django is.

In its own terms, not ours.

Django gives you an ORM with sound migrations, an auth and permissions system, forms, and an admin site generated from your models that is genuinely production-usable. Django REST Framework and Ninja cover APIs, Channels covers WebSockets, and the whole thing sits in the Python ecosystem, which is where the data and machine learning tooling lives.

Where each one wins.

Same amount of room on both sides, on purpose.

Pick Django for

  • The admin

    Django admin is more capable out of the box than most admin panels teams build, and it has twenty years of extension points.

  • The Python ecosystem

    If your product involves data science, notebooks, or machine learning libraries, being in Python is worth more than anything on this page.

  • Migrations

    Django migrations are mature, dependable, and well understood by every Python developer.

  • Stability

    Long-term support releases and a strong deprecation policy, which large institutions rely on.

Pick Stacks for

  • Background work included

    Django 6 added a tasks API but no worker to run it, so production still means Celery or a community backend plus a broker. Stacks ships queues, batches, schedules, retries, and the workers that run them.

  • One language with the browser

    No Python on one side and TypeScript on the other, and no hand-written types across the API.

  • Front end in the framework

    STX views and components rather than Django templates plus a separate JavaScript build.

  • Deploy from config

    Servers on Hetzner or AWS, or any Linux box over SSH, plus DNS and certificates, all declared in the repository and applied by buddy deploy.

  • Your own mail server

    Stacks ships an SMTP and IMAP server, so hello@ and support@ on your domain are real mailboxes on your own box, readable in Mail.app or any client. buddy mail:provision creates them and their MX, SPF, DKIM, and DMARC records. None of the frameworks compared here ships one.

Side by side.

The dimensions teams actually decide on.

Dimension Stacks Django
Language TypeScript Python
ORM defineModel(), migrations generated Django ORM, migrations generated
Admin Dashboard generated from models Django admin, the category benchmark
API layer Generated REST plus OpenAPI DRF or Django Ninja
Background work Queues, workers, and schedules, included Tasks API, plus Celery or a community worker
Realtime WebSocket channels, included Channels
Front end STX: SSR, SSG, islands, signals Templates or a separate SPA
Deploy buddy deploy to Hetzner, AWS, or any SSH box Your own containers and IaC
Mail server Built in: SMTP, IMAP, real mailboxes None; inboxes come from a hosted provider

If you did move.

What ports cleanly, what does not, and where to start.

Models translate directly

Django model fields and Stacks attributes line up almost one to one, including validation and defaults.

Views become actions

Function and class-based views become actions; DRF serializers become model validation and API resources.

Celery becomes jobs

Tasks become job classes with retries and queues declared on them, and the broker choice becomes a config line.

The verdict.

Both answers are real. Most teams already know which paragraph is theirs.

Choose Django when

You are a Python team, or the product needs the scientific and machine learning ecosystem that only Python has.

Choose Stacks when

You want the same completeness, plus queues and a front end, without maintaining Python and TypeScript in one product.

The frameworks that usually come up in the same conversation.