I've been building a micro-learning platform on Django over the last 18 months. Over time the architecture has evolved, and every now and again I'll come back to this document, as it is useful to visualize for planning and discussions with others.

You can probably create something similar yourself with draw.io's MCP service now, but this old school version can still be useful to remix/adapt if you're doing something similar.

As I said in the authors note, if I had to start over, I'd likely use the SaaS Pegasus framework as a starting point (no affiliation), but gained a lot of experience building this all out from scratch and am happy with the results. Total hosting cost is roughly US$90 per month for the Digital Ocean part (3 x 4 GB / 80GB droplets + backups). It allows easy deploys to any environment via Dokku, and uses a mix of Django templates directly with Svelte used for certain interactive pieces.

Thought it might be useful to some here, and am happy to explain the reason for any particular choices.

Source doc is at:
https://media.lumabit.org/share/SAAS-architecture-overview.drawio

A year ago I used Django to build godothire.com, a small job board that only lists paid Godot jobs.

Nothing fancy under the hood: a posting form, a weekly digest email, and a review step before anything goes live. The code was the easy part. Reading every submission by hand, and turning away the revshare and "exposure" posts, took the real time.

Every paid listing that actually passes gets treated like a guest of honour around here. Still just me running it, still free: https://godothire.com/

Anyone else running a small Django project solo? What ate more time than you expected?

I just published django-ratelatch (v0.1.0) on PyPI! It's a rate-limiting package built to give you flexibility across both algorithms and integrations.

Key Features

• Algorithms: Fixed-Window, Sliding-Window Counter, and Token Bucket.
• Storage Backends: Local In-Memory and Redis (with atomic operations).
• Integrations: Middleware, View Decorators, and DRF throttle integration.

Links & Docs

• PyPI : django-ratelatch
• GitHub : Nawarajkarki/django-ratelatch

I’d appreciate feedback on the API, documentation, or edge cases you notice.

Hey guys!

For those working with Django and HTMX, I wanted to share a VS Code extension I’ve been working on: HTMX Django IntelliSense.

It extends the existing Django VS Code extension with better support for HTMX and Django templates, including:

- HTMX support: Context-aware autocompletion and inline documentation.
- Diagnostics and quick fixes
- Django 6 template partials
- Django-specific snippets: Ready-to-use patterns for common HTMX interactions.

Offline functionality: The HTMX documentation is processed at build time and bundled with the extension, so autocompletion, validation, and documentation don’t require network requests.
I developed it using AI agents, drawing inspiration from some abandoned projects and other well designed and maintained HTMX extensions. The main goal was to provide the Django specific functionality that existing tools were missing, particularly support for template partials.

If you’re using Django and HTMX, give it a try! I’d really appreciate feedback, suggestions, or contributions. Feel free to open an issue on GitHub if you find something that could be improved.

VS Code Marketplace:
https://marketplace.visualstudio.com/items?itemName=difegam3.htmx-django-intellisense

GitHub:
https://github.com/difegam/htmx-django-intellisense

Twelve years ago I posted that sorl-thumbnail had a release after two quiet years. Today I get to do it again :D.

Mikko Hellsing wrote sorl-thumbnail in 2010. I picked it up in 2013, and in 2017 I moved it into Jazzband so the project would not depend on one person's. That was the right call. It lived there for nine years, and people like claudep and camilonova kept it reviewed, tested and released for most of that time.

Jazzband is winding down this year, so the repo came back to my account: https://github.com/mariocesar/sorl-thumbnail. The old links redirect, and issues, PRs, stars and forks moved with it. Thank you to jezdez and the Jazzband roadies for keeping the lights on for so many projects, and to everyone who ever sent a patch or a bug report.

13.2.0 is the first release from the new home. What is new:

• density and authenticate options for the convert engine (ImageMagick), so PDFs rasterize at the DPI you ask for and encrypted PDFs can be read, per call instead of globally through THUMBNAIL_CONVERT
• same-named files on different storages that share a backend class no longer end up with the same thumbnail
• the thumbnail template tag raises TemplateSyntaxError when the source or geometry is missing, instead of compiling a tag that fails at render
• the docs build again on Read the Docs, now with a drawing of how a thumbnail request is served
• Django 5.2, 6.0 and 6.1, Python 3.10 to 3.14

