pretalx runs a conference from call for papers to published schedule

One system for the whole conference arc

pretalx is a conference planning tool, and the scope it claims is unusually complete: a configurable call for papers, reviewing and selection, scheduling and release, speaker communication, and the period after the event when speakers get feedback and upload slides and organisers embed recordings. The README puts it plainly, taking a conference from we should do a call for papers all the way to here is the published schedule, and everything in between.

That is a different pitch from a generic event site. A website can list a schedule; it cannot collect submissions, let several reviewers score them without a spreadsheet, hold a draft schedule that is versioned until it is released, and then keep talking to the speakers afterwards. pretalx is aimed at organisers who need all of that in one place, and at the reviewers, speakers and attendees on the other side of it.

The audience includes both kinds of deployment. There is a public instance at pretalx.com that anyone can use, and there is a self-hosting path for teams that want their own instance on their own infrastructure. A list of self-hosted instances is kept in the project wiki, and pretalx.jetzt tracks events running on the software.

The people behind it are also visible. The primary maintainer is Tobias Kunze, who also runs pretalx.com, and the project is distributed through PyPI as well as through source builds.

The Django stack, and what each dependency is doing for the conference

The manifest describes a Django 6.1 application on Python 3.13, with a set of dependencies that map neatly onto the feature list and are worth reading as a description of the architecture.

The web layer is Django with the argon2 extra for password hashing, django-csp for Content Security Policy headers, django-scopes for scoping queries, django-tables2 and django-filter for the administrative tables that reviewers and organisers live in, django-formtools for the configurable submission forms, django-hierarkey for hierarchical key handling, and django-minify-html to shrink the rendered pages. Markdown, bleach and defusedxml handle the text that comes back from submitters, which is the one input an event site cannot fully trust.

Background work is Celery with Redis, which is what makes the templated, queued emails to speakers possible without blocking a request. djangorestframework and drf-flex-fields provide the documented REST API, and the flex-fields extension is what lets an API consumer request only the fields it needs.

The output formats are covered too: icalendar for calendar exports, reportlab and Pillow for PDF and image work, qrcode for the QR codes that the README lists under receiving assets, and publicsuffixlist plus defusedcsv for handling email addresses and CSV data safely.

Two entries point at a product decision. django-i18nfield stores translated fields in the database rather than in code, which is what allows a multi-language event form. The rules package suggests a rules engine for access control or for automated decisions, and the project classifies itself as Development Status 5 - Production/Stable with support for Python 3.13, 3.14 and 3.15.

Configuring the call for papers without touching code

The submission process is the part organisers spend the most time on, so pretalx treats it as configuration rather than as a fixed form. The call for participation is fully configurable, with custom questions, tracks and session types. A question is not a single text field either, since the dependency on django-formtools and the i18n fields mean a question can carry the type and validation the organiser needs, and a track is the unit that later becomes a room in the schedule.

Session types matter more than they sound. A conference that mixes lightning talks, workshops and long talks cannot schedule them the same way, so separating the type from the track lets the scheduler treat them differently.

Anything the configuration cannot reach is handled by the plugin system. The project documentation states that pretalx is highly configurable and that if the settings are not enough, you can write plugins of your own, and the developer documentation and GitHub Discussions are where that work is described. A plugin is installed as an ordinary Python package, which the development tooling makes explicit with a just install-plugin recipe that runs a uv pip install of the plugin path in editable mode.

That combination, configurable settings first and plugins as the escape hatch, is the shape most conference tools adopt, and it is the right one for an event where every year brings a new wrinkle.

Reviewing, selecting, and versioning a schedule before you release it

Reviewing and selection are described as collaborative reviews, scoring, and team-based workflows. The wording matters: a team-based workflow means several reviewers can be assigned to a submission, which is what a conference with more than one track and more than one reviewer needs, and scoring means the comparison between proposals is recorded rather than argued in chat.

Scheduling is where the tool earns its keep. Schedules are built, versioned and released across rooms and days, with a public agenda and per-speaker views once they are out. Versioning is the important word, because a schedule built in June and a schedule released in August are not the same document, and a published schedule that changes needs a history rather than a silent edit. The per-speaker view is a scheduling tool as much as a courtesy: one person looking at their own slot is a different question from one person looking at a room schedule.

Speaker communication covers templated, queued emails, invitations, and post-event feedback, which is the part that usually gets bolted onto a conference site with a mailing list. After the event, pretalx lets speakers receive feedback, upload their slides, and lets organisers embed recordings.

The one thing the README does not describe is the submission deadline and selection algorithm in detail, or how notifications are worded by default. Those live in the feature list on the main site and in the administrator documentation, which is where a team setting up a real event should start reading.

