How to Run a CTF Competition: A Complete Organizer Guide

Most CTFs don't fail because the challenges were bad. They fail at 10:00:03, when every team hits the scoreboard at once. Or on Sunday morning, when someone notices two teams submitted the same flag four seconds apart. Or the night before, when the person who knew how the Kubernetes cluster worked goes to sleep.

This guide covers the decisions that decide whether your event runs cleanly. It assumes you know what a CTF is and have probably played a few. It doesn't assume you've run one.

1. Pick the format before anything else

There are two formats worth considering, and they have very different costs.

Jeopardy. Teams solve standalone challenges across categories (web, crypto, pwn, reverse, forensics, misc) and earn points per solve. It's the default for a reason: challenges are independent, teams can join late, and you can run it with 20 players or 2,000. Infrastructure is mostly a web app, a database and, for some challenges, per-team containers.

Attack-Defense. Every team gets an identical vulnerable machine (a "vulnbox") running a set of services. Teams patch their own services and exploit everyone else's, stealing flags that rotate every tick. Scoring combines attack points, defense points and service availability (SLA). It's the most demanding format to play and the most demanding to host: you need a VPN per team, a checker per service, flag rotation, and a scoring engine that runs every 30–120 seconds without falling behind.

If this is your first event, run Jeopardy. If your players are experienced and you have a team to write checkers, A/D is the format they'll remember.

2. Choose a platform, not a weekend project

You have three options:

1. Self-host an open-source platform (CTFd, rCTF, GZCTF). Free in license cost, expensive in hours. Someone owns uptime, backups, TLS, scaling and container orchestration, during the event.
2. Build your own. Only worth it if the platform is the project. Every team that has done this has a story about it.
3. Use a hosted platform. You configure the event, someone else runs the servers. You trade some control for not being on call.

Whichever you pick, ask four questions: Has the scoreboard been load-tested at your team count? Are flags unique per team? What happens when you exceed a limit mid-event? Can you export every score and explain it afterwards?

3. Write challenges for the field you have

A good challenge set has a difficulty curve, not a difficulty cliff.

• Warm-ups (15–20%). Solvable by most teams in under 30 minutes. They get everyone onto the scoreboard and confirm the submission flow works.
• Core (50–60%). Where the competition happens. Each should teach or test one clear idea.
• Hard (20–30%). For the top ten teams. It's fine if one of these goes unsolved. It's not fine if five do.

Every challenge needs a written, tested solution before the event, by someone other than the author. Most "broken challenge" incidents are challenges nobody solved end-to-end on the production infrastructure.

4. Decide how points work

Static scoring fixes each challenge's value. It's predictable and suits teaching events, where you want points to reflect intended difficulty.

Dynamic scoring starts each challenge at a maximum and decays its value as more teams solve it. The field decides what was hard, which makes it the better choice for open competitions where your difficulty estimates will be wrong.

Whatever you choose, freeze the formula before the event and publish it in the rules. Changing scoring mid-event is the fastest way to lose the trust of your top teams.

5. Assume someone will share flags

In any event with prizes or rankings that matter, some teams will share flags. Static flags (one flag string for everyone) make this undetectable in real time. Your only option is comparing submissions after the event, by hand.

The reliable fix is per-team flags: each team receives a different, cryptographically derived flag for the same challenge. If team A submits team B's flag, the platform knows immediately and exactly who it came from. We cover this in depth in How to Prevent Flag Sharing.

Pair it with a review process. Automated detection should open a case, not issue a ban. Two organizers confirming each penalty protects you from false positives and from accusations of favoritism.

6. Plan for the first five minutes

The heaviest load your platform will see is the start: every player logs in, opens the challenge list and refreshes the scoreboard within the same minute. Then comes the last hour, when the scoreboard is all anyone watches.

Before the event:

• Load-test the scoreboard at 2× your expected team count, not 1×.
• Make sure the scoreboard doesn't query the database on every request. Cache it, and invalidate the cache on solves.
• Put challenge files behind a CDN or object storage, not your app server.
• Have a status channel (Discord, a status page) that doesn't depend on the platform being up.

7. Run the event like an operation

Assign roles: one person on infrastructure, one on challenge support, one on anti-cheat review, one on communications. Write down what you'll do if the scoreboard goes down, if a challenge is broken, and if you need to extend the event. Decide those calls in advance, so nobody has to make them at 3 a.m.

8. Close it out properly

After the event: freeze the scoreboard, resolve every open anti-cheat case, publish final standings, and export results (CTFtime accepts a standard JSON scoreboard). Then publish write-ups or ask teams to. That's how next year's players find you.

---

Running a CTF is mostly operations. The challenges are the part you'll enjoy. If you'd rather spend your time on those, that's what Zero Day Arena is for: per-team flags, a load-tested scoreboard and zero servers to run. Book a demo and we'll walk through your event.