My wife and I were hiking through the scenic hills of Belgium when I received a concerning email from Amazon Web Services (AWS). The email, titled "Amazon SES Complaint Review Period for AWS Account []", contained the following warning:

Your current complaint rate is 0.5%. We measured this rate over the last 10,351 eligible emails you sent. We recommend that you maintain a complaint rate below 0.1%. If your complaint rate exceeds 0.5%, we might pause your ability to send additional email.

I use AWS Simple Email Service (SES) to send emails for my nonprofit organization, and this warning came as a shock. It indicated that recipients had flagged emails from my system as spam. This was unexpected because I only send emails to individuals who actively subscribe to the service. I never send unsolicited messages.

I run a small nonprofit, TheLifeSigns, which helps people living alone stay safe. Through my website, users can sign up with their email address and provide the email addresses of their chosen "buddies," such as friends or family members. The service sends daily emails with a “lifesign” button. If the user clicks the button, nothing happens. However, if they fail to respond, the system automatically alerts their designated buddies. This means that losing email-sending capabilities could have life-threatening consequences for my users.

When I returned home, I immediately began investigating the complaints. My first step was to identify who was flagging my emails as spam and why. I downloaded the complaints list from AWS and cross-referenced it with my user database. My database contains both the email addresses and the IP addresses of users' Internet Service Providers (ISPs) at the time of sign-up. Using a GeoIP database, I was able to determine the geographical locations of users who had signed up.

By combining these datasets, I pinpointed the origin of the complaints. It quickly became apparent that the majority of complaints were coming from Russia.

This discovery raised further questions about the motivations behind these complaints and how they might be mitigated to ensure uninterrupted service for my users.

I had previously noticed that many Russian users signed up for the service but never logged in. Since they didn’t appear to cause any issues, I chose to ignore them. However, this changed in late 2024. Suddenly, a majority of these users began marking email confirmation messages as spam. By December 2024, their behavior became more aggressive, with the complaint rate more than tripling compared to the previous month. This surge in complaints severely impacted my email-sending reputation, leading AWS to threaten the suspension of my email-sending capabilities.

To better understand these attackers, I analyzed the email providers they were using. Interestingly, they almost never used Russian email providers. Instead, the overwhelming majority of them relied on American email services, with Gmail being the most popular by a significant margin.

For this analysis, I examined data from all 1,500 Russian users who had signed up for the service, but were not using it.

By leveraging the GeoIP database, I was also able to approximate the location of the hacker:

While uncovering all this information was insightful, it didn’t immediately solve my problem. AWS suggested implementing a CAPTCHA to make it harder for bots to sign up. I followed their advice, and it did reduce the number of sign-ups from Russia. However, to my surprise, the complaints continued.

These remaining complaints weren’t tied to sign-ups because I couldn’t find the email addresses in my user database. Digging deeper into my system logs, I noticed a large number of "Reset Password" requests. After further investigation, I discovered a bug in my password reset process. If someone entered an email address—whether or not it was associated with an actual account—a password reset email would still be sent. Hackers exploited this flaw, triggering these emails and then flagging them as spam.

Although this bug didn’t pose a security risk—the process would fail later if the email wasn’t linked to a valid account—it did inflate my spam complaint rate. I’ve since fixed the issue by ensuring the system first checks whether an account exists before sending a password reset email.

AWS was satisfied with the actions taken, reset the complaint counter, and concluded the review.

The bigger question remains: why are these Russian hackers putting so much effort into undermining email-sending reputations, particularly for a small nonprofit like mine? My organization exists solely to help people living alone stay safe and currently even has no commercial goals. It seems likely that they’re targeting a wide range of Western organizations with similar attacks.

We often hear that hybrid warfare has become a cornerstone of Moscow’s strategy toward the West. I never imagined my small nonprofit would become a part of this conflict. At least for now, it seems I’ve successfully repelled this attack. But I can only wait and see what they’ll try next.

https://www.thelifesigns.com/

Umm, yes. Yes, I did.

Hey everyone! 👋 I've been using Django for about a year now, and lately I've been starting a lot of new projects for prototypes and simple tools. As someone still relatively new to Django, honestly... the initial setup was killing my motivation every single time. You know the drill:

Create virtual environment

Activate it

Install Django and dependencies

Start the project

Create apps

Set up templates and static folders

Configure settings.py

And so on...

By the time I finished all that, I'd already lost some enthusiasm for the actual development. So last week I decided to do something about it and built Django Project Assistant - a desktop tool that does all this boring setup stuff in under 30 seconds. I know I'm not the most experienced Django dev out there, but this has been a game-changer for my workflow! What it does:

✅ Complete automation: Creates venv with UV (fast!), installs packages, sets up Django project structure

✅ Python version control: Uses UV so you can easily choose which Python version to use

✅ Lightning fast installs: UV makes package installation much faster than traditional pip

✅ Smart configuration: Automatically configures settings.py with your selected packages