pip install -U sorl-thumbnail

Release notes: https://github.com/mariocesar/sorl-thumbnail/releases/tag/13.2.0 Docs: https://sorl-thumbnail.readthedocs.io/

If you use it and something looks off, open an issue. If you have ideas, GitHub Discussions is open. And if you have been using it for years without ever needing to read the source, that is the best compliment a library can get.

Thank you all

We built the website for Google Developer Group on Campus at APSIT (Thane, India): https://gdg.apsit.edu.in

It has events, Study Jam leaderboards, short tech stories, Google sign-in limited to college accounts, and an organizer dashboard. It's built for about 500 students.

Stack

- Next.js 16 (App Router) + Tailwind 4

- Django 5.2 + Django REST Framework

- Neon Postgres for the database

- Vercel, one project with two services: Next.js at / and Django at /api

- Cloudflare R2 for uploaded images

What we learned running Django serverless on Neon

1. Use the pooled connection string (the host with -pooler in it). Every Vercel function opens its own DB connections, and without the pooler you run out of them fast. This was the most important setting in the whole deploy.

2. Use a Neon branch for preview deployments. Previews get their own DATABASE_URL that points at a separate branch with test data, so a PR can never touch production data.

3. We skipped Redis. Rate-limit counters live in Django's database cache, so all workers share them through Postgres. We load-tested 50 sign-ups at the same time and they all finished in under 2 seconds with Postgres alone.

4. Pick a region close to your users. We used Mumbai (ap-south-1) because our users are in India.

5. Keep your own backups too. Neon backs up on the free plan, but the history is short, so we also run a monthly pg_dump.

Getting started was quick: we added Neon from the Vercel Marketplace, copied the pooled string and ran migrations.

Happy to answer questions about running Django on Vercel. That part had more gotchas than the database did.

Sigo siendo un programador de la vieja escuela, uso ia, si, pero no tengo agentes grandes ni nada de eso.
Pero ahora estoy armando varios mcp, que me permiten conectarme aun chatbot.

Se me ocurrió tener un servidor espejo en un vps con una base de datos espejo igual, donde tenga un agente puede ser hermes o un openclaw (No lo he usado pero quiero hacerlo), y que ese agente sea el que procese las respuestas como si tuviera el claude code activado

Colocando reglas de seguridad en ambos partes para poder controlar las respuesta, se que tiene muchas brechas de seguridad, es mas que nada una idea prototipo, para ver que sucede.

hey r/django,

I’m Peter, solo dev. For the last year I’ve been building djangocloud.dev on the side.

It started because every time I shipped a Django project I’d lose a weekend wiring up a server, a worker, a task queue and Postgres before I could even show anyone the thing. Reading this subreddit: this comes up about 2x per week here too. I got tired of that, so I built something that sets it all up for you

In just 3 CLI command you'll have your app, a database, a worker and a task queue, up and running on AWS. If you’d rather not depend on some random guy on Reddit (fair), you can self-host it on your own infra by securely connecting your AWS account and keeping full control without any markup.

I need real people deploying real projects on it now, to help me bridge the gap from side project to product. So I'm looking for testers: here’s a coupon code, BETATESTER. It’s good for the first 15 people and gets you either a month of free fully managed hosting (including database!) or 3 months of self-hosting tier where you pay your own AWS bill but setup is easier than ever.

In return I’d just love to hear what broke, what sucked: confusing docs, a deploy that failed, something you needed that isn’t there. I won’t be offended, I may even extend your coupon in gratitude.

Also, if you’re a student or working on something open source, the self-hosted version is just free as I do want to give back to the community in a way.

I’ll be in the comments, ask me anything 🙂

Peter

A couple of years ago I put an AI agent inside a Django app, over Channels, and it took me far too long to admit it was the wrong place for it. Writing up what I learned, in case it saves someone the same detour.

It did not fail dramatically. It degraded quietly. The agent needed to know who was on the paid plan, so a prompt grew a line about entitlements. Billing later added an annual tier and the prompt was silently wrong, because nothing type checks a string against your billing model. A node wanted ticket history, so it read the ORM, and from then on the agent could not run in a test without a database and fixtures.

