Hey everyone, I just put out version 0.2.0 of Dynimg. It's a Python/Rust package that takes in HTML/CSS and outputs high quality images. If you've ever had to deal with generating images for blog posts (for OG/preview images etc), you know the options are either to run a full headless browser, or build a complicated Pillow pipeline.

I've been making Django apps since version 0.96 (I'm old, sorry), and this is a problem I've needed a solution for many times. It's now finally possible because of another project called Blitz, which is a modular browser built in Rust.

Dynimg is a focused wrapper around parts of Blitz designed around just turning custom HTML and CSS into crisp static images. It's very fast (~20ms) compared to using a full browser to do the same thing. While there's no Django-specific integrations, it works well with Django templates using render_to_string as input.

Example Django code:

import dynimg
html = render_to_string("og.html", ctx)
dynimg.render(html).save_png("og.png")

We've been using Dynimg in production with Django at totem.org for a while now, and it's been just chugging along without issue, so I thought I'd share it here in case anyone else finds it useful.

Despite not being version 1 yet, it is largely feature complete. The main issue is Blitz is still early and there will be slight rendering differences as it matures. However, if you pin Dynimg your images stay stable.

It supports external and local assets (images, CSS, fonts, etc). It works well with Google Fonts for example. Comes with a CLI, Python API and Rust API. It supports PNG, JPEG, and WebP outputs.

Limitations:

• This is not designed to take arbitrary HTML from websites to make screenshots. It is for turning small custom templates into images quickly.
• It's designed to be secure (network and filesystem access are off by default), but it's not designed to take arbitrary user-submitted documents. If you want to use it this way and you find a security flaw, let me know in the repo.
• It does not support JavaScript.
• It does not support every CSS/HTML feature (though more support is added all the time), so make sure to verify it's doing what you want. You may need hacks to get images rendering like a real browser.
• The output images are reasonably sized, but the encoding options are geared for quality. You may want to use a library to fully optimize the image for your use case, then cache it for production.

We currently use it to make dynamic OG and social media images. We host a secret URL on Django for staff to use images how they want: example. You can see example templates here, with how they render here.

Let me know if you like it!

Github repo

Every workshop and hackathon has the same final boss:

“Can we get the certificates by tonight?” 😅

Then begins the traditional ritual: duplicate a design, change one name, export, repeat… and quietly wonder whether anyone will notice the typo in certificate #47.

I started building a small fix for that problem.

After lots of JOMFS — Just One More Feature Syndrome — it became something more. 🔧

A name field became a visual certificate editor.
A CSV upload became bulk generation.
A download button became issuance to each student’s own account.
And, naturally, certificates needed QR codes, public verification, and revocation status.

That project is now open source: Certifier — a tool for designing, issuing, and verifying certificates.

What it can do

• Upload a certificate design or import one from Canva
• Place text, logos, signatures, and QR codes in a visual editor
• Generate certificates in bulk from a CSV
• Deliver certificates to the right student via email or roll number
• Let anyone verify a certificate through a QR code or public code
• Show whether a certificate is valid or revoked

Tech stack

• Backend: Django
• Task processing: Celery
• Frontend: Next.js
• License: AGPL-3.0

Run docker compose up and you can have a working setup with demo data in a few minutes.

Explore the code

• Backend: https://github.com/Shantanu700/certifier_reloaded_backend
• Frontend: https://github.com/Shantanu700/certifier_reloaded_frontend

I'd love contributions: bug reports, fixes, documentation, feature ideas, and feedback from anyone who has had to survive certificate season. 💬

I'm especially interested in feedback on the architecture, verification workflow, and features that would make this useful for colleges, workshops, and hackathons.

If you've built something similar or dealt with certificate generation at scale, I'd love to hear how you approached it!

I wrote up a step-by-step guide for putting a Django app online with PostgreSQL, and two settings came up that catch a lot of people the first time, wherever they deploy:

1. CSRF_TRUSTED_ORIGINS. Since Django 4.0, a login form posted over HTTPS behind a proxy fails with "403 CSRF verification failed - Origin checking failed" unless your site's address is in CSRF_TRUSTED_ORIGINS. The admin login is usually where you first see it. Reading it from the environment keeps it out of your code:

CSRF_TRUSTED_ORIGINS = [os.environ['APP_URL']] if os.environ.get('APP_URL') else []

2. DATABASES from the environment. startproject gives you SQLite. Pointing it at PostgreSQL with the values your host provides, instead of a password in settings.py:

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': os.environ['POSTGRES_DB'],
        'USER': os.environ['POSTGRES_USER'],
        'PASSWORD': os.environ['POSTGRES_PASSWORD'],
        'HOST': os.environ['POSTGRES_HOST'],
        'PORT': os.environ.get('POSTGRES_PORT', '5432'),
    }
}

Plus psycopg in your dependencies, then migrate, and createsuperuser --noinput reads DJANGO_SUPERUSER_USERNAME / PASSWORD / EMAIL if you want the admin user created without a prompt.

The full guide, with screenshots of every step, runs it on Uppcoder's free plan, where the app gets its own HTTPS address and VS Code in the browser, and the two settings above are done for you: https://portal.uppcoder.com/guides/deploy-django-postgresql

Disclosure: I work on Uppcoder. Happy to answer questions about any of the steps, on Uppcoder or anywhere else.

https://magula10.pythonanywhere.com/ebola

Had one of those deployments recently where everything looked fine until I started clicking around and realized I'd broken something that had nothing to do with the change I made.

Nothing catastrophic and I fixed it pretty quickly, but it exposed how bad my rollback plan is.

