2.0 -//Pentabarf//Schedule//EN PUBLISH WH9A7C@@pretalx.evolutio.pt -WH9A7C Static Islands, Dynamic Sea en en 20260415T100000 20260415T105500 0.05500

Static Islands, Dynamic Sea

Python's dynamic nature isn't a bug—it's a feature. Django leveraged this from the start, building elegant APIs that would be impossible in a rigidly typed system. Duck typing, runtime introspection, and flexible interfaces gave us the expressiveness we grew up with. But sometimes we want more. Type safety at API boundaries. Auto-completion that actually works. Data classes instead of ORM objects. The confidence that comes with catching errors before runtime. The answer isn't to abandon Python's dynamic core—it's to build static islands where they help. Incremental typing lets us wrap specific layers (like the ORM) in type-safe interfaces while leaving Django's liquid core untouched. This talk explores when, why, and how to add these type-safe layers, and demonstrates Mantle, utilities for typing around Django's liquid core. We'll keep the Python you love, with those little extras when you need them. PUBLIC CONFIRMED Keynote https://pretalx.evolutio.pt//djangocon-europe-2026/talk/WH9A7C/ AMPHITHEATRE Carlton Gibson PUBLISH ZY8UHF@@pretalx.evolutio.pt -ZY8UHF Oh, I Found a Security Issue en en 20260415T110000 20260415T113000 0.03000

Oh, I Found a Security Issue

This talk is your behind the scenes guide to Django's best in class security processes. I’ll give an introduction to how the team handles security issues: the triaging, fixing, disclosure process, and releases. I will then review the history of Django’s security issues to identify hotspots and areas to look out for. Lastly, I will explore the impact of AI and LLMs on the security of Django as well as its security team. The talk will give you everything you need, to help you interact with Django’s security team when needed, and show how Django's security process can act as an example for other open source projects. PUBLIC CONFIRMED Talk https://pretalx.evolutio.pt//djangocon-europe-2026/talk/ZY8UHF/ AMPHITHEATRE Markus Holtermann PUBLISH ZQE3GP@@pretalx.evolutio.pt -ZQE3GP ATLAS: Building a Zero‑Budget IT Service Management Platform with Django in the Public Sector en en 20260415T120000 20260415T123000 0.03000

ATLAS: Building a Zero‑Budget IT Service Management Platform with Django in the Public Sector

This talk presents ATLAS, a real-world Django application built and operated in the public sector under strict governance, security, and resource constraints. The session starts by outlining the organizational challenges of handling IT service requests at scale and why traditional email-based workflows failed. It then dives into the system’s architecture, focusing on workflow-driven design, authentication and authorization strategies, automation with SLA tracking, and observability through metrics and dashboards. The SLA model does not only enforce operational discipline but is also aligned with the organization’s official performance objectives, enabling IT teams to track compliance against organizational targets and support data-driven decision-making. PUBLIC CONFIRMED Talk https://pretalx.evolutio.pt//djangocon-europe-2026/talk/ZQE3GP/ AMPHITHEATRE Georgios Poulos PUBLISH X9APYZ@@pretalx.evolutio.pt -X9APYZ AI-Assisted Contributions and Maintainer Load en en 20260415T123500 20260415T130500 0.03000

AI-Assisted Contributions and Maintainer Load

**AI tools** are increasingly used by contributors to *read code*, explore codebases, and generate changes. In many open source projects, this is already changing how issues are opened and how pull requests are submitted. While AI can help people get started, it also creates new challenges for maintainers. This talk is based on *real discussions and concrete examples* from the open source community. Maintainers in projects such as **Django**, Python, GNOME, and OCaml report similar patterns: large or unnecessary AI-generated changes, missing design discussion, references to *non-existent APIs*, and contributions that are technically correct but hard to review and maintain. In many cases, work is moved from contributors to already time-limited maintainers. The focus of this talk is not on banning or promoting AI. The shared concern across these communities is **responsibility**. Problems appear when AI replaces *understanding*, *testing*, and *human accountability*, breaking the social processes that open source depends on. The talk also looks at how projects are responding. Some add documentation, disclosure rules, or review guidelines. Others start wider discussions about *governance*, *sustainability*, and *legal risk*. These responses show that the issue goes beyond individual pull requests. Instead of giving simple answers, this talk shares the **real questions** the community is asking today, and helps contributors and maintainers think more clearly about the future role of AI in Django and open source projects. PUBLIC CONFIRMED Talk https://pretalx.evolutio.pt//djangocon-europe-2026/talk/X9APYZ/ AMPHITHEATRE Paolo Melchiorre PUBLISH 3LKHFS@@pretalx.evolutio.pt -3LKHFS Reliable Django Signals en en 20260415T144000 20260415T151000 0.03000

Reliable Django Signals