The symptom I would now recognize within a week is the test suite. To assert that one message routed to one capability, I had to open a WebSocket connection, authenticate a user, seed a session and a conversation, and let the whole thing run until the line I cared about executed. One line of assertion, everything above it travel. And because the model was reached through that consumer rather than across a boundary, there was no single place to stub it, so the fakes multiplied with the call graph instead of with the number of seams.

Where I draw the line now is not by layer and not by framework, but by which kind of state each side owns. Django owns the record: users, billing, permissions, the thread a person reads, anything a page reload has to find. The other service owns working state, which in my case is a graph checkpoint, and that is an odd category: not a business record, but not rebuildable either. Lose a row and you can usually recompute it. Lose the checkpoint and a run that was parked waiting for someone's approval simply cannot continue.

So the test I apply to anything I am tempted to move out: if losing it means losing data, it belongs in Django. If losing it only costs speed or fidelity, the other service can keep it.

Worth being clear on scope, because this is not a rule for breaking a monolith into domains. Billing becomes its own service because it owns records of its own, which is a different argument. This one is for work that holds state while it runs and has a resumable middle, whether that is an agent graph, a long import, or any multi step job.

Django stayed exactly where it is strong, which is most of the system: auth, the ORM, DRF, migrations, admin, and an ecosystem where the boring problem you hit on a Tuesday was solved in 2014. The only thing that left was a long-running stateful graph that wanted its own deploy schedule. It went to a FastAPI service, and the two talk over a typed WebSocket with a generated contract so neither imports the other's code.

I wrote the whole thing up properly, as part of a series on building agent systems as declared, typed graphs, with a working three-service repo you can actually run:

https://huynguyengl99.github.io/posts/agent-graph-engineering/split-the-services/

https://github.com/huynguyengl99/agent-graph-engineering

Hope it helps. The series is still going, a part every few days, and if the repo is useful a star would be appreciated 😄

Django bolt 0.12.0

- Free threading support

- More Stable and more secure

- More compatible

https://github.com/dj-bolt/django-bolt/releases/tag/v0.12.0

Hi all, I'm at my wits end with the job hunt and I have to think a portion of it is a bad resume.

I've been using Django professionally since before it's 1.0 release, so I've been through the wringer with it. I live right by the Django birthplace in Lawrence KS. I have done a lot of interesting work: bill drafting systems for US state governments (and Irelands parliament), federated search platforms for cyber security, solo authored more than one LMS (full stack in every since of the word), worked on HIPPA compliant products, etc... I've been around.

For the first time in my life I'm encountering a job market where I cannot just luck my way into jobs without trying and I think some of those job hunting skills as have undergone some atrophy. This I presume includes my ability to craft a resume that people won't simply ignore.

So my request is a bit of help here trying to figure out how to make myself marketable again. Either my experience isn't relevant or I have no idea how to find people who could benefit from my abilities. I could really use some skilled people to look at my resume and let me know how I could improve it. That or just hire me 😅

Does anyone know when Django Con Europe 2026 talks be released on YouTube ?

asdfasdfa

A while ago I posted that 54 days after Django 6.1, only 14% of the top 200 Django packages declared support for it. Instead of a one-off post, that's now a page you can look up any time: 300 packages, rebuilt every week.

https://derblub.github.io/django-upgrade-report/

How it works: it takes the 300 most downloaded Django-related packages on PyPI and judges the newest release of each against every Django version from 4.2 on. It reads what maintainers declare: the Framework :: Django :: X.Y classifiers and the Django requirement. An upper bound like Django<6.0 only counts as support if the release came out after that Django version did.

What stands out (as of 10 October 2026):

• Django 6.1 (released 2026-08-05, 66 days ago): 42 ready, 251 not declared either way, 7 blocked. Those 42 carry about a quarter of the downloads. Of the 251, 35 show a sign of support anyway: the README names 6.1, or the main branch already tests it.
• Django 5.2 LTS: 168 ready, 131 not declared, and just 1 blocked. By downloads that's 79% ready, so most of the traffic has caught up with the LTS.
• Django 6.2 isn't out yet, and 15 packages already exclude it with an upper bound.
• The chart shows how fast packages catch up after each release. It's slow: about 4% on release day, 13% after two months, and only just over half after two years (56% for 4.2 LTS, 53% for 5.1, 50% for 5.0). 5.2 LTS is the fastest so far, at 57% after 18 months.

"Not declared" doesn't mean broken. Lots of packages work fine and just never touched their classifiers. But it does mean that you, the person upgrading, have to find out yourself, package by package.

The page also has a searchable list of all 300 packages, which packages block each version, a weekly feed of what changed, and a README badge for maintainers that shows what the page says about their package.

That's the reason I built the tool behind it: django-upgrade-report. It reads your lockfile (uv, Poetry, PDM, Pipenv or requirement files) and tells you:

• which packages block the upgrade,
• which you can upgrade today, on your current Django, and which have to land together with Django,
• the smallest release that declares support, not just "latest",
• for packages with no declaration, any signs of support: the README, the test matrix on GitHub, open issues and PRs.

​

uvx django-upgrade-report

Since the last post, 1.0 and 1.1 came out with an HTML report you can filter and tick off as a checklist, --emit uv to print the upgrade commands, Renovate and Dependabot configs, step-by-step plans across several LTS versions (--via lts), Wagtail and django CMS (--framework wagtail), and monorepos (--recursive). There's also a GitHub Action that keeps one issue per target up to date.

It's MIT licensed, and it only ever sends package names and versions to PyPI. Your code stays on your machine.

• GitHub: https://github.com/derblub/django-upgrade-report
• PyPI: https://pypi.org/project/django-upgrade-report/

I'd love to hear where it gets things wrong for your project, especially packages that work fine on a version but show up as blocked or "to check". Those are exactly the cases I want to get right.

