# RootTheBox: a CTF scoreboard with game mechanics bolted on

> RootTheBox is a real-time capture the flag scoring engine that treats a competition as a game: teams capture flags, unlock upgrades, bank in-game money, and watch a websockets-driven scoreboard. It is a Python application with a SQLite default, shipped as a Docker image with memcached alongside it.

**moloch--/RootTheBox** — A Game of Hackers (CTF Scoreboard & Game Manager)

- Repository: https://github.com/moloch--/RootTheBox
- Website: http://root-the-box.com/
- Stars: 1,140 · Forks: 331
- Language: Python
- License: Apache-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/moloch-rootthebox

## A scoreboard that is also a game

RootTheBox is a real-time capture the flag scoring engine for computer wargames where hackers can practise and learn. The application can be easily configured and modified for any CTF style game, and the platform is meant to engage novice and experienced players alike by combining a fun, game-like environment with realistic challenges that convey knowledge applicable to the real world, such as penetration testing, incident response, digital forensics and threat hunting.

That sentence names the design decision. A conventional CTF platform is a scoreboard with a flag submission form, and the realism comes from the challenges. RootTheBox keeps the realistic challenges and adds the game around them, which is why the project describes itself as a game manager as much as a scoring engine.

The game layer is what distinguishes the feature list. There is optional story mode, with an intro dialog and capture flag or section dialogs with graphics, and there are optional advanced features including in-game botnets, SWAT players, banking of in-game money, and a wall of sheep displaying cracked passwords. There are unlocks and upgrades as users capture flags, which is a progression system borrowed from a game rather than from a competition. The chat support, the site themes and the multiple language support are the finishing touches of something meant to be used for hours at a time.

There is also the machinery of a real event: built-in team based file and text sharing, admin game material distribution, export and sharing of boxes and flags, and the option to freeze the scoreboard at a specific time to allow for an end game countdown.

The project is Apache-2.0 licensed, the primary language is Python, the default branch is `master`, the homepage is `root-the-box.com`, and the last push was on 2026-09-03. The recent releases are 3.14.0 from 2024-03-25, 3.13.0 from 2023-03-12 and 3.12.4 from 2023-01-27, and the project is not archived.

## Flag types and the scoring knobs

The scoring engine is configurable in two directions, and it is worth understanding both, because they are what an event organiser actually spends time on.

The first is the flag type. There are five: Static, Regex, Datetime, Multiple Choice and File, with options for case sensitivity. A static flag is a fixed string, a regex flag accepts anything matching a pattern, a datetime flag is a value the player has to find rather than guess, a multiple choice flag is a question, and a file flag means the player has to retrieve a file. Each of those is a different kind of puzzle, and the difference between a static flag and a regex flag is the difference between a lookup and a search, which changes how a challenge is written and how it is solved.

The second is the scoring configuration, and the list is long: options for penalties, hints, attempts, level bonuses, dynamic scoring, categories and more. Penalties and attempts are the classic capture the flag mechanics, a wrong answer costs points or a life. Hints cost points or reveal part of the answer. Level bonuses reward a player for completing a set of challenges rather than a single one. Dynamic scoring is the mechanism for a challenge whose value changes over time, which is what keeps a scoreboard alive in the last hour of an event.

Taken together, this is a fairly complete description of what a capture the flag needs in order to be a game rather than a checklist, and it is the part of the project that an organiser will spend the most time in the admin interface.

## Real time means websockets, graphs and a scoreboard you can freeze

The real-time claim is the technical centre of the project, and it is built on websockets. The feature list names a real-time animated scoreboard, graphs and status updates using websockets, which is a choice that matters at the scale of a live event: a page that polls for a scoreboard refreshes visibly and generates load, and a page that receives the updates does neither.

The websockets are also what the console and the graphs consume, and the Docker deployment runs a memcached service beside the application.

Two of the features exist purely to make the event work. The scoreboard can be frozen at a specific time, which allows for an end game countdown, and that is a small feature that solves a real problem, because a live scoreboard that keeps updating after the closing ceremony is a problem nobody has to have. The CTF Time compatible JSON scoreboard feed is the other, and it is the integration that lets a competition appear on a public results site without anybody having to re-enter the numbers.