✅ Template management: Creates template/static folders and lets you add custom project templates

✅ Fully customizable packages: The Django packages and libraries shown are just examples - you can add whatever you need

✅ Frontend integration: Support for CSS frameworks and JS libraries (examples: Bulma, HTMX, FontAwesome)

✅ Saves preferences: Remembers your last configuration so you don't have to reselect everything

✅ Custom user model: Option to set up custom user model from the start The tool uses a JSON config file that's highly customizable - you can add your own Django packages, frontend libraries, and even custom project templates to fit your exact workflow.

Current state: It's working great for my needs (Windows, Python 3.13), but there are still some things to polish: UI improvements Cross-platform compatibility (currently Windows-focused) Better documentation More thorough testing

The question: Before I spend time making it production-ready and cross-platform, I wanted to ask: Would this be useful for you too? I'm thinking of open-sourcing it if there's interest. Let me know: Do you face the same "setup fatigue" problem? What OS do you use for Django development? Any features you'd love to see?

Thanks for reading! Any feedback is appreciated 🙏

P.S.: Yes, I know about cookiecutter-django, but I wanted something with a GUI that I could customize exactly to my workflow

🔔 Update: Thanks to all the interest, I’ve just released the first version of the software on GitHub. If you’d like to give it a try, here’s the repo: https://github.com/lupon1/Django-Project-Assistant

Any feedback are welcome.

In a general push for removing Microsoft, Google and any US or other non-EU dependency, the French government has been rapidly creating an open source set of productivity tools called "LaSuite", in collaboration with the Netherlands & Germany.

The suite already includes alternatives for Docs, Meet, Slack, WeTransfer, Gmail/Outlook and Drive.

The github repo :
https://github.com/suitenumerique

And the presentation website :
https://lasuite.numerique.gouv.fr/

Considering the massive ambitions of these projects, they chose Django, which I am very happy about.

It was quite long journey.. it took about a year and a half to build and no sales for 4months.. I was quite depressed..

I figured out what to fix and my site started to make sales and now I make $100~$200 in revenue everyday. It is not that big amount but I can do this for living and I know how to scale up

I feel really thanks to django foundation.. If I chose nodejs or something else I wouldnt build a service for living in that short period of time..

I have been developing applications for almost 10 years. For most of those years, I've done it primarily to make money for other people. Yes, I get paid for being their developer, but mainly I'm building their product. This made me happy. I have always enjoyed diving into cool programming languages and solving complex business problems. But it was always for other people.

I have recently developed a pretty popular product for a niche market. Not a project, but a product. When it comes to making money, optimizing for time, and focusing on things that matter, Django is the framework for me. Don't get me wrong - FastAPI and Flask are cool. I like having a lot of control over my app. But I also like building a feature in a few hours then going fishing - knowing that the customer really doesn't care what it was built with. I know that my code will just work. I know that I can find a module to help with my features, and just plug it in. I like knowing that I can create chron jobs that will run on my celery queue with minimal config. I like being able to throw my app up onto a box and it just works. Most other Frameworks are mentally taxing and don't have enough rules for me. And therefore, it's easy for me, to get bogged down into things like best practices, code structure, cute 3rd party modules, and 1,000 other things that are fun, but really just a distraction.

When I was a young buck, I liked configuring my text editors and optimizing sql queries to the micro-nano-milli-jilli-second. I thought it was fun to learn the latest and greatest technologies, and debate the latest flavor of nosql. But now, in my old age (30), I have a really strong desire to make the most amount of money I can, but by exerting the least amount of effort. I still enjoy the challenge of solving complex problems and diving deep into the weeds of business logic - I am, indeed, a developer. But Django is the framework that lives up to its tagline - the framework for perfectionist with deadlines.

Django has helped me do the 1 thing I've never been able to with any other framework - make money with a product I own.

Cost of tinkering around with web microframeworks on Digital Ocean for 4 years... $5/month.

MRR of a product I built in 14 days with Django.. $6,000 (and growing).

Knowing that Django can do it again with my next big idea... Priceless.

Thank you Django. I stayed away from you because I thought I wanted tinkering, atomic control, "requests per second" (whatever that means) and the next shiny thing. But you knew what I really wanted - the ability to build scalable webapps quickly.

And that, is why I use Django.

Happy Birthday Django. You are 15 years old today. 🤩🥰. Proud to be Django developer and trainer.

Hey everyone,

I recently submitted my first contribution to Django and it got merged. Pretty exciting since Django is such a widely used framework.

The issue was related to ASGI request handling. In ASGIRequest.__init__, Django was using str.removeprefix() to strip the script_name from the request path to compute path_info.

The problem is that removeprefix() is just a raw string operation and doesn’t check path boundaries.

Example:

script_name = "/myapp"
path = "/myapplication/page"

Previously this could produce:

path_info = "lication/page"

because /myapp was removed even though it wasn't a proper path prefix.

