Domains
We recommend reserving an entire domain where challenges will be deployed to. For our example we will use example.com.
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
If you are working with a single server setup, set the DISABLE_PLACEMENT_CONSTRAINTS=true envvar in deploybot.