The export list is what an organiser uses afterwards. There is support for the OWASP Juice Shop CTF export, which means a game built around that deliberately vulnerable application can be scored from a RootTheBox instance, and boxes and flags can be exported and shared, so a set of challenges can be reused in the next event instead of being written again.

## The game layer: botnets, SWAT players and a wall of sheep

The optional advanced features are what turn a scoreboard into a game, and they are described in the README as in-game botnets, SWAT players, banking of in-game money, and a wall of sheep displaying cracked passwords.

Each of these maps to a familiar game mechanic, and each of them also adds a rule to the competition. In-game botnets mean a player can take actions against other players, which turns the scoreboard into a contested environment. SWAT players are the opposite, an in-game role that can be unlocked or upgraded. Banking means points can be stored rather than spent immediately, which is what makes the unlocks and upgrades a decision rather than a reward. And the wall of sheep displays cracked passwords, which is the joke that makes the theme coherent.

The features are optional, which is the right call for a platform that has to serve a training exercise as well as a public event, and the README links a wiki page listing the advanced features separately from the main list.

Two integrations in the same spirit round it off. CyberChef is integrated in the tools menu, which is a small thing that removes a very common friction, since a challenge that needs an encoding conversion should not require the player to leave the site. And chat support is built in, with optional Rocket Chat integration for events that already run their own chat server.

The result is a platform with a fairly large surface, and an organiser should keep in mind that the more of it they enable, the more there is to configure before the event starts.

## The Docker image runs SQLite and expects memcached beside it

The deployment artefacts in the repository are small and tell you the shape of a real installation.

The compose file is the whole of it:

```yaml
services:
  memcached:
    image: memcached:latest
    ports:
      - "11211:11211"
  webapp:
    build: .
    ports:
      - "8888:8888"
    volumes:
      - ./files:/opt/rtb/files:rw
    environment:
      - COMPOSE_CONVERT_WINDOWS_PATHS=1
```

Two services, the application and a cache, with the files directory mounted so that uploaded material survives a container rebuild. The `COMPOSE_CONVERT_WINDOWS_PATHS` variable is there because the same compose file is used from Windows, where the volume path has to be rewritten.

The `Dockerfile` shows the runtime assumptions:

```dockerfile
FROM python:3.8

RUN mkdir /opt/rtb
ADD . /opt/rtb

RUN apt-get update && apt-get install -y \
build-essential zlib1g-dev rustc \
python3-pycurl sqlite3 libsqlite3-dev 

ENV SQL_DIALECT=sqlite

VOLUME ["/opt/rtb/files"]
ENTRYPOINT ["python3", "/opt/rtb/rootthebox.py", "--setup=docker"]
```

The base image is Python 3.8, which is worth noticing in a project whose last release was in 2024. The system packages are the build dependencies, including rustc, which suggests a dependency with a native component that has to be compiled. `SQL_DIALECT=sqlite` is the default database, and the entrypoint runs the single script `rootthebox.py` with a `--setup=docker` flag, so the whole application is one Python entry point with a mode for container start-up.

The repository layout supports that shape. There is `rootthebox.py` at the root, then `handlers/`, `models/`, `modules/` and `libs/` for the application, `templates/` and `static/` for the web layer, `locale/` for the translations, `alembic/` for the database migrations, `setup/` for the requirements, `tests/`, a `bot/` directory, a `cyberchef/` directory and a `files/` directory for the uploaded material. There is also a `.devcontainer/` directory and a `Dockerfile` for people who prefer the container to the compose file.

## Running one, and the demo you can look at first

There is no install command in the README, and that is deliberate, because the setup lives in the wiki. The platform requirements are stated plainly: Python 3, PyPy or Docker, and install scripts for Ubuntu 18.04 or later, or for Debian, although the application should work on any recent Linux, BSD, macOS or Windows system.

The advice for a new organiser is to look at the demo first. The README links a live demo instance and warns that it may take a few seconds to wake up, and that the example accounts should not have their passwords changed, though registering a new user is welcome. The credentials are published, and they are the published credentials of a demonstration instance:

```text
Admin Username `admin` Password `rootthebox`
Player Username `player` Password `rootthebox`
```

Publishing them is the right call for a demo, and it is worth noticing that the demo is a different deployment from a real event, since it is presumably configured with a temporary database and a small set of boxes.

