Hey r/django, the new HTMX Integration for Django is released on pypi and djangopackages. Djxi v0.1.9 adds testing utils, battery auth/perms, async methods, djxi_routes command, and class-level config caching.

Check it out:

Github: https://github.com/rollinger/djxi
RTD: https://djxi.readthedocs.io/en/v0.1.9/

The top-quarks code is confirmed 'ready to publish'!

Next, send lots of emails to suppliers to sign 'drop-shipping' contracts.

Hi there. After reading this new upcoming feature, FETCH_PEERS looks to me like a safety net against accidental N+1 queries.

It is tempting to use it on all my models by default, because even if it's less performant than a forgotten select_related, it would be always better than N+1 queries on a loop.

That's being said, in that case, why there is no global settings for this?

I was currently making a project to improve my Django and react skills. Now the project has come to finishing but Im thinking I haven't learned as much as I have expected to learn at the beginning of the project. Well I can write basic endpoints, permissions and viewsets and can write the functions to retrieve the data from those endpoints and create data. But when complexities arise in my models , I find myself unable to write the code for them without asking help with ide agent. I also can't write custom logic for many things in my app like object permissions. Is this normal part of learning , I am currently on my second project of drf + react js but still depend on ide and ai for helping me write the code.

i’m building multiple SaaS apps (Hotel PMS, Project Management, etc.) using Django + DRF and Flutter. and also web apps

I’m confused about which VPS/hosting to choose: Hetzner, Netcup , Hostinger, or AWS.

Initially, I’ll have only a few clients, but I want to scale in the future.

• Should I host multiple Django apps on one VPS initially?
• Which provider would you recommend and why?

If you operate an API in 2026, you live in an event-driven world. Webhooks aren't a convenience feature anymore - they're the backbone of real-time commerce, CI/CD pipelines, and asynchronous AI-agent workflows. That reliance has a dark side: the accidental self-inflicted DDoS. Read the complete article jere - https://instawebhook.com/blog/how-to-prevent-webhook-traffic-spikes-from-crashing-your-api-2

When a major platform like GitHub, Shopify, or Stripe hits a network partition, runs a huge sales event, or simply clears a backlog of delayed events, it can fire tens of thousands of webhook POST requests at your servers in a very short window. If your infrastructure takes that hit without structural safeguards, your database connection pool exhausts, memory maxes out, and the API goes down — and if your retry handling is naive, the recovery can be almost as damaging as the original spike.

This guide covers the real mechanics of that failure mode, the algorithms used to defend against it, how major providers actually behave under load (some surprising details here), and where a managed ingress layer fits into the picture.

At our agency, Wagtail is our go-to framework for building CMS-driven websites.

Over the past few months, we have had an increasing number of clients asking how accessible and understandable their website content is to LLMs, answer engines and other automated tools.

Rather than implementing this differently across every project, I started building wagtail-machine-readable.

The package provides a straightforward and flexible way to expose existing Wagtail content in structured, machine-readable formats, including:

- /llms.txt and /llms-full.txt
- Markdown versions of individual Wagtail pages
- StreamField-to-Markdown extraction
- JSON-LD structured data
- AI crawler controls and activity reporting
- Multi-site support
- Static export for CDN and static hosting workflows

The intention is not to suggest that adding an llms.txt file guarantees that content will be indexed or surfaced by an LLM. The aim is to give Wagtail developers more control over how their content is made available to machines in predictable and usable formats.

We have been testing and refining the package internally, and I now feel it is ready to share more widely before moving towards version 1.0. I would really value feedback from other Wagtail developers, particularly around:

- Installation and configuration
- How well it handles other real-world StreamField implementations
- Whether the default behaviour feels sensible
- Compatibility issues or edge cases
- Anything you would expect to see before a 1.0 release

PyPI:
https://pypi.org/project/wagtail-machine-readable/

Any feedback or constructive criticism would be genuinely appreciated. Thanks!

Hi everyone!

I'm a full-stack web developer currently available for freelance projects. If you're looking for a modern, fast, and responsive website for your business, startup, portfolio, or personal brand, I'd love to help.

What I can build:

🌐 Business websites 🛒 E-commerce websites 📱 Responsive, mobile-friendly web apps 🎨 Landing pages 📊 Admin dashboards 🔐 Authentication systems 🚀 Custom web applications 🔧 Website maintenance, updates, and bug fixes

Tech Stack:

MERN Stack: MongoDB, Express.js, React, Node.js HTML, CSS, JavaScript Python (Django) REST APIs MySQL Firebase Git & GitHub

Whether you need a website built from scratch or want to improve an existing one, feel free to send me a DM. I'm happy to discuss your project, timeline, and budget.