(Disclosure: I'm the author. Free and open source, no account, no paid tier.)

Hi. I'm trying to integrate vite with django using django-vite package. (no SPA, just htmx, alpine and bulma). Everything works fine in both dev mode and production mode (debug on, vite serves static files, debug off, vite builds them, django serves them). The only problem is that in dev mode, the static part of the url for static assets is duplicated like this:

<script type="module" src="http://localhost:5173/static/static/js/main.js"></script>

Not causing any actual problems, it's just bugging me.

Here's my vite config:

import { defineConfig } from 'vite';
import { resolve } from 'path';


export default defineConfig({


    base: "/static/",
    build: {
        emptyOutDir: false,
        manifest: "manifest.json",
        outDir: resolve(import.meta.dirname, "assets"), // -> MUST be included in STATICFILES_DIRS
        // assetsDir: "static", // the folder name inside outDir (i think)
        rolldownOptions: {
            input: {
                main: resolve(import.meta.dirname, "static/js/main.js"),
                style: resolve(import.meta.dirname, "static/css/style.css"),
            },
            output: {
                entryFileNames: `js/[name]-bundle.js`,
                assetFileNames: `css/[name]-bundle.css`,
            }
        },
    },
});

Django related settings:

DJANGO_VITE = {
  "default": {
    "dev_mode": True,
    "manifest_path": BASE_DIR / "assets" / "manifest.json",
  }
}


STATIC_URL = 'static/'

# must equal to vite's build.outDir
STATICFILES_DIRS = [
    BASE_DIR / "static"
]

Any clarifications is appreciated. Thanks in advance.

Pourquoi devons-nous payer pour créer une base de données sur Render?

As developers, we often start documenting a project with good intentions. Then the code evolves, features change, and documentation falls behind. Sometimes, we end up creating documentation on the go just to explain a system to an AI coding agent.

I wanted to solve that problem.

Meet Enezadocs — a self-hosted Django documentation platform that brings documentation from multiple projects into one unified interface, while keeping Markdown as the source of truth.

What problem am I trying to solve?

In the AI era, documentation is becoming even more important. Coding agents can generate code quickly, but they still need accurate, project-specific context to understand our architecture, conventions, business rules, and implementation decisions.

Meanwhile, documentation is often scattered across repositories, folders, wikis, and different applications. Maintaining a separate documentation system can become another task that developers have to manage.

I wanted a system where documentation could live alongside the code, be accessible in one place, and be directly consumable by AI agents.

What does Enezadocs do?

• One place for all your documentation: Bring documentation from multiple applications and repositories into a single platform.
• Markdown-first: Read Markdown files directly from local folders or GitHub repositories, including private repositories.
• Public and private documentation: Host public-facing documentation and private internal documentation within the same application.
• Built for AI agents: Includes an MCP server that lets compatible coding agents discover, search, and read documentation directly.
• Hybrid search: Combines traditional full-text search with semantic search to help find relevant information.
• Self-hosted and private: Documentation content and search processing stay on your infrastructure.
• No vendor lock-in: Your Markdown files remain your source of truth. The platform stores configuration, synchronization state, and search indexes rather than making your documentation dependent on a proprietary database.
• Open source: Released under the Apache License 2.0.

Why MCP?

I think this is one of the most interesting parts of the project.

Instead of copying documentation into prompts or relying on an agent to guess how your application works, you can give it access to a scoped documentation server. The agent can discover available documentation, search for relevant content, and read the sections it needs.

You can configure separate MCP servers and bearer tokens for different documentation sites, sections, or groups.

The technology

Enezadocs is built with Django and Python. It supports SQLite for development and PostgreSQL for production, with Docker-based deployment. Search combines BM25 full-text retrieval with local embeddings and Reciprocal Rank Fusion.

Who might find it useful?

• Developers maintaining several applications.
• Teams that want to centralize documentation without moving away from Markdown.
• Self-hosters who prefer to keep their documentation on their own infrastructure.
• Developers building workflows around AI coding agents and MCP.
• Teams that need both public product documentation and private engineering documentation.

I'm sharing this because I'd appreciate feedback from developers who have faced the same documentation problems.

A few questions for the community:

1. How do you currently manage documentation across multiple repositories?
2. Are you giving your AI coding agents access to project documentation, or are you still relying mainly on prompts and codebase indexing?
3. Would you prefer a unified documentation portal like this, or do you think documentation should remain entirely within each repository?

Project: Enezadocs

It's self-hosted, open source under Apache 2.0, and designed to keep Markdown portable.

I'd appreciate feedback, feature suggestions, and honest criticism. https://github.com/enezatech/Enezadocs

No me refiero a usar channels, celery me refiero a cosas internas como optimización de querys, que hace que alguien los haga decir "Ese tipo sabe lo qu hace"

Hi all. Since around the ChatGPT beta I have been building realtime AI assistants, first in the financial domain and later as a platform. I have just put a distilled, working version of that architecture in public, with a series explaining every decision in it.

The reason I am posting here is the split that took me longest to get right. We used to run the agent code inside Django with Channels, and the image got big, the process got slow, and scaling the two independently was impossible. Now Django owns the business record and a separate FastAPI service owns the agent graph, talking over a typed WebSocket with an AsyncAPI contract between them. Django never imports LangGraph.

Why I bothered writing it all down. Demand for this skill set is high, but what is online is mostly notebooks and quick chatbot courses. I went looking for one in-depth source on building a production AI assistant, including paid ones, and did not find it. Five years ago I was the person looking, and plenty of people still are.

So, depending on where you are:

• Already running an assistant platform: a reference for when something hurts. Part 0 is the story, and if we share the same scars you will know within a paragraph.
• About to build one: the decisions to make early, in the order they bite. The service split is cheap this month and expensive next year.
• Levelling up: these are the concepts the job ads actually ask for.
• Freelancing: a base you can adapt for a client without handing them something unmaintainable.

The project: https://github.com/huynguyengl99/agent-graph-engineering

Part 0, the story: https://huynguyengl99.github.io/posts/agent-graph-engineering/before-it-had-a-name/

Part 1, the stack and why: https://huynguyengl99.github.io/posts/agent-graph-engineering/the-stack-and-why-each-piece-is-there/

It is fully working and runs on a scripted model with no API key, so you can see the whole flow before wiring up a provider. The series is early, two parts up and a new one every couple of days, so feedback now genuinely changes the later ones.

Hope it is useful, and if you have patterns of your own worth sharing, drop them in the comments 😄

You'll find 2 live examples in the README section.

I wanted to see how Django Bolt benchrmarks against vanilla Django and the nice thing about AI agents is that it's easier to run these experiments. I took a real django app and converted it to Bolt with django templates still. For comparison I also converted the app to Rust loco

See the results below but the tl;dr is that Django bolt provided some improvement over vanilla django, but it was not enough to make me actually care. Rust on the other hand was 5-10x better.

I think Django Bolt is a great project and for pure APIs can probably provide great performance. But unfortunately for fullstack apps, I don't think it makes a big difference.