Indico: conference lifecycle management from abstract submission to printed badge

A CERN project shaped by conference management, not meeting scheduling

Indico began as a workpackage inside the European Union's FP5 programme, part of a project officially named the Integrated Digital Conferencing Project or InDiCo. CERN took responsibility for the Make-a-Conference component, drawing on an earlier internal tool called CDS Agenda. That acronym was eventually retired because InDiCo no longer accurately describes the scope, and the word Indico now carries no meaning beyond the product name.

More than 100 developers, translators and usability specialists from many nationalities have contributed to the codebase. Translators appear as a named contributor category alongside developers, which shows up in the dependency list: Transifex configuration, Babel message extraction files and flask-babel are all present in the repository.

The feature list defines the scope plainly. Structured events with external contributors whose proposals need to be collected, reviewed and scheduled are the target. A team running weekly internal meetings gets the same architecture at a setup cost that does not match the task.

Flask, SQLAlchemy and Celery form the three server layers

Indico is a Flask application. The pyproject.toml classifiers list Flask explicitly as the framework, and the repository topics include sqlalchemy, confirming SQLAlchemy as the ORM layer. Background tasks run through Celery 5.6.3, listed in requirements.txt, handling deferred work such as notification emails and PDF badge generation that cannot finish inside a synchronous web request. Alembic 1.19.0, also in requirements.txt, manages database schema migrations as the data model changes across versions.

Frontend assets are compiled by Webpack, with two configuration files at the repository root: webpack.config.mjs covers the core bundle and plugin.webpack.config.mjs is the entry point for plugin authors who extend the frontend independently. Package.json dependencies include @tinymce/tinymce-react for rich text editing in abstract submissions, @monaco-editor/react for code display, and fullcalendar ^6.1.8 for the timetable interface. WeasyPrint handles PDF output for badges and exportable schedules. Leaflet ^1.8.0, leaflet-draw ^1.0.4 and leaflet.markercluster ^1.5.3 are listed in package.json for the room booking map interface.

Developers who inspect package.json to find the product version get a misleading number: package.json declares "version": "2.0.0" as a static label for the npm package, but the actual product version is tracked in indico/__init__.py as specified by version = { path = 'indico/__init__.py' } in pyproject.toml, and the two numbers have no connection to each other. GitHub releases show v3.3.13 as the current product version, far above the 2.0.0 that package.json reports.

Python 3.12.2 to <3.13 is the only supported interpreter range

Pyproject.toml states requires-python = '>=3.12.2, <3.13'. Any Python version earlier than 3.12.2 falls below the minimum, and Python 3.13 is excluded by the upper bound. Classifiers in pyproject.toml list only Programming Language :: Python :: 3.12, with no entry for any earlier or later version, so the constraint is deliberate and documented, not accidental.

A server running a distribution that ships an older Python by default requires a separate Python 3.12 installation outside the distribution package manager. No migration timeline for expanding this constraint appears in the repository files.

Build uses hatchling 1.31.0 as the backend. The constraint applies to every deployed instance and to any environment that imports Indico as a library, so any deployment plan starts with confirming the Python version.

PyPI hosts the package; the CLI registers at indico.cli.core:cli

Two links cover getting Indico in the README: one points to getindico.io/getting-started/ and the other to docs.getindico.io/en/stable/installation/, where platform-specific setup guides live. No install command appears in the repository README, and no Docker Compose file appears in the top-level directory listing.

Indico is available on PyPI under the name indico, as confirmed by the PyPI badge in the README. After a successful install, the registered CLI entry point is indico, mapping to indico.cli.core:cli as declared under [project.scripts] in pyproject.toml. The full initialization sequence lives in the external documentation, not in the repository README.

The sandbox at sandbox.getindico.io hosts a live copy of the interface for anyone who wants to test before setting up locally. The README names this directly under the heading 'I just want to try it out!' with a link to that URL.

Abstract submission, paper review, timetable and badge printing are separate modules

Conference preparation in Indico follows a sequence of modules, each covering a distinct stage. A call for abstracts module collects submissions from external contributors and routes them into an abstract reviewing workflow. A separate paper reviewing workflow handles the stage where accepted abstracts become full papers requiring additional assessment; the README lists these two workflows as distinct items because each workflow runs at a different point in the conference timeline.

Registration form creation gives organizers configurable custom fields for participant data collection. Payment system integration connects those forms to existing payment infrastructure, though the README identifies this as a feature without naming any specific payment systems.

After reviewing, a drag-and-drop timetable interface places accepted sessions into time slots and tracks. A badge editor then generates printable output for participants and staff: the README covers both badges and tickets as separate outputs, since staff and attendees often carry different printed materials. WeasyPrint in requirements.txt is the PDF rendering dependency that converts editor output into printable files.

Room booking uses Leaflet dependencies; video conferencing integration stops at a single phrase

Room booking is a module with its own map-based interface. Room booking is listed as a feature in the README. Leaflet ^1.8.0, leaflet-draw ^1.0.4 and leaflet.markercluster ^1.5.3 appear in package.json as the corresponding frontend dependencies for the map-based interface. Capacity limits, equipment tracking and permission layers are not documented in the repository-level files, so the external documentation at docs.getindico.io is the only resource for those details.

Video conferencing integration appears in the README as 'integration with existing video conferencing solutions', and that is the complete description at the repository level. No platform name, no API key configuration, no plugin reference and no protocol information appear in the README or the top-level directory listing. Verify support for a specific platform in the documentation at docs.getindico.io or at the project forum before depending on this feature.

Internationalization spans Transifex, two Babel config files and a dedicated Makefile lint target

Indico's i18n setup involves several parts of the repository working in tandem. At the root, babel.cfg and babel-js.cfg configure message extraction for Python and JavaScript code respectively. The .tx/ directory follows the standard layout for a Transifex project configuration, which coordinates translation strings across language teams. Flask-babel in requirements.txt handles runtime localization within the Flask layer.

A Makefile target named make lint-i18n-check validates i18n format strings and HTML tags, according to the Makefile's own comments. Running make lint before a pull request submission catches format string mismatches between source strings and translated strings. That target runs alongside Python linting with ruff, JavaScript linting with Biome, CSS linting and file header checks; make lint runs all of them together.

The last push to the repository was on 2026-10-06 and v3.3.13 is the most recent product release, published 2026-08-25, under the MIT licence.

Editorial conclusion

Indico suits institutions that run events with external abstract submissions, multi-stage reviewing and custom registration workflows, and can maintain a Python 3.12.2 through 3.12.x environment. Organizations that only need a meeting scheduler or a room calendar will find the architecture oversized for that purpose. Self-hosting is the deployment model, and the Python constraint in pyproject.toml is the first thing to verify: requires-python = '>=3.12.2, <3.13' means Python 3.11 is out and 3.13 is excluded. Check that constraint before reading the setup guide at docs.getindico.io/en/stable/installation/.

Frequently asked questions

Official sources

1. indico/indico on GitHub
2. License: MIT
3. Project website
4. README
5. Releases