Domains

We recommend reserving an entire domain where challenges will be deployed to. For our example we will use example.com.

info

If needed, you can use a subdomain of another domain. For example, you could deploy challenges on challenges.example.com and run CTFd on ctf.example.com.

However keep in mind that there may be security concerns around deploying potenailly malicious/vulnerable applications on the same domain as a proper application.

Configuration

CPU_LIMIT

CPU_LIMIT determines the CPU quota limitation for every deployed service

MEM_LIMIT

MEM_LIMIT determines the CPU quota limitation for every deployed service

SNIPROXY_WILDCARD_DOMAIN

The wildcard domain where all challenges will be scheduled.

SNIBRIDGE_HOSTS

The servers which are responsible for proxying unencrypted TCP requests to sniproxy who then proxys requests over to the intended challenge service.

DOCKER_REGISTRY_USERNAME

The username by which deploybot can login to a Docker registry where private Docker images for challenges are stored

DOCKER_REGISTRY_PASSWORD

The password by which deploybot can login to a Docker registry where private Docker images for challenges are stored

DOCKER_REGISTRY_HOST

The hostname for a private Docker registry

DISABLE_PLACEMENT_CONSTRAINTS

Set to true to disable any constraints around scheduling services on specific servers/nodes.

DISABLE_RESOURCE_CONSTRAINTS=false

Set to true to disable any resource constraints around CPU/RAM for services

Example

CPU_LIMIT=1
MEM_LIMIT=268435456
SNIPROXY_WILDCARD_DOMAIN=example.com
SNIBRIDGE_HOSTS=0.challenges.example.com,1.challenges.example.com
DOCKER_REGISTRY_USERNAME=username
DOCKER_REGISTRY_PASSWORD=password
DOCKER_REGISTRY_HOST=registry.gitlab.com

tip

If you are working with a single server setup, set the DISABLE_PLACEMENT_CONSTRAINTS=true envvar in deploybot.