Django signals are extremely useful for decoupling modules and implementing complicated workflows. However, the underlying transport for Django Signals makes them unreliable and subject to unexpected failures. In the talk I demonstrate several strategies for decoupling modules, including Django Signals, and discuss different aspects such as user experience and fault tolerance. Finally, I present an alternative underlying transport implementation for Django Signals using the new tasks framework in Django 6 that addresses the shortcomings of all other approaches. The alternative implementation makes Django Signals reliable for mission critical workflow and for applications that require high reliability and fault tolerance. PUBLIC CONFIRMED Talk https://pretalx.evolutio.pt//djangocon-europe-2026/talk/3LKHFS/ AMPHITHEATRE Haki Benita PUBLISH ZLRWH9@@pretalx.evolutio.pt -ZLRWH9 Django forms in the age of HTMx: the single field form en en 20260415T151500 20260415T154500 0.03000

Django forms in the age of HTMx: the single field form

PUBLIC CONFIRMED Talk https://pretalx.evolutio.pt//djangocon-europe-2026/talk/ZLRWH9/ AMPHITHEATRE Hanne Moa PUBLISH MSJQLT@@pretalx.evolutio.pt -MSJQLT Scaling the database - using multiple databases with Django en en 20260415T161500 20260415T164500 0.03000

Scaling the database - using multiple databases with Django

As your Django application gets popular, you'll need to scale up. Maybe you need to run more web workers, more CPU cores, or even spread across more servers. This works great, up to a point. Your database is likely at the core of your application, but whilst it's easy to throw more resources at a database, it's much harder to scale to multiple. After a while, you'll outgrow a single database. Maybe performance isn't the issue, and instead you need the rock-solid reliability which can only come from multiple database servers. Django supports multiple database connections, but leaves it up to you to manage how to use them and which queries to send where. But, how? How do you split your data between multiple databases? How do you tell Django which to use when? If your infrastructure already has replicas, how can you use them effectively. PUBLIC CONFIRMED Talk https://pretalx.evolutio.pt//djangocon-europe-2026/talk/MSJQLT/ AMPHITHEATRE Jake Howard PUBLISH YPQ8YK@@pretalx.evolutio.pt -YPQ8YK Partitioning very large tables with Django and PostgreSQL en en 20260415T165000 20260415T172000 0.03000

Partitioning very large tables with Django and PostgreSQL

## Introduction Database systems like PostgreSQL provide a useful layer of abstraction: you can store and retrieve data using SQL (via the Django ORM) without having to worry about how the database manages the data under the hood. Database indexes enable fast queries, and automatic vacuuming cleans up old row versions and deleted rows. But as tables become extremely large, the abstraction starts to break down, and performance issues become apparent. In this talk, I'll describe what options are available (including partitioning) to manage large database tables, and how we're approaching this problem at Kraken Tech. ## The problem At Kraken Tech, one of our installations of Kraken has a table with about 9 billion rows and is about 3 TB in size. This table takes around 20 hours to vacuum, and it requires vacuuming about once a day. During a recent bigint conversion project (see my talk from DjangoCon Europe 2025), this long and frequent vacuuming interfered with the other maintenance work we were doing on the table. We'd like to reduce the time taken to vacuum; other performance improvements would also be welcome. We'd also like the solution we adopt to be generally applicable to other large tables. One approach would be to delete old data from the table and store it in another storage system instead (such as S3). However, that would also require application-level changes to enable access to the old data, and those changes wouldn't necessarily generalise to other tables. Another approach would be to start with a brand new table for all new data. The new table will be fast (until it grows to the size of the old table), and the old table will stop needing to be vacuumed once no more writes to it are needed. This approach will also require application-level changes to access both databases, and will only defer the problem, not solve it. A third approach is to partition the table using PostgreSQL's native support for partitioning. Partitioning splits a large table into a number of smaller tables, with each row being assigned to one of the partitions depending on the value of its partition key. These smaller tables have their own indexes and are vacuumed separately as needed, which will address the problem of slow vacuuming. And accessing a partitioned table is transparent to the application, mostly. ## Requirements, choices and compromises PostgreSQL supports different types of partitioning: range, list and hash; that's one choice we need to make. Another choice is how many partitions will be used, and when to add new ones. But the biggest choice, and the one with the most requirements and consequences, is which column(s) to use for the partition key. There usually will be a compromise here, since the partition key that offers the most performance improvement will often not support desired constraints. And Django imposes its own requirements that affect the choice of partition key. ## Partitioning existing tables For our use case at Kraken Tech, we would like to partition existing tables without imposing any system downtime. The PostgreSQL extension `pg_partman` provides support for "online" partitioning that enables this, but via manual processes that don't scale across the large number of installed systems we support. We have developed a Python package `psycopack` for replicating PostgreSQL tables and performing schema changes in the process; we are working on enhancing that tool to support partitioning as well. PUBLIC CONFIRMED Talk https://pretalx.evolutio.pt//djangocon-europe-2026/talk/YPQ8YK/ AMPHITHEATRE Tim Bell PUBLISH KYPGJ8@@pretalx.evolutio.pt -KYPGJ8 Django from the trenches: Advanced Indexing and Concurrency in Django and PostgreSQL en en 20260415T110000 20260415T123000 1.03000

