DMOJ online judge, a contest platform built for schools and olympiads

A contest system, not a problem archive

The project describes itself as a modern open source online judge and contest platform system, and the documentation notes it has been used to host thousands of competitions, including several national olympiads. That framing matters, because the majority of the feature list is contest machinery rather than a problem browser. There is an optional rating system, contests can be restricted to particular organizations or require access codes to join, scoreboards can be hidden, and users can keep participating virtually after a contest has ended. Editorials are built in and are published automatically once a contest ends. The plagiarism checking integrates with Stanford MOSS. The contest formats for ICPC, IOI, AtCoder and ECOO work out of the box, and new formats can be added with custom code. The audience is an organiser running a real competition with real rules, and the site at dmoj.ca is a working instance of that.

The judging backend is a separate project

The judging machinery is split out, and understanding that split tells you what this repository contains. The supported runtimes are documented in a separate repository, DMOJ/judge-server, which holds the list of more than sixty supported platforms and the backend details, and the site links there for the authoritative list. The languages named in the project documentation include C++ 11 through 23 with GCC and Clang, C 99, 11 and 23, Java 8 and 25, Python 2 and 3, PyPy 2 and 3, Pascal, and Mono with C#, F# and VB. The capabilities listed for the judging system cover interactive tasks, signature graded tasks, runtime data generators, custom output validators, and per-language resource limits, and the documentation claims the design scales to hundreds of judging servers. The site repository still carries a judge/ directory, so both halves live in the same organisation, but the runtime catalogue changes on a different clock from the site code.

Rating, hidden scoreboards and virtual participation

The rating system is described as Elo-MMR style, following the paper on that method, and it is optional per contest. A contest can be configured to run in any timeframe, which is how a school running a one week event and a regional body running a five hour contest can use the same software. The most operationally interesting feature is virtual participation, where users continue to submit after the official end. That changes what a contest ends to mean, and it is a scheduling decision for the organiser rather than a default the platform imposes. The judge side has a matching notion of system testing, where problems are checked against the complete test set rather than a sample, and submissions to a problem are live, with the global, per problem and per contest lists updating as they come in and filterable by status and language.

Django, Celery and a long list of pinned dependencies

The dependency list in requirements.txt is a good map of the design, and the first line sets the floor: Django 4.2 with an upper bound below 5.

Django>=4.2,<5
django_compressor>=3
django-mptt>=0.13
django-registration-redux>=2.10
django-reversion>=5
django-social-share
django-sortedm2m>=3.1.0
django-impersonate

Asynchronous work goes through celery, and pika is the AMQP client, which tells you the site expects a message broker for judging work rather than doing it in the request cycle. The rest of the list explains the visible features. social-auth-core and social-auth-app-django provide the OAuth login with Google, Facebook and Github, pyotp and qrcode provide the two factor authentication, webauthn provides the passkey path, django-fernet-fields handles encrypted fields, pymoss wraps the plagiarism service, mistune and bleach handle Markdown and sanitising, lupa and llist provide Lua and linked list support, and django-statici18n and the locale/ directory hold the internationalised interface. A few pins are explicit about age, with packaging held below 22 and importlib-metadata below 5 because a newer major release of a Celery dependency breaks things.

Where the site code lives

The directory listing is the architecture. The dmoj/ package holds the application, and it is surrounded by the pieces a large Django project accumulates: templates/ for the HTML, locale/ for translations, resources/ for static assets, and the third party packages vendored into the tree, django_ace/ for the editor component and martor/ for the Markdown editor used in problem statements. Three top level scripts describe the runtime shape. manage.py is the Django entry point, dmoj_celery.py is the Celery application for the background workers, and dmoj_bridge_async.py bridges asynchronous results back into the site. The websocket/ directory is how live submission updates reach the browser without polling, and the separate judge/ directory and .gitmodules file show that the judging components are pulled in rather than written here. The .ci.settings.py, .flake8, codecov.yml and .browserslistrc files are the continuous integration and front end build configuration, and make_style.sh is a small style helper.

Problem statements, editorials and the admin surface

Problem statements are written in Markdown with LaTeX enabled math and figures and syntax highlighting, and they can be saved as PDF for distribution to contestants, which removes a whole category of manual work for an organiser. The site picks the most relevant statement language for a reader when an author has provided several, and the internationalised interface extends past the chrome to the problem text, with a separate translate.dmoj.ca site tracking translation status. Submissions can be aborted by their author or by an administrator, which matters when a judge queue backs up. Compilation errors and warnings for a number of languages get colour highlighting, so a contestant can see at a glance what their build complained about. The administration interface is the other half of the product, described as versatile enough to run from managing users to authoring problem statements, with fine-grained permission control for staff.

An AGPL site with a three year old tag

The licence is the GNU Affero General Public License version 3, which for a web application carries the network use condition, and that is a fact a deploying organisation has to look at rather than assume. The release history is the other thing to look at. The newest tagged site release is v4.0.0 from 2023-01-23, preceded by v2.1.1 from 2020-10-17 and v2.1.0 from 2020-05-11, while the last push to the default branch was on 2026-10-11, so the branch has moved a long way past the last tag. Installation is documentation driven rather than scripted: the project points at the install documentation hosted at docs.dmoj.ca and offers a Discord channel for questions. That combination, an active branch with a dated tag, means an operator has to decide deliberately whether to run a tagged release or a branch commit, and to keep the site and the judge-server repository in step with each other, because the two deliver the same service from separate code bases.

Editorial conclusion

DMOJ fits a school, university or regional organiser who wants a full contest system rather than a problem archive, and it fits a site operator who needs interactive tasks, custom validators and per-language resource limits without writing a judge. It does not fit a person who only wants to run problems, since the platform is large and the install path is documentation driven rather than one command, and it does not fit an organisation that needs a support commitment, because the newest tagged release dates from January 2023 while the master branch keeps moving. Verify three things first: which judge-server version pairs with the site version you are installing, whether the licence terms suit your deployment, since it is AGPL, and how much of your own infrastructure you are willing to run, given the site, the judge and the message queue all have to be up together.

Frequently asked questions

Official sources

1. DMOJ/online-judge on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases