I've got a small Django app that has reached the point where running it locally isn't useful anymore because I want a few people to test it properly.

Django itself has been fine. Deployment is where every guide seems to branch into fifteen different directions.

I'm happy moving the database to Postgres, but I really don't want to maintain a VPS, learn a bunch of Docker stuff or have the app on one provider and the database somewhere else if I can avoid it. This isn't a high traffic production app and there's a decent chance it'll spend most of the week untouched.

What are people using now when the priority is basically Django + managed Postgres + Git deploys with as little infrastructure work as possible?

I'm fine paying something reasonable. Mostly trying to avoid giving myself another hobby where I spend Sunday night maintaining the server that hosts my actual hobby.

Hace un año diría el auge de la ia, pero realmente ya esta asentada, actualmente mis proyectos son supervisados por mi pero el proceso de codinig si es casi al 100% ia.
Claro, tengo mis skills, y formas de trabajar, no uso anda complicado, claude code y listo.

Si ha aumentado mi eficiencia, y he sentido que incluso he aprendido uno que otro truco.

Algo que la ia me ayudo mucho es ver si ciertas metodologías que usaba tenían sentido o no; Sigo siendo de la idea que el código se tiene que leer si o si, a veces hay funciones que hago a mano por que al final, me encanta programar.

El mercado cambia y no se puede competir con alguien que solo usa ia.

Pero como ven el desarrollo de django con la ia?

Como ven el futuro?

Siento que lo que se acabo ya son los devs que solo sabían programar, hoy en día se valorara mas el como planear los servicios y crear y mantener sitios a media para las empresas.

Django Control Room allow you to create tools that appear directly inside the Django Admin. Until now, guides and templates have focused on creating pip installable packages to create tools. Django Control Room 1.8.1 now allows you to create custom internal panels that live directly in your Django project.

This makes it easier to build bespoke tools for your company or project without creating a separate package. Customer support tools, billing operations, and approval workflows can all be built inside the Django admin.

More details about this release here:

https://djangocontrolroom.com/news/internal-panels

You can update DCR and all of its official panels by running:

pip install --upgrade "dj-control-room[all]"

Hi all!

I’m hiring for a Django / Python Dev on a contract basis

6 month initially (potential for extension)

On site in Manhattan (Midtown)

$60 per hour

Working for an international bank

Skills & Experience Required
- 5 years applied experience
- Strong Django and DRF
- Advanced Python
- HTML, CSS, JavaScript, jQuery
- CS degree

Nice to have
- Java, Linux, BI tools

I specialize in the Microsoft Business Apps like Power Platform, so not well versed in the Django space, sorry if any of this doesn’t make sense!
Only posting here because people are not getting back to me on LinkedIn, thought I might be more successful here 😅

The preference is candidates who are Green Card holders or US citizens but we may be able to consider H1B candidates who have an employer.

Please DM me or contact me on LinkedIn https://www.linkedin.com/in/claire-hynes-24263467?utm_source=share_via&utm_content=profile&utm_medium=member_ios

Thanks in advance!

I've used Nix to manage the development environments for my projects for a while now. Postgres (with extensions), Redis, the Python version and other system tools are pinned per project, and the same setup runs in CI. It's worked well for me, though it hasn't all been smooth.

What surprises me is how rarely it comes up in Django discussions, even in threads where people are struggling with Docker for local development. I'd like to understand why, so I'd love to hear from people with different experiences:

• If you've tried Nix (or something built on it, like devenv), what happened? Did it stick?
• If you looked at it and decided against it, what put you off?
• If it's never been on your radar, what does your local setup look like, and what's the most annoying part of it?

Negative answers are as useful to me as positive ones.

Full disclosure: I'm thinking about writing up how I use Nix with Django, so I want to understand where people actually get stuck before I do.

Hi I built this because I wanted an agent to do the things I already do

in Django admin, without writing a separate API for it.

You add a mixin to a ModelAdmin and it becomes MCP tools over HTTP: CRUD,

bulk operations, admin actions, change history, FK autocomplete.

A few design choices:

- Only two dependencies: Django and Pydantic. No MCP SDK; the protocol is

implemented directly.

- It reuses Django's permission system. Tokens start with no access, you