The fix ensures the prefix is only removed when it’s actually a valid path segment boundary.

Ticket: https://code.djangoproject.com/ticket/36940
PR: https://github.com/django/django/pull/20749

The Django maintainers were super helpful during the process. Definitely recommend trying to contribute if you're interested in Django internals or open source.

Happy to answer questions about the process if anyone is curious!

Hey everyone,

I just wanted to thank you all for your support. I’ve been learning Django for 306 days this year and gained skills in:

Python

Django , Django REST Framework

MySQL, Redis, Celery

Git , GitHub Docker Html, little bit css😅 JavaScript

Django Channels & WebSockets

I’ve completed projects like: E-commerce site Social network Chat app Task management Survey project

I’m a self-taught developer, and although I’ve failed three interviews, I’m still motivated to keep learning and improving. I’m now learning DSA but haven’t progressed much beyond binary trees and linear structures. Any suggestions on what I should focus on next?

Thanks again, everyone!

Previously, implementing composite primary keys in Django required some workarounds, such as:​

Using third-party packages like django-composite-foreignkey.​

Employing the Meta.unique_together option, which enforced uniqueness without treating the fields as a true primary key.

Writing custom SQL, thereby breaking ORM abstraction for composite key queries.​

Now with Django 5.2, CompositePrimaryKey creates a genuine composite primary key, ensuring that the combination of product and order is unique and serves as the primary key.

There is no need to import the models in the shell. Instead Django will do it for us.

Previously, when using the Django shell, we had to manually import models, but Now, Django automatically imports models when you enter the shell, so we can start using them right away!

this was a part of shell_plus inside Django extensions package

Unfold is a theme for the Django admin interface that incorporates best practices for building full-fledged admin areas. It is designed to enhance and extend the default administration features provided by Django.

Features :-

• Highly Customizable • Polished Look • Dark Mode: Supports both light and dark mode versions. • Responsive Design

We wanted to post earlier why we like/use Django, but, we get pretty busy around here, so a bit late. Sorry if this is duping any existing threads.

Why

This is not a Drupal vs Django fight, we're not here to slag Drupal, Drupal has been important to The Onion, but The Onion decided to stop using Drupal a long time ago. The Onion deployed a Drupal site back in 2005, at the time it was the right decision given the resources, yet even then we were interested in using Python whenever possible. We feel it is a vastly better designed language than PHP and of course any framework you're using is only as good as the language. We started rolling out other projects, like The A.V. Club, in Django. Just this past weekend we switched over The Onion proper, and we're seeing immediate gains in speed, maintainability, and stability. As a team we have a pretty broad base of experience and I know we're all in agreement that what we've got now is better, enormously better. We're not just using Django, we have some other pieces that made our lives easier: git, PostgreSQL, VPS's. So this isn't just about The Onion using Django (and recommending it), but generally that you can make things better by investing time and energy into new technology.

How

It took us about 3 months to convert our old Onion site to Django while we also maintained and built on our other sites. We already had some components written for A.V. Club, including a strong article and image model, so we felt we could concentrate on coming up with good models that covered the necessary editorial cases. The hard part was more how to fit pieces of content from ten years ago consistently and cleanly than it was writing the code to make use of the final model. We broke out templates into nicely reusable components and made use of the Django template hierarchy. Multi-db made the conversion of data from a MySQL db to the PostgreSQL db fairly easy, so we could rerun importing old data into the new system and fix and tweak. There is an enormous advantage using Django, sorl and PIL for creating image crops based on templatetags which gives the editorial and design folk flexibility they need (no more css cropping odd-sized images into place). Again, lots of work went into actually cleaning a site that goes back to 1996, Django allowing for a relatively minimal amount of coding -- particularly when it comes to the admin side for content entry, Django trunk we found almost ready to go as-is (something we did not find with previous Django). That we could use the Django admin rather than create custom entry forms I think saved us 2 months work.

Because

Cleaner. Much cleaner. Proper unit testing. Real reusable components across applications. An ORM rather than a just a series of functional query helpers. Tighter conventions (q: how often do people using Python argue about bracing styles? a: they don't). We can update then test a Django core change without worrying about having to take apart our applications, and if we do need to make a change, it's easy to do because there's less, much more readable code. Every member of the tech team can meaningfully contribute because there are fewer specialized or hacked together pieces. We can move more quickly on large changes because of all these reasons. And we're more stable because of all the previously expressed points.

-- The Onion Tech Team

It looks like FastAPI will soon overtake Django in GitHub stars, and honestly, that makes me a little sad. Django has been the backbone of so many great projects for years, and seeing it get dethroned—at least in terms of stars—feels bittersweet.

Of course, stars don’t define a framework’s true value, and Django is still the GOAT in my eyes. It’s battle-tested, powerful, and continues to evolve. But I can’t deny that FastAPI’s rise is impressive and shows how much developers appreciate async and modern Python features.

What do you guys think? Do GitHub stars actually matter, or is this just a popularity contest?