不是。静态容器与动态容器相同，每个参赛队伍都有一个独立的容器。
但是静态容器内的内容是一样的，且不会传递下发动态 flag。只能通过获取硬编码于容器中的一个或多个静态 flag 作为验证指标，也即“静态”的意思。
一名用户可参与多个队伍，每场比赛每个均需要每名队员独立报名，同一个人可以以不同队伍身份同时参与多场比赛，报名时需要选择以哪个队伍进行参赛。
在报名等待审核和被拒绝时可以撤回报名。审核通过、禁赛时不可撤回报名及更换所属队伍，且队伍将会被锁定。
在比赛结束后，队伍仍然显示处于锁定状态，若确认没有其他正在进行中的比赛时进行人员变动，队伍将会自动解锁。
目前由于考虑到一些容器后端的兼容性问题，暂不支持多容器题目。
目前的题目编辑逻辑为拉取一次数据，本地更新后全量更新数据库，多人编辑可能造成数据冲突或丢失，最终数据以最后一次更新为准，因此不建议多人同时编辑同一个题目。
多阶段题目建议将 flag 在注入时进行切片，再分发到不同的位置或按照题目需要的方式进行组合。
在一段时间的测试和使用后，我们发现了一种较好的题目描述编写方式，这一方式不会抢占附件下载按钮的位置，同时还能提供更多的题目信息：
需要注意的是，在 Markdown 编写规范中，如果需要换行的同时不另起一个段落，需要在行尾加上两个空格。
在 GZCTF 上编写题目时，请注意在信息行和另外有换行需求的行后适当加上空格，同时尽量多换行、保证短句每行宽度在 490px （约 30 个中文字符）以内来获得更好的显示效果。
对于拥有多机集群及其部署需求的用户，建议使用 K3s 作为 K8s 的发行版，其能提供所需的全部功能，且易于安装部署。
更一般的情况下最方便的部署方式为 Docker + K3s 分离部署，只需要执行 docker-compose 即可完成 GZCTF 平台的部署，而 K3s 的部署则只需要执行安装后导出 kubeconfig 挂载给 GZCTF 即可。
如果需要使用 K3s 集群内部署，需要提供两个 PVC（用于数据库及附件存储）、一个 ConfigMap（用于存储 appsettings.json）、一个 Secret（用于存储指向自己集群的 kube-config.yaml）。你可以按需进行数据库部署及 Redis 部署，如果只运行一个 GZCTF 实例，可以不部署 Redis。
经测试，出于数据库性能考量，暂不建议使用多实例分布部署，单实例多性能足以支持大多数比赛。
GZCTF 支持多个实例同时运行，但需要提供相同的数据库实例及 Redis 实例（多实例必选）及共享存储（如 NFS）作为 PVC。其中数据库实例和共享存储用于保证数据一致，Redis 实例用于进行后端部分数据的缓存同步、SignalR 的 Scale-Out 广播。
同时，为了确保 SignalR 基于 websocket 的正常运行，需要在负载均衡器中配置 Sticky Session。
此类问题主要出现在 Docker + K8s 分离部署的情况下将 GZCTF 通过 Docker 直接运行在 K8s 节点中，此时机器的 HTTP 端口被 traefik 及其负载均衡器占用，导致无法访问。解决方案很多且非常灵活：
GZCTF 作为一个免费开源的项目不会去做 AWDP 的支持。
虽然目前能设想的方案兼容性是很高的，且不是不能做，但是实现起来需要大量的时间投入，且大概还需要三个附属项目，为此没有收入是不太能接受的；其次是，如果做出来可能会影响部分企业的盈利渠道，也算是不太好的一件事情。
解题赛本身已经能够训练大部分的技术能力，fix / patch 也是直接教学、分发镜像本地实验就可以实现。GZCTF 的初衷是 帮助高校更好地训练 CTF 队伍，而不是举办正式的比赛，从教育角度出发，去做一个 AWD 平台的必要性很低，想训练赛制的话不如去打个现场赛，这也是考量的另一个方面。