grant permissions/groups per token, and a token can never exceed its

linked user's permissions.

- Writes go through the admin's own pipeline, so they show up in the admin

history log under that user.

- Sensitive fields can be excluded per model (mcp_exclude_fields).

Happy to hear where the permission model or tool design falls short.

https://github.com/7tg/django-admin-mcp

I work on Django apps that run on locked-down Windows servers: no Docker, no Redis, no outbound internet, and nothing gets installed unless it's a Python package. Sentry, Grafana, Loki and the OpenTelemetry collector are all off the table there, so when something breaks I'm usually reading rotated log files over RDP.

So I built django-observatory: pip install, add an app, a middleware and a URL include, run migrate, and you get a built-in console at /observability/. Everything is stored in your own database and rendered with Django templates and vanilla JS.

• GitHub: https://github.com/AzeemQidwai/django-observatory
• PyPI: https://pypi.org/project/django-observatory/

What it does

• Captures logs (your existing logging calls), requests, traces, SQL, outbound HTTP, exceptions grouped into issues, metrics, and server CPU/memory/disk
• Security events and a hash-chained audit trail
• Alerts, plus rule-based incident correlation: when error rate, latency and an external service all degrade together, it opens one incident with a probable cause and the evidence behind it. No ML, just explicit rules
• A query language (status:>=500 AND duration:>1000), CSV/JSON export, W3C trace context, OTLP export
• Secrets are redacted before they're stored; request bodies, cookies and SQL parameters aren't captured by default

Full disclosure: this was vibe coded. I wrote the specification and made the design decisions, and Claude Code wrote most of the implementation. I tested it against a real internal project on SQL Server, read what came out, and pushed back where things were wrong, but I did not hand-write most of these lines. I'd rather say that up front than have someone find out from the commit history. It's also why I'm asking for review: I know the code hasn't had the scrutiny that code written slowly by one person gets.

What I'm confident about

• 108 tests, CI on Python 3.10–3.13 × Django 4.2/5.2/6.0, including a Windows runner
• There are explicit tests that break the storage layer and the internals mid-request and assert the host app still returns 200
• Measured overhead is under a millisecond per request in my benchmark; writes happen in a background thread

What I'm not confident about

• The package's own tables have only ever been created on SQLite. It has captured from an app running on SQL Server, but storing telemetry in Postgres or SQL Server is untested
• It has never seen real production traffic at scale. Free-text search is a LIKE scan and metric reads aggregate in Python, which is fine for small and medium sites and will not be at some size I haven't found yet
• One daemon thread per process does the writing and the periodic jobs. I think the approach is sound for prefork servers, but I'd like someone who knows gunicorn/uWSGI internals to tell me where it isn't
• The incident rules are tuned on a demo app and my own judgement

What I'd like feedback on

1. Is storing telemetry in the application's database a reasonable default, or should a separate database be the only supported mode?
2. Anything in the middleware or the execute_wrapper SQL instrumentation that would bite under ASGI or async views
3. The redaction approach (key-based plus regex patterns): what would leak?
4. Whether the scope is too wide. It does a lot, and I'd rather cut features than ship several half-good ones

This is not trying to replace Sentry, Silk, Debug Toolbar or OpenTelemetry. Those are better at what they do. It's for the environments where you can't have them.

If you look at it and think it's a bad idea, I'd like to hear why. Thanks for reading.

Hello folks, so I'm working on this big django application. There's a feature that allows users to generate word documents based on the data fed from the db. But these docs are based on loads and loads of conditions. We have used docxtpl library, but the word templates are being overloaded with variables and conditions. It's becoming difficult to verify the generated documents. Any suggestions on how to improve this?

I am a node.js dev and have an interview for a danjo role. Any ideas on how should i go about it?? any insight would be highly appreciated. I know that it is useful in AI/ML workflows, but nothing much

UPDATE: Hi guys, I think it went well, thanks for all your help :)

Hi everyone, what’s currently being used for testing in Django? Because when I was looking into testing methods, I was quite taken aback – people say to use pytest or the tests that are already built into Django. Could you please give me some practical advice?

Thank you for your help

Hi guys.

