Running a CTF means coordinating organizers and challenge authors while keeping the infrastructure stable and players informed. These guides cover the work from early planning through teardown, including mistakes that tend to repeat.

Before building challenges or deploying infrastructure, decide who is responsible for each part of the event, set a schedule, and establish how participants will get information and support.

Organizational structure

A small team can run a strong event, but every important job needs a clear owner.

• Organizers own the schedule, final decisions, sponsor relationships, merchandise, and prizes.
• Challenge authors build challenges and playtest one another’s work.
• Infrastructure leads deploy the platform and challenges, monitor them during the event, and respond to security or capacity problems. For a long event, rotate this responsibility so someone with access is always available.
• Support team members answer participant tickets and bring challenge or infrastructure problems to the right person.

Timeline

Start at least two or three months before the event. One workable schedule is:

• Three months out, choose the date, outline the challenges, contact sponsors, and start the CTFtime registration.
• Two months out, begin writing challenges.
• Two weeks out, freeze new challenge ideas and focus on playtesting, revisions, platform setup, and infrastructure testing.
• One week out, finalize every challenge, open registration, announce the event, and prepare Discord for participants.

CTFtime

CTFtime is where most teams discover upcoming CTFs and track their results. Check its calendar before choosing a date, then list the event early enough for the registration to be approved.

Listing a CTF takes three steps:

1. Create a team. The same team can compete in and organize events.
2. Register the event series, such as “My CTF.” The CTFtime team reviews this manually, so submit it well before the event.
3. Add an edition for the specific competition, such as “My CTF 2026.”

After the event, upload the final scoreboard so teams receive CTFtime ranking points. Competitors also vote on the event’s weight, which can increase as the event establishes a history.

Homepage

The homepage is the first thing participants see. It should cover event timing, rules, prizes, sponsors, and anything else worth surfacing up front.

Rules

Publish the rules before registration opens. A reasonable starting point is:

• There is no team limit.*
• Do not attack or interfere with other teams, the competition infrastructure, or other competitors.
• Do not share flags, solutions, or hints with other teams.
• Do not discuss challenges with other teams until the CTF is over.
• Do not attempt to brute-force flags or flag submission endpoints.
• Do not use automated tools or scanners against competition infrastructure.
• Each player may only be a member of one team. Do not register multiple accounts.
• Tiebreakers are resolved by the timestamp of the last solve that brought the team to their final score.
• Violating any of the above rules may result in disqualification at the discretion of the organizers.

Sponsorships and prizes

Prizes are optional, though many events reward the top three teams or strong post-event writeups. Sponsors often cover those costs.

When looking for sponsors:

• Start two or three months ahead. Approval can take time.
• Prepare a short proposal with the event audience, expected participation, sponsor benefits, and a few funding levels.
• Begin with companies and organizations that already support security events or have worked with your team.

Possible starting points include:

• OtterSec
• GCP credits for CTF infrastructure by Google
• Sponsor lists from upcoming and past CTFs

Common sponsor benefits include:

• Logo placement on the CTF homepage and merchandise, if applicable
• Shoutouts on social media and announcement channels
• A challenge written by the sponsor or built around one of its tools, when that fits the event
• A talk or booth at an onsite event

Communication

Discord setup

Most CTFs use Discord as the main communication channel for announcements, support, and post-event discussion.

A typical Discord server configuration for a CTF includes the following channels:

Keep support in one place instead of answering direct messages. A ticket channel gives the team a shared record of platform problems, broken challenges, incorrect flags, and hint requests.

Hints

When a participant reports a challenge problem, confirm that the live service and reference solution still work. Do not reveal anything about the intended solution.

If you need to publish a hint or clarification, follow the hint policy.

Set the event format before authors begin. For a typical online jeopardy CTF:

• Run for 24 or 48 hours, usually over a weekend.

• Use recognizable CTF categories.

• Aim for two to six challenges per category and avoid leaving one category noticeably thinner than the others.

• Include a real range of difficulty. One or two easy, two or three medium, and one or two hard challenges per category is a useful starting point.

Challenge authoring

Good challenges are what make a CTF worth playing. Keep these guidelines in mind during development.

General principles

• Write original challenges. Reused problems are often searchable or recognizable.

• Give solvers enough information to make reasoned progress. If the only way forward is to guess what the author had in mind or try arbitrary inputs, the challenge is unclear rather than difficult. An unsolved challenge is usually a reason to revisit the design.

• Make sure the intended solution fits the length of the event.

• Do not use fake clues or red herrings.

• Give each challenge a technical idea worth learning or practicing.

Challenge components

Each challenge should include the following:

Dockerization

Package remote challenges as containers so the same build can be tested, deployed, and reproduced after the event.

Best practices

• Keep one challenge per container so each challenge stays self-contained. If a challenge requires multiple services (e.g., a web app and a database), use Docker Compose.
• Reach for minimal base images like alpine or debian-slim to reduce build times and attack surface.
• Build artifacts separately with multi-stage builds, compiling binaries in one stage and copying only the final artifact into the runtime image.
• Run challenge services as non-root users inside the container to limit the impact of container escapes.
• Use a read-only filesystem where possible by mounting the root filesystem as read-only (readOnly: true or --read-only) and using a tmpfs for writable directories.

Security defaults

When deploying challenges, apply the following security settings:

• cap_drop: ALL drops all Linux capabilities.
• no-new-privileges: true prevents privilege escalation.
• Memory and PID limits prevent resource exhaustion (e.g., fork bombs).
• Network isolation uses internal networks for multi-container challenges where services should not be directly reachable.

Example Dockerfile

1
FROM python:3.12-slim
2

3
RUN useradd -m ctf
4
WORKDIR /home/ctf
5

6
COPY requirements.txt .
7
RUN pip install --no-cache-dir -r requirements.txt
8

9
COPY app.py flag.txt ./
10
RUN chmod 444 flag.txt
11

12
USER ctf
13
EXPOSE 5000
14
CMD ["python", "app.py"]

Using with rCTF instancer

With the rCTF Docker instancer, describe the challenge services in instancerConfig. The instancer creates the containers and network for each team, then removes them when the instance expires.

Pre-event checklist

Before the event, verify the following for each challenge:

• The challenge is solvable with the provided materials. Where it fits, ship a single solve.py that outputs the flag.
• The challenge has been playtested internally. Two playtesters per challenge is the safer bet.
• The flag is correct and matches the expected format.
• The files are correctly packaged and downloadable. Double-check that the files are the right versions, since authors sometimes update source code without re-packaging the distribution zip.
• The remote services are accessible and stable.
• The Docker containers build and run correctly.
• The solution or writeup is documented internally and accessible to the support team.

This walkthrough installs rCTF on an Ubuntu VPS, puts Nginx in front of it, and enables TLS through Cloudflare or Certbot.

Prerequisites

You will need:

• A domain name, such as example.com
• An Ubuntu 24.04 VPS with at least 2 CPU cores and 4 GiB of memory

The TLS steps cover either a proxied Cloudflare hostname or a certificate issued with Certbot.

Installing rCTF

Setting up the web server

rCTF listens only on the VPS loopback address. Nginx terminates TLS and forwards public traffic to it. Cloudflare can sit in front of Nginx for proxying and DDoS protection.

Creating an admin account

Hosted challenges use either a shared remote, which every team connects to, or an instanced remote, which gives each team a separate environment.

Admin bots should run separately from challenge services. This keeps browser traffic outside the challenge network and lets bot workers scale independently.

Shared remote

In a shared remote, every team connects to the same service. Use one when solves do not alter shared state, or when each connection runs inside its own sandbox. A cryptographic oracle is a common example.

kCTF runs shared challenges on GCP with autoscaling, health checks, automatic restarts, and per-connection sandboxing. A dedicated VPS running Docker is simpler, but you must provide the isolation and resource limits yourself.

kCTF

kCTF has its own documentation, so this section focuses on the things that aren’t immediately obvious, especially for first-time users:

• Set the challenge domain with --domain-name when you run kctf cluster create. To use *.example.com, use Google nameservers for the domain. To use *.subdomain.example.com, add NS records that delegate the subdomain to Google.
• By default, the created nodes are spot (preemptible) instances. This means the nodes rotate every 24 hours, with brief downtime each time. To avoid this, resize the cluster without the spot instance flag (e.g., kctf cluster resize --min-nodes 1 --max-nodes 3 --num-nodes 1 --machine-type n2-standard-4), at slightly higher cost.
• If a health check fails, the challenge restarts automatically, which can look like a connectivity issue from the outside. Run kctf chal status to see what’s actually going on.
• Watch your GCP project’s quotas. The dashboard shows which limits have been hit or are getting close. Deploying a lot of challenges can fail because of insufficient IP addresses or other quota constraints. Setting up kCTF early is a practical way to verify your quotas are sufficient, and it may improve your account’s standing for automatic quota increase approvals.
• Some challenges deployed to kCTF need extra changes because of the security hardening. Standing up kCTF early lets you catch and fix these before the competition starts. The Kubernetes Pods documentation covers the configurable options for kCTF challenge instances (for example, additional volumes, since the file system is read-only by default).

Docker

For a smaller setup, run Docker on one or more dedicated hosts. Do not put intentionally vulnerable challenges on the server that holds the rCTF database or participant data. Challenge traffic and a container escape should not be able to take down or expose the platform.

Docker Compose is enough for a small set of shared services, with each challenge on its own port. A container alone is not a safe boundary for an RCE challenge, especially if it has extra privileges. Put the vulnerable process inside pwn.red/jail or nsjail and set storage and process limits.

VM

Another option is to give each challenge instance its own VM or VPS. This costs more, but a compromised challenge is less likely to affect the rest of the event through disk exhaustion, a container escape, or a host failure. Block access to the cloud metadata service on these hosts as well. Choose the level of isolation based on the risks and resource needs of each challenge.

Instanced remote

An instanced remote gives each team its own environment. Use it when a solve changes persistent state, writes files, or gives broad code execution that cannot be safely reset after every connection.

rCTF provides two instancer backends:

• Docker instancer is a bundled Python FastAPI service that runs on a standalone Docker host alongside Traefik and Redis. It’s lightweight and a good fit for small-to-medium events.
• Kubernetes instancer runs each team instance in its own namespace with network policies and Traefik routing. It includes a Terraform deployment for GKE and is intended for events that need several challenge nodes.

The instancer overview explains the shared instancerConfig fields, participant controls, and admin UI.

Existing systems such as Klodd can still integrate with rCTF.

Admin bot

The rCTF admin bot runs trusted TypeScript handlers in Chrome or Firefox. It validates participant input, queues browser visits, and returns logs for each job. Run the worker separately from the challenge so browser capacity can scale without exposing the worker service publicly.

Keeping challenges in sync

Deploy source, attachments, images, and instancerConfig from the same revision. Updating them separately makes it easy to publish a binary that no longer matches the remote service or reference solution.

Generate attachments from the challenge build and reference the output through attachments.files. Konata archives that output on each sync, while rCTF skips the upload when its contents have not changed.

The SekaiCTF 2026 challenge repository shows this workflow with Konata, Kubernetes, instanced challenges, and dynamic scoring.

During the event, the team needs to watch the platform, respond to failures, and make consistent decisions about broken challenges and hints.

Monitoring

Watch the services participants depend on, and make sure alerts reach someone who can act:

• For the rCTF API, watch error rates, latency, CPU, and memory.
• For PostgreSQL, watch connection usage, slow queries, and disk space. A steadily rising connection count can point to a leak.
• For Redis, watch memory and connected clients. If Redis fails, leaderboard caching and rate limiting are affected.
• For challenge containers, watch CPU, memory, network traffic, restarts, and disk use.
• For the reverse proxy, watch request volume, 5xx responses, and latency. If Cloudflare is in front, include its traffic and DDoS dashboards.

Staffing and shift coverage

For events longer than 12 hours, rotate shifts and keep someone with infrastructure access on call at all times. When a challenge author is offline, the support team should still have the reference solution and enough notes to investigate tickets.

Incident response

Decide who can change infrastructure, challenges, and the event schedule before an incident happens.

Challenge outages

If a challenge becomes unavailable, the response depends on the deployment method:

• For Docker containers, check container status with docker ps and logs with docker logs <container>. Restart with docker compose up -d --force-recreate <service> if needed.
• For instancer-managed challenges, verify the instancer service is running and reachable. Check the instancer logs for errors. If individual instances are failing, the issue may be with the challenge image itself rather than the instancer.
• For static challenges (no remote), verify that challenge files are accessible through the upload provider. If using S3/GCS, check bucket permissions and CDN status.

After the fix is tested, announce that the challenge is available again and say whether its files or behavior changed.

Platform issues