Running it from source with uv and just

The development tooling is a justfile driven by uv, and it is unusually well organised into groups, which makes the setup short. Installing every dependency, including the frontend packages, takes one command:

uv sync --inexact --all-extras
just install-npm

The --inexact flag is there for a specific reason. The comment in the justfile explains that it keeps locally installed plugins, the ones brought in by just install-plugin, and their transitive dependencies from being removed by the sync. Anyone who has lost a local plugin to a dependency sync will recognise why that flag is not the default.

Setting up a development instance is a single target that does the whole sequence:

just dev-setup

Looking at the recipe, it installs all dependencies, collects static files, compiles translation messages, applies migrations, creates a superuser, installs faker, creates a test event, and finally starts the server. The create_test_event step is a nice touch: it means the running instance is populated with a sample conference instead of an empty database, which is the difference between seeing the scheduling screens or not.

The same file defines the plugin installation recipe, which installs a plugin from a local path in editable mode:

uv pip install -e {{ path }}

There is also a dependency upgrade recipe that runs uv lock --upgrade followed by a full sync, and separate tasks for running the public schedule app dev server and for the npm scripts in the frontend project. The repository also carries a uv.lock and a uv.lock.license file, so the exact dependency versions are pinned for reproducible installs.

Three different licence statements, and the one that counts

The licence information for pretalx is contradictory, and this needs resolving before you deploy it anywhere.

The licence field on the repository says Other, a custom licence that GitHub cannot classify, and the repository has both a LICENSE file and a LICENSES/ directory, which is the structure used by projects that carry a licence with additional terms. The manifest is more specific: it declares license = "AGPL-3.0-only", and a comment right above it explains that the intended expression should be AGPL-3.0-only WITH AdditionRef-Pretalx-AGPL-3.0-Terms, but that Python does not support SPDX v3 yet, so the exact form cannot be expressed. The license-files key points at the LICENSE file itself. Meanwhile the README says the project is published under the terms of the Apache License.

Those three statements cannot all be right, and the resolution matters more than usual here. AGPL-3.0 with additional terms is a copyleft licence with a network use clause, which is a very different obligation from Apache-2.0 for anyone who modifies pretalx and offers it over a network. The file headers in the repository carry the SPDX identifier Apache-2.0, which is the opposite again.

The practical advice is narrow and specific. Read the LICENSE file and the contents of the LICENSES/ directory, and treat those as the terms, since the manifest itself names them as the licence files. Do not rely on the repository label, and do not rely on the README paragraph either.

This is a description of the terms as written, not advice on how to apply them.

Regular releases, a coverage gate, and a Python version mismatch

pretalx releases on a version scheme that tracks calendar periods. The recent tags are v2026.2.1 on 2026-07-08, v2026.2.0 on 2026-07-07 and v2026.1.2 on 2026-04-30, and the last push to the repository was on 2026-10-19 with the repository not archived. The project describes itself as under active development, and points to a changelog for what is coming.

The claim in the README that the CI gate is 100% test coverage is the kind of statement that is easy to make and hard to believe, so it is worth checking against the actual gate rather than taking it on trust. It does at least explain the shape of the repository, where doc/, tools/, src/ and a justfile sit at the top level.

The Python version requirement is a real inconsistency to plan around. The README says self-hosting runs on Python 3.12 or newer, while the manifest declares requires-python as 3.13 or newer and lists classifiers for 3.13, 3.14 and 3.15. The manifest is the one the installer enforces, so an environment with 3.12 will be refused by a modern pip even though the README says it is supported.

There is one more thing to know before you self-host. The administrator documentation is where the Docker based setup and the manual setup are described, and the project also maintains a blog for version notes. For an event with a fixed submission deadline, the practical risk is not the code but the calendar, so reading the changelog before committing to a date is the sensible move.

Editorial conclusion

pretalx fits an event team that wants one system for the whole arc of a conference, from a configurable call for papers through reviewer workflows to a released schedule and speaker follow-up, and it fits a team that needs its own look and behaviour through plugins rather than by forking. It does not fit someone who needs a one-page event site with no review or scheduling stage, and it is a poor fit for anyone who cannot accept copyleft terms. Verify the licence first, by reading the LICENSE file and the LICENSES/ directory rather than the repository label or the README, and confirm the Python version your environment actually has, since the manifest asks for 3.13 or newer while the README says 3.12 or newer.

Frequently asked questions

Official sources

1. Issues
2. pretalx/pretalx on GitHub
3. Project website
4. README
5. Releases