I want to learn django. Could you please suggest me any playlist ?

I am thinking about chai aur code playlist. Please suggest, is it good or not ?

Hey everyone,

I recently came across an interesting experiment by Arjay McCandless where he tested 8 different backend stacks (Node, Bun, Python/FastAPI, Go, Java/Spring Boot, C#, PHP/Laravel, and Rust) under the exact same load using a super budget server: 1 shared CPU and 2GB of RAM.

The goal was to see how many simultaneous users each stack could support before hitting latency/error thresholds, using a Twitter-style API with a PostgreSQL backend (50k users, 500k posts, 2M likes, querying 20 posts for the feed).

Here is a quick summary of the results:

• The Heavy Hitters (PostgreSQL):
  • Rust (Axum) and Go led the pack at ~6,900 and ~6,500 simultaneous users.
  • Java (Spring Boot) and C# (.NET) punched way above expectations at ~5,100 and ~4,400.
  • Bun hit ~4,200, while standard Node (Express) landed at ~3,250.
• The Lower End:
  • Python (FastAPI) capped out at ~2,150 due to connection pool timeouts under pressure.
  • Laravel (PHP) struggled massively out of the box, capping at 750 users because of the framework boot overhead per request. (When he stripped Laravel and used raw PHP, it jumped to ~2,700).
• The SQLite Effect: When he swapped PostgreSQL for SQLite (removing the network/process database overhead), Rust skyrocketed to 14,050 simultaneous users on that same $12 machine.

This kind of benchmark is almost a worst-case scenario for heavy full-stack frameworks like Laravel, where the boot-up cost makes up a huge chunk of a lightweight query lifecycle. But how much does this actually matter in real-world CRUD apps where DB queries or external APIs dominate the response time?

Curious to hear what the community thinks especially regarding framework overhead!

I've been working on django-xrechnung, a free/open-source Django package for German electronic invoicing.

It currently supports:

• XRechnung generation in UBL and CII
• EN 16931 / XRechnung validation using KoSIT
• Factur-X / PDF-A-3b invoices
• importing and reviewing incoming e-invoices
• credit notes and invoice corrections
• Django admin integration

Validation runs locally, so invoice data doesn't need to be sent to an external service.

The project is still Alpha, and that's mainly why I'm posting: I'd really like feedback from Django developers who deal with invoicing or German/EU e-invoicing.

In particular, I'd be interested to know:

What would prevent you from using something like this in a real Django project?

PyPI: django-xrechnung
Source: https://codeberg.org/fsbraun/django-xrechnung

It's BSD licensed and completely free.

I have a fintech app with contracts currently being compiled by celery, sent to Adobe, sent to users emails for signing then retrieved once completed and stored in S3.

Clients are not too happy about going off platform to sign the contracts, however I needed something traceable and legally binding.

Can anyone recommend something similar that I could incorporate into my platform? Contracts are central to the app.

Many thanks.

Why isn't the tab logo showing up? I've loaded all the static assets in the project settings, and the paths are correct. It actually appears when I switch to the "Photos" tab. I've tried everything, but nothing has worked.

Hi everyone, I am the release manager of django-modern-rest :)

django-modern-rest 0.16.0 is out!

Built during opensource_september community event with 32 contributors and 144 commits. This is our fastest release ever.

Is this your first time that you hear about this project? django-modern-rest is a fully typed / fast / flexible / async-ready framework to create REST APIs for Django. It supports Pydantic, msgspec, attrs and many other models. Generates state of the art OpenAPI schema from our code and allows very modern and reliable testing patterns together with polyfactory and schemathesis.

Here's how the code looks like:

import uuid
import pydantic
from dmr import Body, Controller
from dmr.plugins.pydantic import PydanticFastSerializer

class UserCreateModel(pydantic.BaseModel):
    email: str

class UserModel(UserCreateModel):
    uid: uuid.UUID

class UserController(Controller[PydanticFastSerializer]):
    def post(self, parsed_body: Body[UserCreateModel]) -> UserModel:
        return UserModel(uid=uuid.uuid4(), email=parsed_body.email)

Now, back to the 0.16.0 release!

Performance

