>chall.run
EN KO
contact

// platform

A microVM per instance,operations on us.

We build your images, isolate every instance, place it in the right region, handle incidents and go through the logs after the event. You look after the challenges and the event.

01 how it works

Keep your compose filesand your CTFd.

  1. 01

    Push

    challrun push builds your images and deploys them to the regions you choose, from the same compose file you tested locally.

  2. 02

    Connect

    Install the CTFd plugin, or call the REST API from another platform. rCTF or a custom scoreboard works as long as it can make HTTP requests.

  3. 03

    Event day

    Each time a team starts an instance, a new microVM boots with that team's flag injected. We handle host monitoring and incident response.

# sits next to your docker-compose.yml, nothing else changes
name: web/blog-v2
compose: ./docker-compose.yml
expose:
  - service: app
    port: 8080
    as: https   # https://<team>.blog-v2.inst.chall.run
  - service: pwnbox
    port: 31337
    as: tcp     # nc icn1.chall.run 40213
resources:
  memory: 512Mi
  cpu: 0.5
ttl: 45m
flag:
  env: FLAG       # unique per team, injected at spawn
  format: "acme{%s}"
team -- https / nc --> edge.icn1   sni + port map
                          |
          +---------------+---------------+
          v                               v
   host epyc-07                    host epyc-11
   |- fc-7f3a  b4ckd00r          |- fc-c0de  r3kt
   |  `- compose: app, db          |  `- compose: pwnbox
   |- fc-91ab  null_ptr          `- fc-0b5e  0xfe
   `- ...                             `- ...

02 regions

Instances startclose to the player.

Open CTFs draw teams from everywhere. A European team on an instance in Seoul sits behind more than 250 ms of round trip. chall.run can spread one event's instances across regions.

  • fra1 Frankfurt DE
  • ams1 Amsterdam NL
  • atl1 Atlanta US
  • icn1 Seoul KR
  • nrt1 Tokyo JP
  • sin1 Singapore SG
  • gru1 São Paulo BR soon

  • +Nearest region by default

    When a player starts an instance, it goes to the region closest to where they connect from. Same challenge: Seoul for a Korean team, Frankfurt for a German one.

  • +Or pin it

    For finals where every team needs the same conditions, pin a challenge or the whole event to one region.

  • +Images in every region

    Your images are prebuilt on servers in every region you use, so starting anywhere takes the same time.

  • +Billed where it runs

    Each instance is charged at its own region's multiplier and egress rate. Rates are on the pricing page.

03 reliability

Ready before 09:00,not patched after it.

Read the infra write-ups CTF organizers publish and the outages bunch up in the first 30 minutes. So we do most of the work for your event before it opens.

$ challrun preflight acme-26
[ok] hosts     12 in icn1, instances spread across all
[ok] images    14/14 challenges prebuilt on every host
[ok] testrun   900 parallel starts, p99 boot 0.8 s
[ok] failover  pulled icn1-07, 61 instances redeployed in 4 s
[ok] isolation scoreboard p95 41 ms during the rush
[ok] on-call   24/7, #acme-26-infra
ready. good luck, have fun.
sample output

  • +Images prebuilt on every host

    Your images are already built on every server, so nothing waits on an image build once the event starts. Images that go unused for a while after their last use are deleted automatically.

  • +Test any time before the event

    You can start instances and test whenever you like, before the event too. It's billed in credits like anything else, so if you want a load test, start as many instances as you have teams and see.

  • +No single host to lose

    Instances are spread across servers. If one server fails, the same instances are redeployed on another server right away and players are notified.

  • +Scoreboard kept separate

    Instance requests go to our control plane, not to your CTFd server. A rush on instances doesn't slow down the scoreboard.

  • +Engineers on call 24/7

    An engineer is on call around the clock, so an event that starts at 3 AM or on a Sunday gets the same response.

  • +Live dashboard, then a report

    During the event you see running instances, the queue and host health. Afterwards you get usage numbers and a write-up of anything that went wrong.

04 audit

Flag sharing and AI use,checked against the logs.

Each team gets its own instances, and with dynamic flags its own flag too, so every request and every flag can be traced to a team. During or after the event, we go through those logs and hand organizers what we find.

$ challrun audit acme-26
[flag]  0x1f submitted a flag issued to 0x3a
        web/blog-v2 · 10:41:12
[flag]  0x1f, 0x77 same /24, 4 solves <40 s apart
[agent] 0x52 web/notes 1,840 req in 6 min
        scripted path walk, no idle gaps
[agent] 0x0c pwn/heap 94 connects
        payload rewritten every ~8 s
[ok]    808 teams, no signals
report: audit/acme-26.html (organizers only)
sample output

  • +Flag sharing

    A flag submitted by a team it wasn't issued to is caught on the spot. This needs the challenge to support dynamic flags: we pass each team's flag in the FLAG environment variable when the instance starts, and the challenge reads it from there. We also look for quieter signs: one instance reached from several teams' IPs, solves landing seconds apart, identical payloads.

  • +AI audit

    Agents work a challenge differently from people: request rate, the order they walk paths, how they retry, the fingerprints their tooling leaves. We mark teams whose traffic looks automated and show the requests behind it.

  • +Your rules, your call

    Whether AI is allowed is up to your event. We don't disqualify anyone; you get evidence per team and decide. If AI is allowed, the same data shows how teams used it.

  • +Per-team timeline

    Which instances a team started, when, and what it sent to them, exportable for appeals and post-event reviews. Only your organizers can see the logs, and they are deleted 30 days after the event.

05 questions

Q.Why microVMs instead of containers?
Players are actively trying to escape sandboxes. Containers share a kernel with everything else on the same host; each microVM has its own. The VMs boot in under a second, so stronger isolation doesn't mean a long wait.
Q.Do I need to change my challenges?
Usually not. If it runs with docker compose up locally, it runs here. Privileged containers and host networking are not supported.
Q.Can I use it without CTFd?
Yes, through the REST API. It has four endpoints: start, extend, stop and status. The CTFd plugin uses the same API.
Q.Will you ban teams that use AI?
No. We report what the logs show and organizers decide under their own rules. A detection is a lead, not proof, so every team we mark comes with the requests behind it.
Q.What if players attack the infrastructure?
Each VM has egress limits and no network path to other teams' VMs or to the control plane. If you find a VM escape or a similar issue, please report it. Valid reports are rewarded.

Early access is paused.Reach us by email.

$ contact

We're not taking early-access requests while we get the beta ready. For event plans or any questions, send us an email.

support@quickmetal.kr send an email →