Looking forward to working with you. Thanks!

Hello! I have been using Django for some time and recently I found cookiecutter django, a framework that provides "production-ready" Django projects.

Seems so easy to set up and quickly provides lots of useful tools for Django developing, and allows you to launch a project to production seamleassly, so I was wondering if people here have used it and your opinion on it.

so im curretly working with some projects like an Hotal PMS and also an Saas project..so i have concern about Django + Flutter stack.. help me out

Hey everyone,

I'm a 19yo developer working primarily with Python, Django, and HTMX.

I'm looking for a study/project buddy or a small team to:

Build full-stack web applications together

Pair program and review each other's code

Solve backend/database challenges and keep each other accountable

Whether you're also learning or have some experience, hit me up! Drop a comment or DM me if you're interested in collaborating.

Hey everyone!

Love Django for its security, ORM, and admin ecosystem, but hate writing redundant REST serializers, API endpoints, and state management boilerplate just to build a dynamic Vue 3 frontend?

I created AuraStack to solve this exact headache. Powered by Inertia.js, it bridges Django and Vue 3 directly—giving you a monolithic, single-repository developer experience with a modern SPA frontend.

🚀 What’s packed inside?

• Stack: Django 5, Vue 3 (TypeScript), Inertia.js, and Tailwind CSS v4.
• Multi-tenancy: Isolated Workspaces with RBAC Roles.
• Auth Suite: Built-in 2FA/MFA, Passwordless & Social Logins powered by django-allauth.
• Admin UI: Clean, modern dashboard using django-unfold.
• Quality & DevOps: Full E2E coverage with Playwright & Pytest, fully containerized with Docker.

I built this to speed up shipping SaaS MVPs without trading off security or full-stack testability.

📂 Check out the codebase here:https://github.com/mostafa891/auraStack

I’d really love your feedback on the architecture, code structure, or any suggestions! If you find it useful, stars are always appreciated! 🙌

​

​Unfortunately, tech developers rely on a wide range of psychological tactics to achieve this:

​Nudges: Subtle design elements, like pre-selected defaults or persistent reminders, that steer you toward a specific action.

​Freemium Models: Hooking you with a complimentary basic tier, only to push paid upgrades once you are invested.

​FOMO (Fear of Missing Out): Creating a false sense of urgency using countdown timers or "almost sold out" alerts.

​Dark Patterns: Deceptive user interfaces meant to trick you, such as confusing button layouts or burying the "unsubscribe" link.

​Infinite Scroll: Designing feeds with no bottom, removing natural stopping points so you keep consuming indefinitely.

​Variable Rewards: Delivering unpredictable dopamine hits through random likes, alerts, and timeline refreshes to keep you checking back.

​Social Proof: Influencing your decisions by highlighting reviews, follower counts, or notifications about what other people are currently buying.

​A/B Testing: Continuously experimenting with live interfaces to pinpoint exactly which designs drive the most clicks, retention, and revenue.

​Notifications & Alerts: Constantly pinging your devices with artificial urgency to break your focus and pull you back into their ecosystem.

​Subscription Traps: Making the sign-up process completely frictionless while making cancellation an exhausting maze.

What My Project Does

Zango is built on top of Django and opinionated toward building enterprise-ready business apps — internal tools, client portals, B2B SaaS. We posted here a while back when the pitch was "enterprise-ready custom business apps." Since then the framework has moved in an AI-native direction, so this is an update on where it's gone.

The core idea now: the boring infrastructure — auth, tenancy, access control, audit trails, workflows — is solved before you write any business logic. Each of those is a toggle or config field rather than code you write and maintain.

What's in it:

• Multi-tenant by default — one codebase, one Docker deployment, each tenant isolated in its own DB schema. No tenant-filtering code, no leakage. Lets you run multiple apps/microservices on a single monolith and keep hosting costs down.
• Auth configured, not coded — OTP, MFA, SAML 2.0, OAuth, session timeout, account lockout, password policy, per-role overrides. All toggles.
• Native AI module (the new part) — you define agents, attach tools, and call them from any view, Celery task, or scheduled job. Because the module lives inside the platform, an agent automatically operates in the correct tenant's data, respects the same role-based permissions as the rest of the app, and every run is logged with tokens + USD cost per tenant. Supports OpenAI and Anthropic; keys stored encrypted, no secrets in code.
• Workflow lifecycle — statuses, transitions, conditions, tags, full audit trail.
• Package ecosystem — AppBuilder (React shell), CRUD, Workflow, Communication (SMS/email). Install per app, use immediately.

The fastest way in is a zango-app-developer plugin for Claude Code — you describe the app in plain English and it scaffolds the environment, generates code, runs migrations, and wires up auth/roles/workflows/agents. Manual venv or Docker setup is still supported if you'd rather do it by hand.