The three deployment routes in the feature list are the cloud, Docker, or direct installation, each with a wiki page, and the direct route is the one where the install scripts come into play. The wiki also holds the screenshots and the game examples, and the contributing guidelines are there too, with the project explicitly welcoming code contributions, and the issue tracker open for questions, problems and feature requests.

For a team that has never run a capture the flag, the order that works is the demo, then the wiki installation page, then Docker, and only then the direct install, because the Docker route has the fewest unknowns about the host.

## Where RootTheBox is the wrong tool

The limits are the ones that come from choosing a game over a scoreboard, and they are worth being blunt about.

The first is that it does not author challenges. RootTheBox is the scoring engine and the game manager, and the boxes, the flags and the story have to come from somewhere. A team that wants a platform where the challenges are already written and the participants are students who will never configure anything is looking at the wrong project, and a team running an event for experienced players may find that the game layer is decoration on top of a competition that was better without it.

The second is the deployment shape. A single web application, a memcached instance and, by default, a SQLite database is an arrangement that works for a training exercise and for a modest event. It is not a clustered scoring service, and the compatibility between the websockets, the cache and the database is exactly the kind of arrangement that has to be sized by hand when several hundred teams are connected at once.

The third is the age of the base image and the release line. The Docker image is built on Python 3.8, which is past its support window, and the newest published release is 3.14.0 from March 2024 while the repository has been moving since. The code is not archived, so the project is alive, but a deployment is being built on an image and a dependency set that were chosen two years ago.

The alternative for a small exercise is a plain scoreboard, a shared document and a script that posts the results, which is what a lot of internal training events actually use. The difference in approach is that RootTheBox is a game with scoring, progression and story, and the alternative is a list with a countdown. A team that wants the game takes the deployment; a team that wants the list should not.

For a serious public competition, the more likely comparison is with a purpose-built event platform with an audited scoring service, and the difference there is not features but guarantees, because a scoreboard that decides a prize needs to be boring rather than entertaining.

## Conclusion

RootTheBox fits a training team or an event organiser who wants a capture the flag that feels like a game rather than a spreadsheet, and who is prepared to author the challenges and boxes themselves. It is the wrong choice for a small internal exercise, where a plain scoreboard and a shared document do the same job with none of the deployment, and it is the wrong choice for a competition that needs audited, high-volume scoring, because the project presents itself as a game manager first. Before deploying it, read the wiki's installation page for your platform, and note that the Docker image is based on Python 3.8 and the compose file defaults to SQLite with memcached beside it, so a real event with concurrent teams needs the database and cache settings decided in advance rather than inherited from the example.

## FAQ

### What is RootTheBox?

It is a real-time capture the flag scoring engine and game manager for computer wargames, under the Apache 2.0 licence. It supports team or individual play, a websockets-driven animated scoreboard with graphs, several flag types, and optional game mechanics such as in-game botnets, SWAT players and banking.

### How do I run RootTheBox with Docker?

The compose file starts a memcached service on port 11211 and a webapp built from the Dockerfile on port 8888, with the files directory mounted at /opt/rtb/files. The image is based on python:3.8, installs the requirements with SQL_DIALECT=sqlite, and runs rootthebox.py with the --setup=docker argument.

### Which flag types does RootTheBox support?

Static, Regex, Datetime, Multiple Choice and File, with options for case sensitivity. Scoring is configured with penalties, hints, attempts, level bonuses, dynamic scoring and categories, and the scoreboard can be frozen at a set time for an end game countdown.

### Does RootTheBox integrate with external CTF services?

Yes. There is a CTF Time compatible JSON scoreboard feed, an OWASP Juice Shop CTF export, optional Rocket Chat integration for chat, and CyberChef in the tools menu. The demo instance is linked from the README with published admin and player accounts.

## Sources

- [License: Apache-2.0](https://github.com/moloch--/RootTheBox/blob/master/LICENSE)
- [moloch--/RootTheBox on GitHub](https://github.com/moloch--/RootTheBox)
- [Project website](http://root-the-box.com/)
- [README](https://github.com/moloch--/RootTheBox/blob/master/README.md)
- [Releases](https://github.com/moloch--/RootTheBox/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/moloch-rootthebox