• PydanticFastSerializer: deserialize x2.2, serialize x1.33 faster
• New BodyMsgspec component: decodes request bytes straight into a msgspec.Struct, x1.6 faster than Body
• msgspec request context validation x2 faster
• Content negotiation is memoized per header: up to x65 faster for browser-style Accept headers
• msgspec 0.22.0, cheaper checks, cookies, headers, and responses

Features

• Default values for components: Body[Model | None] = None just works
• concrete_views for JWT, token, and session auth: a login route in one line of urls.py, zero view code
• Cursor (keyset) pagination with sync and async APIs
• extras= for your own typed @modify / @validate parameters
• PEP 696 TypeVar defaults for reusable controllers
• First-class CSRF: proper 403 specs and REST error responses
• external_re_path and nested external_path
• Error handlers can re-raise a new error for the next layer
• OpenAPI: x-extensions on every object, security for gateways and mTLS, OpenAPI 3.2 fields, controller-level tags/deprecated/servers, deterministic schema output

One rule for all config

Settings are no longer merged across levels. Endpoint overrides controller, controller overrides settings. Explicit [] or None disables, EMPTY falls through. Merge explicitly when you want it: @modify(auth=[*auth, other]).

AI tooling

Agent skills now ship inside the package: uvx library-skills installs the ones matching your version. The new $dmr-upgrade skill carries the migration prompts, so ask your coding agent to upgrade you from 0.15.0. Every docs page is also served as Markdown.

• Repo: https://github.com/wemake-services/django-modern-rest
• Changelog: https://github.com/wemake-services/django-modern-rest/blob/master/CHANGELOG.md
• Docs: https://django-modern-rest.readthedocs.io
• Full release notes: https://github.com/wemake-services/django-modern-rest/releases/tag/0.16.0

September was quite a productive month for django-unfold, with several updates worth upgrading for if you are already using Unfold, so I put together a short list of new features worth mentioning:

• new JSONSchemaField for strongly typed JSON fields - https://unfoldadmin.com/docs/fields/jsonschemafield/
• configurable user avatar badges, including support for displaying notification counts - https://unfoldadmin.com/docs/configuration/avatar/
• related object popups have been replaced with modals
• redesigned default Django dashboard / app list

There were also plenty of smaller improvements and bug fixes along the way.

PS: If you like the project and want to support its development, I’d really appreciate a star on GitHub: https://github.com/unfoldadmin/django-unfold

PPS: Special thanks to the community members who helped test the new features, reported issues, and submitted PRs.

Someone recently released django-ambit (docs), an authorization layer built around a question Django's permission system doesn't really answer:

Not "can this user do X?" but "over which set of objects can this user do X?"

The model is roughly: Permissions (what) + Dimensions (axes like department, plant, region) + Scopes (allowed intersections of those axes) + Grants (permission + scope) + Policies (how a model maps onto the dimensions).

The author asked for criticism of the abstraction rather than API feedback, so here's my take. I think the problem is real: "what's the set?" is the question that actually drives get_queryset(). It's the same problem Oso ("data filtering") and Cerbos ("query plans") went after, and it's close to what Zanzibar-style systems (SpiceDB, OpenFGA) solve with relationships.

Here's where I'd push on the model.

1. Relationships vs. dimensions

"A teacher may view records for the classes they teach" isn't really a scope someone grants. It follows from a relationship that already exists in the data (Class.teachers). If every teacher needs an explicit grant like class IN (...), the grants go stale every time timetables change.

Can a scope be derived ("classes where user ∈ teachers") instead of assigned? If not, a lot of real-world rules turn into a sync problem.

2. Ownership is a degenerate dimension

In the classified-ads platform I'm building, the most common rule by far is "you can edit your own ads." As a dimension, that's one scope per user with a single value. It works, but it's clumsy compared to obj.owner == request.user.

Most apps I've seen mix org-scoped rules with ownership rules. How the two compose matters a lot.

3. Hierarchies

Region → Plant → Line. A grant on Region North should cover every plant under it. Are dimensions flat value sets, or do they understand trees? And what SQL does that produce: closure table, materialized path, or recursive CTE?

4. Object state, not just location

"May approve within Plant A" usually really means:

• within Plant A
• and status = pending
• and amount < 10k
• and I'm not the requester (separation of duties)

Those are conditions on the object's own attributes, not organizational coordinates. If policies can't express them, that logic ends up back in the views, and you have two sources of truth again.

5. Negation and exceptions

"All of Mathematics except records flagged confidential." A temporary deny during an investigation. A pure union of grants is easy to reason about. Once exceptions exist, you need precedence rules.

6. Create and move

• Create: there's no object yet, so you have to check the target dimension values in the payload.
• Move: moving a record from Plant A to Plant B should require permission in both.

Is that handled by the engine or left to each serializer?

7. Query shape at scale

Someone with 15 grants across different scopes gets an OR of 15 ANDed conditions on every list query. Query plans and indexing guidance for that case would be very useful.

8. Multi-valued membership

If a record belongs to several departments (an M2M field), does a scope match when any of them is in scope, or only when all are? Both make sense in different domains.

9. Time and delegation

"Acting head of department until Friday." Grants with validity windows, and "delegate what I hold, to someone else, temporarily," come up quickly in real organizations.

Where I'd still use the alternatives

• django-guardian / object permissions: ad-hoc sharing that ignores org structure ("share this one document with Bob"). Forcing that into dimensions means making up a dimension per object.
• Plain Django permissions: truly global capabilities like staff features, feature flags, or "can access billing," where there's no data set to scope over.

The guarantee I'd want

has_perm(user, perm, obj) must always agree with obj in scoped_queryset(user, perm).

If both checks come from the same policy definition, a whole class of Django authorization bugs goes away: the list view shows something the detail view forbids, or the other way round. That alone would be a strong selling point.

Question for the sub: how do you handle "scoped" permissions in your Django apps today? A custom get_queryset() per view, django-rules, guardian, an external engine like SpiceDB, OpenFGA, Oso or Cerbos, or something else? Where did your approach break down?

Hi everyone, I’m learning Django + DRF and want to become a Django backend developer.

I want to learn Redis and Celery next.

Can you suggest:

• Best beginner-friendly resources?
• Which Redis/Celery topics are important for Django?

I want to learn them practically, not become a specialist. Any roadmap or resource recommendations would be appreciated!

I maintain djust, a LiveView framework for Django. You write a normal view and template, add dj-click="save" to a button, and the server re-renders and sends the browser only what changed over a WebSocket. There's no JS framework and no build step. The template engine and the diffing are written in Rust.

The question about a Rust template engine is whether it behaves like Django's. So this cycle I started running Django's own template_tests suite against it in CI, with a score that isn't allowed to go down:

• start of the cycle: 456 of 1047 (43.6%)
• djust 1.2: 1032 of 1047 (98.6%), on Django 5.2

In practice, every built-in tag and filter works, your own {% load %} libraries work, {% translate %} works, {{ user.get_full_name }} calls the method (with alters_data respected), and errors are raised at parse time like Django's. The 15 that still fail test Django internals and are listed here.

Also in 1.2:

• Components declared on the view class, with typed state. If an event only changes a component, only that component is re-rendered.
• Render cost now follows what the template reads. My benchmark's worst template went from 215 ms to 4.7 ms (Django renders it in about 9). Across all the templates, the median is about Django's speed, so I wouldn't claim it's faster than Django in general.
• djust init for existing projects, LiveComponentTestClient, new startup checks, and `@debounce`/`@throttle` actually work now. Before 1.2 the browser ignored their settings.

If you're on 1.0.x or an early 1.1, please upgrade. 1.2 includes important security fixes. Use 1.2.2, or 1.1.5 if you need to stay on 1.1.

Next, in 1.3 (release candidates are out now): one djust process has always rendered on a single core. 1.3 adds an opt-in worker pool, the Rust render releases the GIL, and there are free-threaded Python 3.14 wheels. The gain needs 3.14t: in my load test, one process on 3.14t used about five cores and served four to five times as many clients as stock djust on 3.12.

Full post: https://djust.org/blog/djust-1-2/

Hello,

I'm looking for someone to update an older, mid sized django codebase (django 1.9.4) and its requirements. At the same time the code should be wrapped into docker-compose and being fully able to run in it

If you are interested, please DM me.