Skip to content

BearcatCTF

Welcome to the BearcatCTF Infrastructure documentation. This section is designed for infrastructure engineers, CTF leads, and anyone who wants to understand how we host, scale, and automate BearcatCTF.

Our main goal is Infrastructure as Code (IaC) and Continuous Deployment. We aim to minimize manual server configuration, prevent "it works on my machine" syndrome, and ensure our systems can scale gracefully under load.

1. The Core Tech Stack

We build our infrastructure using industry-standard tools to ensure high availability, reproducibility, and automation.

AWS (Amazon Web Services)

AWS is our primary cloud provider. We use it to host both the CTFd platform and the dynamic challenges.

  • ECS (Elastic Container Service): Deployed via a hybrid approach using both Fargate and EC2 launch types. Fargate hosts the primary CTFd website, while the EC2 launch type handles our dynamic challenges.
  • Lambda: Executes lightweight serverless functions, specifically our automated challenge health checks.
  • S3 (Simple Storage Service): Serves static challenge assets and archives.
  • RDS: Deployed using a MySQL engine with automated autoscaling. It acts as the permanent, persistent single source of truth—storing critical structured data such as user credentials, challenge flags, and the official submission history.
  • ElastiCache: Deployed as a high-speed Redis cluster for production environments. It acts as an in-memory caching and session layer—handling transient data like active user login sessions, real-time scoreboard calculations, and API rate limiting to reduce database load.

Terraform (Infrastructure as Code)

To prevent configuration drift and allow us to tear down or spin up the entire CTF environment in minutes, we define our AWS resources in Terraform.

  • All VPCs, subnets, EC2 instances, security groups, and IAM policies are declared declaratively.
  • If it is not in the Terraform codebase, it does not exist in our production environment.

GitLab CI/CD (Automation Pipeline)

GitLab CI/CD acts as the central nervous system of our deployment pipeline.

  • Whenever a challenge or infrastructure file is updated, GitLab runners automatically build, test, and package the assets.
  • Pipelines run validation checks, compile docker images, upload them to AWS, and update the live CTFd instance.

2. The Lifecycle of a Challenge

To understand how these tools interact, here is the automated path a challenge takes from creation to deployment:

Push challenge files (Dockerfile, challenge.yaml, solve.py)
▼
Triggers CI/CD Pipeline
▼
Builds Docker image
▼
Pushes verified image
▼ (Triggered by Terraform/Ansible deployment)
Runs container; maps port; updates CTFd platform
  1. Write: A creator submits a challenge containing a Dockerfile, challenge.yaml, and a validation script (solve.py).
  2. Test: GitLab CI/CD runs a static scan against the image. We use a tool built in house tool called ctf-tool to make sure that the challenge can be compiled.
  3. Registry: If the test succeeds, the container image is compiled and pushed to our secure Gitlab container registry.
  4. Deploy: Terraform ensures the host servers are healthy, and our orchestration tools pull the new images onto the ECS Cluster.