If the rCTF platform itself becomes unresponsive, work through the following steps:

1. Check API server logs for crash traces, out-of-memory errors, or unhandled exceptions. If using Docker, run docker logs rctf-rctf-1.
2. Verify database connectivity by ensuring PostgreSQL is running and accepting connections. Check for connection pool exhaustion or long-running queries with docker exec -it rctf-postgres-1 psql -U rctf -c "SELECT count(*) FROM pg_stat_activity;".
3. Verify Redis connectivity by ensuring Redis is running. Run docker exec -it rctf-redis-1 redis-cli --pass "$RCTF_REDIS_PASSWORD" ping.
4. Restart the rCTF service if the issue is not immediately identifiable. Run cd /opt/rctf && docker compose restart rctf.
5. Check resource usage to verify the host has sufficient CPU, memory, and disk space. High leaderboard update frequency or large team counts can increase resource usage.

If an outage materially reduces playing time, extend the event and announce the new end time clearly.

Security incidents

For security incidents:

• For suspected flag sharing, preserve submission times, IP records, and the shared values before deciding on a penalty.
• During a denial-of-service attack, take the affected challenge offline if necessary, preserve logs, and add rate limits or blocks before restoring it.
• If a flag is leaked, rotate it in rCTF and every affected service immediately, then announce any file or service changes participants need to know about.

Challenge issues

Broken challenges

If a challenge is reported as broken, verify it first. Have the author run the intended solution against the live deployment. If it’s actually broken, work through the following steps:

1. Post an announcement acknowledging the issue and that a fix is in progress.
2. Apply the fix to the challenge.
3. Test the fix before redeploying.
4. Announce when the challenge is back online.

Unintended solutions

Accept unintended solutions unless they rely on attacking shared infrastructure or another team. Finding a valid path the author missed is part of solving the challenge.

If a deployment mistake exposes the flag directly, fix the original only when necessary for fairness or stability. A separate patched variant can preserve the intended idea, but its release may reveal what was wrong with the first version.

Attachment updates

If challenge attachments need updates (e.g., typo fixes or missing files), update the attachment and post a clear announcement spelling out what changed. Avoid changes that would invalidate existing progress.

Hint policy

Do not give private hints. If an unsolved challenge needs help, release the same information to everyone:

1. Around the halfway point of the competition, ask interested participants to open support tickets describing their current progress on unsolved challenges.
2. The challenge author reviews the submitted progress and decides whether a hint is warranted and what to provide.
3. Any approved hints must go out publicly in the #announcements channel so all participants have equal access.

Announcements

Keep communication with participants clear and timely throughout the competition. Always announce the following:

• Competition start and end reminders
• Challenge releases (if challenges are released in waves)
• Challenge fixes or updates
• Delays or extensions of the competition
• Hint releases
• Infrastructure issues and resolutions
• Survey release
• Writeups release

Keep announcements concise and informative. For time-related announcements, Discord’s timestamp formatting handles relative times across time zones.

After the event, submit the scoreboard, contact prize winners, collect feedback and writeups, publish an archive, and remove infrastructure that no longer needs to run.

Uploading scoreboard to CTFtime

Submitting the final scoreboard to CTFtime is what gives participating teams their ranking points. The procedure below exports the scoreboard in the format CTFtime expects.

Prize distribution

Contact winners through the email in the admin teams view, not through an unverified Discord account. The same view can filter teams by division for divisional prizes.

Feedback collection

A short post-event form can show what to keep and what to change. Ask about:

Writeup collection

Writeups make the challenges useful after the scoreboard closes. To encourage them:

• Announce a deadline for writeup submissions (typically one to two weeks after the event).
• Offer incentives such as prizes for outstanding writeups or recognition in official channels.
• Compile and share links to community writeups in the Discord server or on the event website.
• Release official writeups for challenges that received few or no community solutions.

Archive the platform

Before decommissioning the platform, use the static export tool to preserve challenges, profiles, solves, and the final leaderboard. Host the resulting read-only site wherever you plan to keep permanent links and writeups.

Infrastructure teardown

Scale expensive infrastructure down soon after the event. If the budget allows, keep challenge services available for a few days so participants can finish writeups and verify solutions.

Cloud credits are not a reason to leave vulnerable or forgotten services running. Keep them only while someone is still monitoring them and no sensitive data or credentials remain exposed.