Django from the trenches: Advanced Indexing and Concurrency in Django and PostgreSQL

Building applications to serve actual users is really hard! Traffic spike, data accumulates, queries becomes slow, response time suffer and you sre left completely baffled! In this workshop we'll optimize real-life scenarios in a Django application using advanced indexing techniques in PostgreSQL. We will also identify and tackle concurrency issues and experiment with different approaches to prevent them, without bringing the system to a halt. By the end of this workshop you'll learn how to prepare your Django application for the real life. PUBLIC CONFIRMED Long Workshop https://pretalx.evolutio.pt//djangocon-europe-2026/talk/KYPGJ8/ NEW STAGE Haki Benita PUBLISH DDP7TX@@pretalx.evolutio.pt -DDP7TX llms.txt and Django en en 20260415T151500 20260415T164500 1.03000

llms.txt and Django

The llms.txt format is an emerging standard to structure information for Large Language Models. It’s a desirable addition to the docs of Python packages. We have been [busy adopting it for Wagtail](https://wagtail.org/blog/llmstxt-preparing-wagtail-docs-for-ai-tools/), and can now share how it all went. Let’s review how to adopt it! We’ll discuss the fundamentals of the format and its benefits as a user of the docs, and as a maintainer. How to produce and consume those files across different tools (Sphinx, mkdocs, Django). How to optimize them for different LLMs with an eval suite. Tools and techniques you should be able to reuse through other engineering tasks with LLMs. PUBLIC CONFIRMED Long Workshop https://pretalx.evolutio.pt//djangocon-europe-2026/talk/DDP7TX/ NEW STAGE Thibaud Colas PUBLISH 3BGDDQ@@pretalx.evolutio.pt -3BGDDQ A Practical Guide To Agentic Coding For Django Developers en en 20260416T093000 20260416T102500 0.05500

A Practical Guide To Agentic Coding For Django Developers

PUBLIC CONFIRMED Keynote https://pretalx.evolutio.pt//djangocon-europe-2026/talk/3BGDDQ/ AMPHITHEATRE Marlene Mhangami PUBLISH 9GZGLP@@pretalx.evolutio.pt -9GZGLP Digitising Historical Caving Data with Python and Django en en 20260416T103000 20260416T110000 0.03000

Digitising Historical Caving Data with Python and Django

Endless quantities of old but critically important data is trapped in paper journals and reports across the world. Is it possible to extract this data and make it available to the masses, even when the data is highly specialised and of poor quality? That is what I did for reports of caving incidents and accidents dating back 50 years. The National Speleological Society has published American Caving Accidents since 1967, documenting thousands of incidents, and despite being freely available as PDFs, these are unindexed, poorly scanned, and basically impossible to use as a learning tool. In this talk, I'll show you how I built a system that programmatically processed these documents into a structured, publicly searchable database. You'll see the full pipeline: how to OCR degraded/low quality documents, custom code to untangle multi-column layouts, and LLM processing stages to extract and format the data whilst maintaining 100% accuracy. I'll cover some of the more unusual challenges: handling dates like "Autumn 1996" with a custom model field, building a pluggable processing step system in Django, and how to intake and normalise large quantities of low quality data in a relational database. Have you ever looked at a stack of old documents and thought: "there's valuable data in here, if only someone could extract it"? This talk is about what happens when you actually try. PUBLIC CONFIRMED Talk https://pretalx.evolutio.pt//djangocon-europe-2026/talk/9GZGLP/ AMPHITHEATRE Andrew Northall PUBLISH DLX7N7@@pretalx.evolutio.pt -DLX7N7 Beyond print(): Observability to debug you Django apps en en 20260416T110500 20260416T113500 0.03000

Beyond print(): Observability to debug you Django apps

Most Django developers have been there: something is slow, users are complaining, and the first instinct is to sprinkle `print()` statements or scroll through server logs hoping for a clue. Without proper observability, diagnosing performance bottlenecks in a Django application (or any application, for that matter) is guesswork. Observability is the practice of understanding what is happening inside your application by looking at the signals it produces: traces, metrics, and logs. While the concept is well-established in infrastructure and DevOps circles, it remains under-explored in the day-to-day workflow of many Django developers. Yet Django's middleware architecture, ORM, and request/response cycle make it particularly well-suited for instrumentation. In this talk, I will walk through how to add observability to a Django app. I'll cover the **Four Golden Signals of observability** (latency, traffic, errors, and saturation), explain why they matter for your Django app, and show how to expose them with minimal setup. Through a live demo, you will see how to use observability standards to monitor your system. You'll also see how to leverage AI to query your logs and traces in natural language or with SQL. Attendees will leave this talk with a practical, reproducible workflow for adding observability to their own Django projects, along with an understanding of which signals to monitor and why. PUBLIC CONFIRMED Talk https://pretalx.evolutio.pt//djangocon-europe-2026/talk/DLX7N7/ AMPHITHEATRE Laís Carvalho PUBLISH D3X8M9@@pretalx.evolutio.pt -D3X8M9 Role-based access control in Django - How we forked Guardian en en 20260416T120500 20260416T123500 0.03000

Role-based access control in Django - How we forked Guardian

Django's built-in access control system is very good for basic operations and Guardian is a natural extension to the object level. However, our customers wanted more: a group hierarchy, just-in-time privileged access, delegating permissions to other users, custom permissions. This talk tells the story of how an authentication company built a role-based authorization system for Django. PUBLIC CONFIRMED Talk https://pretalx.evolutio.pt//djangocon-europe-2026/talk/D3X8M9/ AMPHITHEATRE Gergő Simonyi PUBLISH WUZSPX@@pretalx.evolutio.pt -WUZSPX Is it time for a Django Admin rewrite? If so, how? en en 20260416T124000 20260416T131000 0.03000

Is it time for a Django Admin rewrite? If so, how?

What if customizing Django's admin felt like writing any other Django view? Not just a cosmetic refresh, but a radically new approach relying on Django itself, factory-generated views and with a plugin-first design. Talk Structure: 1. The Problem Space (5 min) - Django admin's 20-year legacy: what it got right and where it shows its age - The extension dilemma: 3rd-party ecosystem and collisions between extensions - Developer experience gap: different patterns for regular Django vs. admin - Community feedback: recurring requests that would be hard to implement 2. Architectural Foundations (7 min) - View Factories: How views get generated dynamically - Action System: Actions are the recipes followed by view factories - Plugin Hooks: djp/pluggy integration and hook patterns - Out-of-the-box enhancements 3. Examples & Demo (8 min) - Starting with familiar API: @register(Product) and list_display - Customizing `list_display` - Customizing `layout` - Creating your own plugins - Testing tools: `BaseCRUDTestCase` - Demo (pre-recorded) 4. Migration & Adoption (4 min) - Running side-by-side with existing admin - Early adopters (well-know projects that already have plugins) - Extension compatibility matrix: no-effort, medium-effort, hard cases 5. The Path Forward (2 min) - What's next: roadmap and timeline - Other potential benefits mid-term - Call to action PUBLIC CONFIRMED Talk https://pretalx.evolutio.pt//djangocon-europe-2026/talk/WUZSPX/ AMPHITHEATRE Emma Delescolle PUBLISH BC3BJY@@pretalx.evolutio.pt -BC3BJY Django Task Workers in Subinterpreters: Single-Server Django Applications Without Process Overhead en en 20260416T144000 20260416T151000 0.03000

Django Task Workers in Subinterpreters: Single-Server Django Applications Without Process Overhead

Deploying Django applications with background tasks typically requires managing multiple processes and queues. But what if you could run everything in a single process without sacrificing isolation or performance? This talk shows how Python 3.14's `subinterpreters` enable a practical pattern for self-contained Django applications: **The Pattern**: - Web server and task workers run in separate subinterpreters within one process - True isolation prevents memory leaks and state contamination between components - Simplified deployment: one process, one server, one application **What This Solves:** - **Deployment simplicity**: No separate worker processes, no queue infrastructure - **Resource efficiency**: Shared memory space with isolated execution - **Self-contained applications**: Perfect for internal tools, small services, or edge deployments **We'll walk through code showing:** - Setting up Django web server and task workers in InterpreterPoolExecutor - Inter-interpreter communication using shared queues between webserver and task worker - We will also look at a version using PostgreSQL as a backend and how to run tasks - Running CPU-intensive tasks (image processing, PDF parsing) without blocking web responses - Gotchas and errors that occur, how to monitor them, and how to build in a mechanism for recovery - **Error recovery mechanisms**: - Worker subinterpreter crash detection and automatic restart - Graceful shutdown handling for in-flight tasks **We will also discuss:** - Limited third-party library support - Difficulties in exception handling and retry mechanisms This is a practical pattern for real Django applications that need background processing without the complexity of traditional distributed task queues. You'll leave with concrete examples you can adapt for your own single-server Django deployments. **Target audience**: Django developers who deploy their own applications and want simpler background task processing. PUBLIC CONFIRMED Talk https://pretalx.evolutio.pt//djangocon-europe-2026/talk/BC3BJY/ AMPHITHEATRE Melhin Ahammad PUBLISH UJZX9Z@@pretalx.evolutio.pt -UJZX9Z When SaaS Is Not Allowed: Shipping Django as a Desktop App en en 20260416T151500 20260416T154500 0.03000

When SaaS Is Not Allowed: Shipping Django as a Desktop App

Some teams face constraints that make standard web deployment impossible: confidential data that must never leave user machines, air-gapped environments, and workloads that are too expensive to run centrally. This talk presents a production pattern for turning Django into a desktop application by packaging it inside Electron. The case study is Steel-IQ, an open-source steel-industry simulation tool for multi-decade decarbonization scenarios, shipped for local execution with sensitive data. Structure (30 minutes): 1. Why this architecture exists: confidentiality, offline environments, heavy compute. 2. System design: Electron + Django + django-tasks workers + SQLite (including WAL mode). 3. Packaging and distribution: python-build-standalone, uv, installers, and update paths via GitHub Actions. 4. Production failure modes: startup checks, graceful shutdown, orphan process cleanup, migrations, and memory behavior. 5. Demonstration and decision checklist: when this approach is right, and when to choose alternatives. Audience and level: - Intermediate to advanced Django developers. - Useful for teams building internal tools, offline-first products, or applications with strict data constraints. - No prior Electron experience required. Attendee takeaways: 1. A reference architecture for embedding Django inside Electron in production. 2. A concrete packaging strategy for standalone Python across platforms. 3. Process-management patterns for reliability and recovery. 4. Operational lessons for long-running local workloads. 5. A decision framework for when desktop-packaged Django is a fit. PUBLIC CONFIRMED Talk https://pretalx.evolutio.pt//djangocon-europe-2026/talk/UJZX9Z/ AMPHITHEATRE Jochen Wersdörfer PUBLISH XLSYHM@@pretalx.evolutio.pt -XLSYHM Advanced ORM kung-fu for on-demand filtering, sorting, and summing 40 million financial transactions en en 20260416T161500 20260416T164500 0.03000

Advanced ORM kung-fu for on-demand filtering, sorting, and summing 40 million financial transactions

When the base data is a collection of 40 million postings in a table that grows longer every day, distributed across 472,000 accounts on roughly 5,000 properties; when the use case is filtering, grouping, summing, and sorting these; and when all of this has to happen on-demand for users trying to keep track of what the real-time financial situation of their property is- that's when you realise that using the ORM for mere data access and working the data in Python might not be the ticket. And, when users suddenly want to compare their property to some of the 5,000 others, your Python-first approach will expose the users to a considerable wait which, frankly, can be a bit embarrassing. You don't want to be that guy. I'm going to talk about how I pushed all this heavy lifting to Postgres using the Django ORM and (almost) no raw SQL - with techniques like chained annotations, window functions for cumulative summing, subqueries with OuterRef, conditional statements in the query, and, for extra fun, digging into JSONB-arrays because hey- there's a json blob describing how all of this data finally has to be sorted. I'll also be touching on the subject of materialized views. The benefits of this approach are not only dramatically better performance (what my friend said...) but also, super-readable and solid code. If you're a Django developer working with large and growing datasets, or if you're curious how your app can benefit from the performance of Postgres without writing raw SQL, this talk is for you. PUBLIC CONFIRMED Talk https://pretalx.evolutio.pt//djangocon-europe-2026/talk/XLSYHM/ AMPHITHEATRE Mathias Wedeken PUBLISH 8QGZVD@@pretalx.evolutio.pt -8QGZVD How to understand the employer's perspective when you apply for a job en en 20260416T110500 20260416T123500 1.03000

How to understand the employer's perspective when you apply for a job

One of roles at Canonical is hiring lead. Since 2022, I have hired several dozen people for numerous different roles. I have interviewed hundreds, and reviewed thousands of applications. A candidate's expectations of what they ought to do can be far apart from that of a prospective employer. I have seen hundreds of candidates fare much less well in the process than they should have done, simply because they were not able to understand the process from the employer's perspective. It _particularly_ harms candidates unfamiliar with the industry, from other cultures, or without personal networks of people who are already industry insiders. They make unnecessary mistakes. They emphasise and focus on the wrong things. They neglect things that could give them real advantage. It's one of my missions in life to help address that unfairness. I want to share and explain the employer's perspective, so that applying for jobs becomes less like trying to understand the workings of a black box. I will also show how to approach job applications in ways that help a candidate provide what the employer needs. This is a hands-on workshop, in which participants will have the chance to revise their own approaches based on insider insights, There will also be plenty of opportunity for questions and discussion of strategy and technique, in writing CVs, submitting applications and taking part in interviews and assessments. There's a vast amount of bad advice and false information about how to succeed as a job applicant. The perspectives and advice in this session come directly from my own position and experience as someone who assesses, interviews and hires candidates: they are what I wish all the candidates I meet already knew and did. PUBLIC CONFIRMED Long Workshop https://pretalx.evolutio.pt//djangocon-europe-2026/talk/8QGZVD/ NEW STAGE Daniele Procida PUBLISH S8GYY9@@pretalx.evolutio.pt -S8GYY9 Django and AI: A Community Conversation en en 20260416T151500 20260416T164500 1.03000

Django and AI: A Community Conversation

The Django community is at a pivotal moment in its relationship with generative AI. From code generation tools reshaping developer workflows to ethical questions about training data and environmental impact, there's no shortage of opinions, but limited space for structured, collective sense-making. This workshop proposes a facilitated Open Space-style discussion that brings the Django community together to surface, explore, and document the key themes, concerns and opportunities around Django and AI. Rather than prescribing answers, we want to harness the room's collective expertise to map the landscape as practitioners experience it. The session, hosted by Thibaud Colas and Laura Gates, will use a participatory format drawn from Open Space Technology, where attendees propose and lead breakout discussions around the sub-topics that matter most to them – whether that's AI-assisted development, ethical frameworks for Django projects integrating LLMs, the Django Software Foundation's approach to AI policy, or something we haven't anticipated. Thibaud brings deep technical leadership and a long-standing commitment to ethical open-source practice as product lead for the Wagtail CMS, while Laura brings experience facilitating open space and participatory events across academic, charity and corporate settings. Together, we'll synthesise the session's outputs into a documented resource for the wider Django community. This workshop is for anyone in the Django ecosystem – whether you're enthusiastic about AI, cautious, or still figuring out where you stand. No prior AI expertise is needed; the goal is an inclusive, grounded conversation that reflects the full range of community perspectives and produces something genuinely useful beyond the room. PUBLIC CONFIRMED Long Workshop https://pretalx.evolutio.pt//djangocon-europe-2026/talk/S8GYY9/ NEW STAGE Laura Gates Thibaud Colas PUBLISH AS7ZTU@@pretalx.evolutio.pt -AS7ZTU Body of knowledge en en 20260417T093000 20260417T102500 0.05500

Body of knowledge

PUBLIC CONFIRMED Keynote https://pretalx.evolutio.pt//djangocon-europe-2026/talk/AS7ZTU/ AMPHITHEATRE Daniele Procida PUBLISH EGA3KM@@pretalx.evolutio.pt -EGA3KM Zero-Migration Encryption: Building Drop-in Encrypted Field in Django en en 20260417T103000 20260417T110000 0.03000

Zero-Migration Encryption: Building Drop-in Encrypted Field in Django

Django doesn't come with a solution to encrypt database data out-of-the-box. While community projects exist, they often require complex migration processes or double-writing to new columns. At Sentry, for our high-traffic distributed system, we needed a solution that would abstract encryption logic without worrying about encryption keys on a case-by-case basis or performing risky migrations on millions of existing entries. We built EncryptedFields, a custom Field base class that provides drop-in, no database migration, replacements for CharField, JSONField, and TextField. Our approach allows for a "hybrid" state: the field handles both old plain-text formats and the new encrypted format on-the-fly. This eliminated the need for complex data migrations or secondary columns, making the transition safe and seamless for our engineers. PUBLIC CONFIRMED Talk https://pretalx.evolutio.pt//djangocon-europe-2026/talk/EGA3KM/ AMPHITHEATRE Vjeran Grozdanic PUBLISH DHCJ9P@@pretalx.evolutio.pt -DHCJ9P Auto-prefetching with model field fetch modes in Django 6.1 en en 20260417T110500 20260417T113500 0.03000

Auto-prefetching with model field fetch modes in Django 6.1

New in Django 6.1, model field fetch modes provide a way to avoid the deluge of queries from accessing un-fetched objects during a loop (also known as the "N+1 queries" problem). You may be familiar with how Django's prefetch_related() and select_related() methods can prevent these queries, but unlike those tools, the "fetch peers" mode does not require maintaining a list of fields to fetch. This can significantly improve project maintenance, especially when QuerySets are constructed at some distance from where they are used. In this talk, we'll cover what's new about fetch modes, what tradeoffs are entailed, how to configure fetch modes per-model via managers, and how to use the "raise" mode to surface issues in development or put guardrails around performance-intensive sections of code (like the django-seal package). PUBLIC CONFIRMED Talk https://pretalx.evolutio.pt//djangocon-europe-2026/talk/DHCJ9P/ AMPHITHEATRE Jacob Walls PUBLISH U3ZMQV@@pretalx.evolutio.pt -U3ZMQV Improving One of Django's Most Used APIs — And It's Not the One You're Thinking Of en en 20260417T120500 20260417T123500 0.03000

Improving One of Django's Most Used APIs — And It's Not the One You're Thinking Of

**The Setup: APIs Are Everywhere** We'll start with a quick tour of what "API" really means—not just REST, but Python imports, command-line interfaces, and the configuration files we use every day. Django's `settings.py` is arguably its most-used API: the interface through which we configure databases, middleware, installed apps, and everything else. And `manage.py` commands are APIs too—contracts between Django and developers about how to run, migrate, and manage projects. This reframing sets up the core question: if `runserver` is an API, what is it communicating? And is that message actually helpful? **The Problem: Django's Deployment Cliff** Deployment breaks down into three parts: setting up the environment, getting code there, and running processes. Django provides great documentation, but when it comes to actually running your app in production, you're on your own. Even the name `runserver` is misleading—it doesn't say "development." It just says "run the server," and for a beginner, that sounds like the whole story. Many miss the jump entirely—not realising a different approach is needed for production. And when they do, configuring Gunicorn, Uvicorn, or Celery workers is daunting—and can feel like a betrayal of the "batteries included" promise. We can add warnings and documentation, but that can add noise and not signal. The reception of adding the warning "do not use in production" to `runserver` has been mixed and if I'm honest it's a poor solution and quick fix to a larger problem. That's coming from me—the one who proposed and implemented it! If the API design itself is confusing, no amount of documentation or warnings will fix that. **A Possible Solution: django-prodserver** I've built and published `django-prodserver`, a package that brings a production process configuration API into the familiar `manage.py` interface, configured through `settings.py`, where it belongs. A `PRODUCTION_PROCESSES` dictionary lets you name and define your processes, with backends for popular WSGI/ASGI servers and background workers. Swap backends by changing one line. The package also includes a `devserver` command—mirroring the symmetry we might want in Django itself. **Live Demo** I'll take an existing project deployed on a Dokku VPS and show what changes when prodserver enters the picture. The goal is to make the "aha" moment tangible: this is what a cleaner deployment API could feel like. **The Bigger Picture: What Could Django Provide?** We can't just change `runserver, Django's stability guarantees mean experimenting with core commands is risky. That's actually a good thing. But packages like django-prodserver give us a safe space to try ideas in the open. What naming makes sense? What hooks should Django expose for the ecosystem to build on? Could this eventually lead to production server support in core? I'll share some thoughts and invite the community to shape what comes next for prodserver and more broadly for designing new APIs through the experimental API feature that has been proposed. **Takeaways** Attendees will leave with: - A new way of thinking about Django's CLI and settings as API surfaces - Practical knowledge of django-prodserver they can use today - Ideas for how the community can shape Django's deployment future - Considerations for API design and how the experimental APIs proposal could open new paths for Django's development PUBLIC CONFIRMED Talk https://pretalx.evolutio.pt//djangocon-europe-2026/talk/U3ZMQV/ AMPHITHEATRE Andrew Miller PUBLISH XBBRYC@@pretalx.evolutio.pt -XBBRYC Where did it all `BEGIN;`? en en 20260417T124000 20260417T131000 0.03000

Where did it all `BEGIN;`?

Until 2013, Django's `atomic` context manager didn't exist. This talk will explore how we had to manage database transactions -- as well as save-points, rollbacks, and commits -- before the ergonomics of `atomic` and what changed when it was introduced. By understanding what tools Django users had in Django 1.5 to make their code atomic, durable, or both, we can understand what problems `atomic` solved and how it made writing Django applications better. Fast-forward to 2026 and we all take `atomic` for granted. But what problems might it have for modern development? We take a look at where `atomic` can cause confusion and suggest some ways to handle that in the future using `django-subatomic`. PUBLIC CONFIRMED Talk https://pretalx.evolutio.pt//djangocon-europe-2026/talk/XBBRYC/ AMPHITHEATRE Sam Searles-Bryant Charlie Denton PUBLISH GX9KHL@@pretalx.evolutio.pt -GX9KHL How Django is helping to build the biggest X-ray observatory to date en en 20260417T144000 20260417T151000 0.03000

How Django is helping to build the biggest X-ray observatory to date

The European Space Agency (ESA) is leading the development of NewAthena (the New Advanced Telescope for High ENergy Astrophysics), an X-ray observatory designed to explore cosmic phenomena such as black holes, neutron stars, and galaxy clusters. The telescope utilizes a 12-meter focal length mirror assembly composed of 600 mirror modules. These modules are manufactured using Silicon Pore Optics (SPO), a technology that transforms silicon wafers into precision mirror plates. In total, the assembly involves approximately 2,400 mirror stacks and 100,000 individual plates. Each component must be tracked through a series of physical, mechanical, and chemical processes at various locations throughout Europe. At each step in this production chain, data is collected to assess the state and quality of the components. This includes logging components' status, recording geometric specifications and process parameters, and maintaining a complete history of the production chain. This talk will explore how Django serves as the software backbone for managing this data. It presents how tracking systems for scientists and engineers are built using Django’s standard core tooling, as well as additional packages where needed. In doing so, this talk demonstrates how a general-purpose web framework can be adapted to support a scientific and engineering environment within a space mission context. PUBLIC CONFIRMED Talk https://pretalx.evolutio.pt//djangocon-europe-2026/talk/GX9KHL/ AMPHITHEATRE Loes Crama PUBLISH 7A87Q7@@pretalx.evolutio.pt -7A87Q7 Django templates on the frontend? en en 20260417T151500 20260417T154500 0.03000

Django templates on the frontend?

In recent years, the Python community has widely adopted HTMX and Hotwire's Turbo. The paradigm of these frameworks is to use AJAX requests to handle changes in the web page. However, there are situations where each HTTP request has a cost, either in bandwidth, volume quota, or any other form of resource cost. In such situations, your application cannot afford to make an HTTP request every time a subform is added to a Django Formset, for instance. After encountering this situation several times, I decided to start working on django-template-transpiler, a tool written in Rust that converts Django templates into a JS function that renders the DTL on client side, similar to what Handlebars can do. The rationale to allow the developers to make your page dynamic, whil minimizing the number of HTTP queries and render both on server-side and client-side using your Django templates as a single source of truth. PUBLIC CONFIRMED Talk https://pretalx.evolutio.pt//djangocon-europe-2026/talk/7A87Q7/ AMPHITHEATRE Christophe Henry PUBLISH 3VP3W7@@pretalx.evolutio.pt -3VP3W7 What's in your dependencies? Supply chain attacks on Python projects en en 20260417T161500 20260417T164500 0.03000

What's in your dependencies? Supply chain attacks on Python projects

Your Django project doesn't just depend on Django - it depends on dozens, sometimes hundreds, of packages. Each one is code that runs with your privileges. What happens when one of them gets compromised? This isn't theoretical. Attackers have phished maintainers to publish malicious versions of trusted packages. They've exploited CI/CD pipelines to inject crypto miners into popular libraries. They've registered typosquatted package names and waited for developers to mistype. This talk examines how these attacks work and what you can do about them. We'll look at real incidents to understand the attack patterns - how attackers get in, what payloads they deploy, and how compromises get detected. And we'll build a practical defense toolkit: scanning for known vulnerabilities, evaluating new dependencies before installing them, and hardening your workflow against supply chain attacks. The talk is aimed at Django developers who want to understand the threat landscape and leave with concrete steps they can implement immediately. No security background required - just familiarity with pip and the general shape of a Django project. PUBLIC CONFIRMED Talk https://pretalx.evolutio.pt//djangocon-europe-2026/talk/3VP3W7/ AMPHITHEATRE Mateusz Bełczowski PUBLISH EGHWNC@@pretalx.evolutio.pt -EGHWNC Improve your CV with help of your Django friends en en 20260417T110500 20260417T115500 0.05000

Improve your CV with help of your Django friends

When searching for a new job a Software Engineer is often reduced to a 2-page PDF document - CV - that they need to submitted to be even considered for a job interview. With this in mind we need to treat it as marketing document, that benefits from going through a few stages of reviews from our peers in the field. We'll start the workshop with some basic guidelines of how to read CVs with the idea that CV can be adjusted for specific job role (e.g. Backend Engineer with FinTech experience). We'll then split into groups and try to read each others' CVs (and possibly LinkedIn descriptions) to help provide feedback on how to better refine them for the next career step. Pre-requisites needed: current CV in English language that participant can share (e.g. uploaded somewhere online); computer or similar device to view participants CVs. PUBLIC CONFIRMED Workshop https://pretalx.evolutio.pt//djangocon-europe-2026/talk/EGHWNC/ NEW STAGE Jure Cuhalev PUBLISH 83B97E@@pretalx.evolutio.pt -83B97E Django-Admin-Deux: From First Steps to Custom Plugins en en 20260417T151500 20260417T164500 1.03000

Django-Admin-Deux: From First Steps to Custom Plugins

What if customizing Django's admin felt like writing any other Django view? Django-Admin-Deux aims at doing just that. It is not just a cosmetic refresh, it's a radically new approach relying on factory-generated views with a plugin-first design. Let's have a closer look! Workshop Structure: 1. Architectural Foundations (20 min) - View Factories: How Django-Admin-Deux generates views dynamically - Action System: Actions are the recipes followed by view factories, including non-model-related ones like dashboards - Plugin Hooks: what hooks are available? - Dataclasses: Django-Admin-Deux uses a series of dataclasses to make extending it type-safe and practical, let's look at them 2. A practical example: using Django-Admin-Deux (30 min) - Simple (migration from the stock admin) - Enhancements (`list_display` with enhanced features, Form `Layout`, `Collection`s) - Adding custom `View`s and `Action`s - Permission system (from stock admin compatibility to composable permissions) - Visibility, debugging and testing 3. A more advanced example: let's build a plugin (30 min) - Structure of a plugin - Minimum requirements - Enhancing existing `View`s and `Action`s - Announcing and checking feature availability Prerequisites: - Familiarity with Django and the admin in general - Starter repository will be provided before the workshop PUBLIC CONFIRMED Long Workshop https://pretalx.evolutio.pt//djangocon-europe-2026/talk/83B97E/ NEW STAGE Emma Delescolle