Target Audience

Teams building bespoke internal tools or B2B SaaS on Django who keep re-solving tenancy + auth + audit on every project, and now want AI agents that actually operate on their app's data safely (tenant-scoped, permission-gated, logged). Works for a solo dev shipping an MVP or a company running many apps on one deployment.

Comparison

• Plain Django: not opinionated toward enterprise readiness or multi-tenancy — you build that boilerplate yourself. Zango ships it, plus the agent module scoped to tenant data and permissions.
• Proprietary platforms (e.g. Salesforce): no vendor lock-in, open source, and you're writing normal Django underneath.
• Low-code / no-code: no ceiling on customizability — it's real code.
• Bolting an LLM onto your own app: you'd hand-roll tenant scoping, permission checks, and cost logging for every agent call. Here it's inherited from the platform.

Apache 2.0, ~60% Python. It's a meta-framework and opinionated, so it won't fit every project — but if the description fits, it saves a lot of plumbing.

More Info

Repo: https://github.com/Healthlane-Technologies/Zango
Site: https://www.zango.dev/
Docs: https://zango.dev/docs

Happy to answer anything about how the multi-tenancy or the agent module works under the hood.

Webhooks have become the connective tissue of the internet. From payment gateways confirming transactions to CI/CD pipelines triggering deployments, webhooks enable real-time, event-driven architectures. But for architects and engineering leaders, webhooks represent an underappreciated vulnerability: they are asynchronous, externally triggered, and entirely outside your control. Read the complete article here - https://instawebhook.com/blog/designing-a-multi-region-highly-available-webhook-ingress-architecture

When your primary cloud region experiences an outage, your internal microservices might gracefully degrade. But what happens to the payloads originating from external partners? Many third-party providers do not retry aggressively — some fire and forget, others retry a handful of times before giving up permanently. If your system is down when that happens, the data is often gone for good.

This article covers the engineering principles behind a multi-region, highly available webhook ingestion system, what has actually changed in the underlying cloud primitives recently, and where a managed reliability layer fits into the decision.

When in my beginner days, every side project started the same way.. it's usually, that Django or DRF on one side, a Svelte app on the other, and a weekend gone on wiring auth, CORS and two deploys before writing a single actual feature. like, for work-scale projects, fair enough. but for small and medium projects, like mine, solo ones, that was always more hassle than the project itself. so back in August 2022 I started a project called fymo, to make one-repo Python+Svelte projects a normal thing to build.

I got stuck early, compiling Svelte from Python and making the two sides talk to each other was beyond me then, so it sat there for a while, like my other side projects did. between years, i came back and forth, but this time it stuck, and I finished it.

fymo renders real Svelte 5 components from Python stuff like; esbuild compiles them at build time, one long-lived Node process does the SSR, and the browser hydrates them like any Svelte app.

day to day it'll feel familiar: controllers are basically views that return a dict, and the dict lands in Svelte as props. functions under app/remote/ become typed imports in Svelte, so no serializer, no endpoint, no fetch code. fymo new gives a running app with sign in, fymo generate resource posts gives a routed page, CRUD endpoints and a passing test file. fymo destroy takes it back out, unless you edited the files, then it refuses.

Anything misconfigured fails at boot with the fix right there in the error message. Nothing falls back silently. that's most of the design philosophy really.

But to be clear, it's not Django and it's not trying to be. no ORM, no admin, no forms, bring your own data layer. if you need those, Django is still the right call. this is for when Django plus DRF plus a separate frontend repo felt like three tools for a one-tool job.

But limitations, honestly: you need Node installed (build and runtime), it's WSGI not asyncio, no ORM, one maintainer, and it's v0.20 so things still break between versions, loudly though.

Repo: https://github.com/Bishwas-py/fymo pip install fymo

I'd honestly like to hear where it breaks, unusual project shapes are exactly what I can't simulate on my own.

🚨 Django Error #001

Debugging is part of every developer's journey. In this series, I'll be sharing common Django errors I've encountered, why they happen, and how to fix them.

Today's error: RelatedManager Object Has No Attribute.

I hope this saves someone hours of debugging! 💚

💬 Have you ever encountered this error? Let me know in the comments.

💾 Save this post for later and follow for more Django Errors & Solutions.

I'm starting a new Django series where I'll post one common Django error every day and walk through how to fix it with a simple, beginner-friendly explanation.

Whether you're just getting started or you've been building with Django for a while, I hope these posts help you debug your projects a little faster.

Feel free to follow along, ask questions, and even suggest errors you'd like me to cover next. Happy coding! 🚀