Skip to content

Update CTFp to support CTFd 3.8.6 and move to Redis Replica instead of cluster - #27

Draft
The0mikkel wants to merge 56 commits into
mainfrom
develop
Draft

Update CTFp to support CTFd 3.8.6 and move to Redis Replica instead of cluster#27
The0mikkel wants to merge 56 commits into
mainfrom
develop

Conversation

@The0mikkel

Copy link
Copy Markdown
Member

This PR updated CTFp to support CTFd 3.8.6 and removes Redis cluster and moves to Redis replicated.

The PR also updates the Kube-hetzner plugin from v2.18.2 to 2.21.0, along with locking the OS image generation script to specified version.

@The0mikkel The0mikkel self-assigned this Jul 27, 2026
The0mikkel and others added 7 commits July 27, 2026 19:50
Migrate to Redis replication for CTFd, from the current faulty Redis
cluster set up.

This update splits Redis deployment into two; cluster and replication.  
Traefik keeps cluster deployment, while CTFd is migrated to Redis
replication.

This is inline with the CTFd v2.0.0 deployment, which is currently
provided as a release candidate;
[v2.0.0-r.1](https://github.com/ctfpilot/ctfd/releases/tag/v2.0.0-r.1)

This update also fixes an issue with Traefik Helm configuration, and
updates the Redis Operator to v0.25.0.
The0mikkel and others added 3 commits July 29, 2026 22:13
# Summary
Makes the MariaDB cluster's timeZone configurable instead of hardcoded

- New `db_timezone` variable (default `"+2:00"`, preserving current
behavior exactly), threaded through the `mariadb-cluster` module and
wired into the CTFp CLI's `PLATFORM_TFVARS` list
- Validation on `db_timezone` accepting either a UTC offset (`"+2:00"`)
or a named zone (`"Europe/Copenhagen"`)
- Documented in both tfvars templates and variable descriptions
- Also wires the mariadb-cluster module's Backup resource timezone (used
for the backup cron schedule) to the same db_timezone variable,
previously hardcoded independently to Europe/Copenhagen.

This closes #9
…agent nodes - Upgrade requires cluster to be offline

This update groups nodes into three placement groups: control planes, agents and challs.
This allows specifying what type of deployment that is made, such as standard, single-node or ha.
This configuration automatically updates replicas of core services deployed as part of the platform.
The0mikkel and others added 23 commits July 30, 2026 19:09
…cal severity alerts to Discord, and reformat to fit Grafana v13
Add support for varying platform sizes, by adding support for three
deployment types: `single-node`, `standard`, and `ha`.
This allows running the platform on 3 nodes, instead of the standard
supported 7 nodes.

The update adds configurable replica count for most services, along with
an extensive default system which uses the new `deployment_type` to
select how mnay replicas should be used for a given deployment.

This does solves #25 by allowing the specification of how many replicas
individual services should have.

The PR also provides some minor updates to resources, and update naming
of placement groups.
Additionally, the PR provides the option run the platform with a single
top-level domain, instead of three.
Allow configuring additional ports for Traefik, such as for static TCP
challenges, and allow adding additional trusted IPs for Traefik, for
example to trust Cloudflare proxy headers.
Cloudflare by default only covers the TLD and one level of subdomains. The system automatically detects the number of levels, and decides if the record should be proxied based on it Cloudflare allows it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants