Django replaces a stack of recurring web decisions
Django gives a Python project URL routing, request handling, an object-relational mapper, schema migrations, forms, templates, authentication, sessions, caching hooks, security middleware, and an automatically generated administration site. Those pieces share conventions, so a model can flow into a migration, form, permission check, and admin screen without choosing a different package for every layer. That cohesion is Django's main advantage.
It fits products whose core is structured records and user workflows: publishing systems, internal operations, marketplaces, account portals, and line-of-business software. The built-in admin is especially useful for staff operations, though it is not intended to become every customer's interface. Teams still design domain models, permissions, background work, APIs, and the public experience. Django removes plumbing; it does not decide the product.
SQLite starts the tutorial, while production usually needs more
The quick install guide requires Python and uses SQLite because Python includes it. Larger deployments can use PostgreSQL, MariaDB, MySQL, or Oracle through the supported database layer. That makes the first tutorial easy to run without credentials or another daemon. It does not make SQLite the automatic choice for a busy multi-user service with concurrent writes, operational backups, and database-specific features.
A production team must choose and operate its database, run migrations during releases, monitor connection use, and test restores. Django's ORM covers a lot of common SQL work, but indexes, query plans, locks, transaction scope, and data migrations remain engineering concerns. The framework can generate a query without proving that it stays fast after the table grows.
What happened when we ran it
Our lab cloned commit 0b40210 into a fresh unprivileged container with 3 CPUs and 8 GB RAM. The checkout contained 7,009 files, about 533,845 source lines, and 45.6 MB. Its npm install completed in 47 seconds, adding 213 packages and occupying 124 MB. This was the repository's JavaScript tooling path, not a Python package installation.
The package file exposed no build script or target, so our harness skipped build. The npm test command succeeded in 8 seconds. Npm audit found 0 known vulnerabilities: 0 critical, 0 high, 0 moderate, and 0 low. The scan also found 17 CI workflow files, a tests directory, and no Dockerfile. Those are precise results for the measured checkout and command path.
Django's Python test suite is separate. The README points contributors to dedicated unit-test instructions, while package.json runs Grunt and QUnit for browser-facing assets. An 8-second npm pass does not establish that the ORM, request stack, migrations, database backends, or Python security tests passed. A contributor acceptance run should execute the relevant Python suite and database matrix as well as the JavaScript checks.
The admin saves time when staff workflows match models
Registering models can produce searchable list views, edit forms, filters, relations, and permission-aware staff access with little code. That is a genuine head start for content moderation, customer support, inventory correction, and internal review. The admin also exposes data powerfully, so access should be limited, protected by strong authentication, and tested against the same object-level rules as custom staff tools.
Do not bend the admin into a polished customer application. Complex multi-step flows, unusual layouts, and strict front-end interaction requirements usually deserve custom views or an API client. Use the admin for trusted operators working close to the data. When every screen needs extensive overrides, its initial speed advantage has already been spent.
Production starts where runserver stops
Django's deployment checklist explicitly rejects manage.py runserver for production and calls for a WSGI or ASGI server. It also requires a secret production key, DEBUG=False, correct ALLOWED_HOSTS, static-file collection, safe media handling, database backups, logging, and real email settings where the application sends mail. The check --deploy command catches some configuration mistakes but cannot inspect the whole hosting environment.
HTTPS belongs at the front of the design. Login credentials, session cookies, and password-reset tokens need encrypted transport. After HTTPS is working, the checklist calls for secure session and CSRF cookies. A proxy must forward scheme and host information correctly, while Django must trust only the proxy topology you actually operate. Misaligned proxy headers can undo otherwise sensible security settings.
Built-in defenses still depend on application code
Django documents protections for cross-site scripting, cross-site request forgery, SQL injection through the ORM, clickjacking, host validation, sessions, uploads, and HTTPS. Template escaping and parameterized queries remove common mistakes from normal paths. Raw SQL, manually marked safe HTML, disabled CSRF checks, permissive hosts, and unsafe file serving can bypass those protections. Framework defaults reduce risk without replacing review.
The security guide also treats user uploads as untrusted. Serve them from storage and a web server that will not execute their contents, restrict size and type where appropriate, and back them up separately from the database. A database restore without uploaded files may recover rows that point to nothing.
Active main-branch work is newer than any stable contract
GitHub showed 88,957 stars, 474 combined open issues and pull requests, and a last push on August 23, 2026. The GitHub latest-release endpoint returned 404, which matches Django's practice of signed Git tags and stable release branches rather than GitHub release objects. The main branch identified itself as 6.2 alpha, so it should not be treated as the latest stable package.
Django publishes version-specific documentation and a time-based release process with designated long-term support lines. Use an official release, read the documentation for that exact version, and stay on current patch releases for fixes. Django is the right default when an integrated Python web stack saves decisions. The 47-second npm result is reassuring for its asset tooling, while production confidence still requires the Python tests and deployment checklist.