For a small app or tiny team, what do you consider the sensible minimum here?

I don't want to build some elaborate deployment pipeline for a project with modest traffic, but rebuilding the previous commit while something is broken feels like a pretty dumb recovery strategy too.

Ideally I'd like deployments to keep known-good versions around so putting the previous one live is basically an immediate action, then I can figure out what I broke without rushing.

Curious how people handle this before the project is big enough to justify serious DevOps work.

https://magula10.pythonanywhere.com/incident/

Sharing two concrete fixes from a Django REST + PostgreSQL build I am working on (a multi-tenant SaaS, one shared database, tenant column on the tenant-owned models). Posting in case it saves someone else the debugging time.

Mistake 1: filtering by tenant inside each view, by hand. Early on, individual views did things like Model.objects.filter(tenant=request.user.tenant) — until one list endpoint missed it and a detail view used a raw get_object_or_404 with only the PK. Nothing bad reached production, but code review caught how easy it would be to miss one. Fix: a single TenantScopedViewSet mixin that overrides get_queryset() and filters by the authenticated user's tenant, plus a matching manager-level check in tests. The rule in the codebase now is simple: if a view is not using the mixin, that is a bug to explain in review. Detail views get the same scoped queryset, so a cross-tenant PK returns 404 instead of leaking existence.

Mistake 2: ignoring connection settings for background work. Web requests were fine, but my background worker processed document jobs in a loop and, with CONN_MAX_AGE = 0, opened a fresh Postgres connection for every job. Under a batch of uploads that showed up as connection churn and avoidable latency. Setting a sane CONN_MAX_AGE for the worker (and making sure connections are closed cleanly where Django expects long-lived processes to handle it) removed most of that overhead.

Question for people running multi-tenant DRF on one database: do you enforce tenant scoping at the viewset/mixin layer like this, at a custom manager layer, or with Postgres row-level security? I picked the mixin + tests because it is explicit, but RLS looks stronger as a backstop.

I am a student form the tire - 3 engineering college form India .Till now i have the knowledge of the Javascript , Ts ,React, Python ,Django, DRF, Django ORM ,Redis ,celery, RabbitMQ, Docker,and basci of the Kubernetes.

I want to get a job by next year and I recently started open-source contribution with goal to participating in GSOC 27.

I am confused about what I should focus on next ,Should I start learning AIML that RAG and gen -AI stuff ,or should I start strengthen my fundamental by learning system design ,understanding redis internal and then moving toward devops. so what should I do next to land good paying Job in next year .

I was benchmarking database-backed task workers and ran into something that applies to any Django worker, whatever backend it uses.

With the default CONN_MAX_AGE = 0, Django closes the connection after every task, so each task opens a new PostgreSQL connection. In my runs that cost about 5 ms, more than the claim-and-run path takes on a warm connection.

Four workers, 20,000 no-op tasks, PostgreSQL 16 in Docker, medians of five runs, in tasks per second:

Holding the connection is about a 4x change for one backend and 3x for the other. Django 6.0 rejects a pool combined with a nonzero CONN_MAX_AGE, so pick one. If your worker runs the default, that's the first thing I'd change before adding more processes. These tasks do nothing, so with real tasks the relative gain will be smaller.

Both backends got identical connection settings. With a pool or persistent connections, django-ox did 1.4 to 1.7 times the tasks per second of django-tasks-db. django-ox is my project. It's 100% open source (BSD-3-Clause) with no paid tier, and pull requests are welcome. Settings and every raw number: https://oxpull.com/django-ox/benchmarks/

What do you run your workers with, persistent connections or a pool? If your numbers differ, I'd like to see them.

Hello everyone,

I am stepping into Django with Node.JS/ExpressJS background.

Right now i am using Django on backend with DRF.

Could anyone tell me or give me some advice for custom error messages? Since English is not my native language, i have to translate also add custom error messages.

As far as i understood, there are different layers where the error accours.

This could be HTTP Level, this could be validation level, this could be DB level.

So, can anyone give me some advice and show me a path where i can add and improve my custom error messages?

Thank you.

Quiero evitar tener un texto enorme, se que la norma es que cada Tool del MCP tenga su propio docstring, pero que es recomdable poner el las instruction del DJANGO_MCP_GLOBAL_SERVER_CONFIG

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

Update 2:
Best viewed directly with draw.io/diagrams.net (where you can zoom/edit etc):
- go to https://app.diagrams.net/
- click File -> open from URL
- paste in the source doc url above.

Update:
To address those that find it difficult to follow, it's how I see how things put together that we use.

- Users of different types come in on the left.
- Cloudflare is used as the WAF/CDN before reaching the Django server.
- Items in the blue columns are the key packages that are used for important functionality (not exhaustive)
- Media is stored in Cloudflare R2 (S3 compatible buckets) that have both public and private versions for each environment.
- All the services/dependencies are in a row coming down, reflecting the choices for logging/analytics/e-mail/payments etc.
- the 'Forge' bit is likely the most unclear, this is a separate Python app that is run to execute various pipelines that help to managing content. This can be for reviewing/scoring of content, content revision based on briefs, image management etc.
- Git repos connected to dokku, allowing for easy deploys (with the idea that it makes it easy to migrate to another hosting provider if required).
- A separate droplet is used to deploy the development environments.
- Other bits showing the software choices.

This would be very easy to integrate into your system. Use the arrow and +/- keys to zoom and pan.

https://magula10.pythonanywhere.com/flight/

Suggestions welcome!

https://magula10.pythonanywhere.com/incident/

Suggestions welcome!

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

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?

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.