Skip to content


Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time


This is the platform for TJCTF. It's (what I think is) the best of the MITRE, CTFd, and picoCTF platforms rolled up into a Flask application.

I'm bad at naming things.


You're going to want to edit The variable names should be fairly self-explanatory.

You're going to want to create a file called secrets. It will look like this:

mailgun_key: key-asdflkjasdhflkjsdahflkhsdaklfjhasd
recaptcha_key: asdlkfjhasdlkjfhlsdakjfh
recaptcha_secret: sdakjfhsdalkfjhsdalkfjh
key: this can be anything you want, it is your flask secret_key

You should edit line 2 of, unless you want to use SQLite. This uses Peewee, so you can use any Peewee-supported database.

You can create some problem YAML files that look like this:

name: Problem Name
author: ME!
category: Binary
description: binary binary binary binary. i love binary
points: 250
flags: "flag{whatever}"

Then add them with ./ctftool add-challenge problem.yml and it'll get put in the database.

Run python and you have a server running. You probably want to deploy it with gunicorn or similar, long-term.


You can do some really fancy stuff with ctftool. If you have a directory structure like this:

  • ctf-platform
  • ctf-problems
    • problem1
      • problem.yml
      • static.yml
    • problem2
      • problem.yml
      • static.yml
    • problem3
      • problem.yml
    • problem4

You can run ./ctftool scan ../ctf-problems/ and get a fully populated database with information from all the problem.yml files, and automatically generated static file names, and automatic substitutions for static file links in problem.yml. More documentation on this to come soon.


Flagbase is under really heavy development right now. That means

  • Absolutely do submit issues: bugs and feature requests are awesome.

  • Don't submit a pull request for:

    • a major feature addition
    • database model changes
  • Do submit pull requests for:

    • documentation addition/edits
    • minor bugfixes
    • small changes to existing features

If you're touching or, you're probably doing it wrong.

If you decide to ignore my guidelines, write detailed documentation on what your pull request consists of, what problems it fixes, how it works, and what issues it could bring up.

Of course, you are more than welcome to fork the repository.