I've spent most of the last year sitting in on enterprise Capture-the-Flag evaluations — sometimes on our side of the table, sometimes just helping a customer make sense of the shortlist. The thing that surprises me every time is how much shorter the real shortlist is than the spreadsheet the team walked in with.
A security lead opens a procurement cycle with six or seven platforms in the frame. By week two, half of them are gone — not because of features, but because somebody asked "can we host this inside our own VPC" and "will someone pick up the phone at 2 a.m. on event night" in the same meeting. Very few vendors say "yes" to both. That's the slot this post is about.
I'm not going to pretend Battlegrounds by Fionetix is the right answer for every team. It isn't. But in that narrow intersection — self-hosted, on your infrastructure, with a named engineer on contract — the list of real options is tiny, and I think it's worth writing out honestly.
Why "self-hosted + real support" is a tight segment
Enterprise CTF platforms mostly cluster on one side of a single decision:
- Managed SaaS, with a slick UX, a huge challenge catalog, and a perfectly reasonable SLA — but your trainee data, your flags, and your scoreboard live in the vendor's cloud. For a lot of regulated buyers — banks, defence, health, anyone under a national data-residency mandate — that conversation ends at "the data leaves our VPC".
- Self-hosted with a vendor behind it, where the app sits inside your own environment, under your SSO, with a named engineer on the contract. That one is rare. Most platforms that can be self-hosted don't come with anyone to call when it breaks; most platforms that come with someone to call are SaaS-only.
- Battlegrounds · Fionetix
- CTFd Enterprise
- Hack The Box Business / HTB Enterprise
- TryHackMe for Business
Immersive Labs · private cloud, in rare cases
The five enterprise-grade CTF platforms, split by deployment model. If your RFP requires data to stay in your VPC, the column on the left is the shortlist.
That's the whole landscape, without the marketing layer. If your procurement team is insistent on the left column — and most regulated buyers are — the conversation really does narrow to two names before features even come up.
The enterprise contenders, side by side
Here's how I've found myself drawing this on a whiteboard. Nine rows, five columns, tick-and-cross. No more, no less — this is what survives a serious RFP.
| Capability | Battlegrounds Fionetix | CTFd Enterprise | HTB Enterprise | TryHackMe for Business | Immersive Labs |
|---|---|---|---|---|---|
| Runs inside your own VPC | Private cloud, rare | ||||
| Source code access | OSS core only | ||||
| Data stays on your infrastructure | Depends on tier | ||||
| Named support engineer on contract | |||||
| Multi-tenant contests on one deployment | Rooms only | ||||
| SSO / SAML | |||||
| Per-contest admin delegation | Workspace-level | ||||
| Audit trail wired to your SIEM | Export only | Export only | |||
| White-label branding (your name, not theirs) | Logo only | Logo only |
Nine things I've watched enterprise buyers actually care about, across the five platforms that reach the final shortlist.
The first three rows do most of the work. Runs in your VPC. Source access. Data stays on your infrastructure. If your RFP checks all three, you're looking at one of two names — and the rest of the table is a tie-breaker, not a cull.
What Battlegrounds actually is
Battlegrounds is a Next.js + Prisma application that treats contests as first-class tenants — not as folders of challenges stapled to a single-instance engine. Concretely, that means you can run, on one deployment, at the same time:
- An always-on internal training ladder for your SOC team.
- A recruiting CTF for candidates, with its own admins and its own branding.
- A partner or customer-facing event, white-labelled end-to-end.
Each contest has its own admins, its own participants, its own notices, its own submission trail. The Submission rows capture IP, timestamp, exact flag submitted, points awarded, and a first-blood flag — so the audit question "who authored challenge X and which IP submitted the winning flag at 14:03:22" has an answer without anyone grepping through logs at midnight.
The Battlegrounds data model, simplified. Contests aren't a feature — they're the shape of the platform.
How an enterprise deployment tends to look
The common shape we see: SSO terminates at the customer's identity provider, the app sits inside the customer VPC, a primary-plus-replica Postgres holds state, an object-storage bucket holds challenge artifacts, and every audit event gets piped to whichever SIEM the customer already pays for.
Nothing leaves the customer VPC. SSO lives in the DMZ. Every submission row ends up in the customer's own SIEM.
Where Battlegrounds earns its spot
1. The support contract isn't an upsell
Every paid Battlegrounds deployment includes a named engineer you can reach on Slack or Teams, and source access is part of the license — you can audit it, fork it, patch it. When we ship a fix it lands back in your branch on your cadence, not ours. That's not a platinum tier. That's the only tier.
2. Multi-tenant contests on one instance
This is the one I think gets undersold the most. The same deployment runs your internal SOC ladder and your recruiting CTF and a partner event, each with different admins and different branding, without spinning up three copies of the app. Most OSS-lineage platforms assume one instance equals one event. Battlegrounds assumes the opposite, and for a team that runs more than one kind of exercise a quarter, it changes how much platform they actually need to own.
3. A stack your own engineers can maintain
Next.js, TypeScript, Tailwind, Prisma, Postgres. Nothing exotic. Nothing locked in a compiler or a private runtime. If we disappeared tomorrow — and I wouldn't recommend it — any mid-level web engineer on your team could keep the thing running. That quiet property matters more in a five-year procurement contract than the loud ones tend to.
4. An audit trail designed for the questions auditors ask
Every submission carries IP, exact timestamp, points awarded, and whether it was first blood. Problems track creator and last editor. Notices track severity and who posted them. None of this is bolted on; it's in the schema. I've watched more than one SOC auditor visibly relax when we pulled up a live query that answered their question without any log-grepping at all.
5. First blood is already a data field, not a plug-in
isFirstBlood is a boolean on every submission row. No extension, no cron, no custom build. It's the small kind of detail that says "someone who runs events thought about this" — and it saves a surprising amount of ceremony when you're actually running one.
Where procurement usually pushes back — and why it hasn't mattered
A blog that only lists strengths is a brochure. So here are the five things your procurement team will flag about Battlegrounds, honestly — along with what I've actually seen happen when the dust settles inside an enterprise deployment.
"There's no public challenge marketplace"
True. What I've seen: enterprise teams don't want a public marketplace anyway. The training content they use is either authored internally, licensed under NDA from a specialist, or curated from a handful of sources they already trust. Piping in public-internet challenges — whose authorship and safety you can't vouch for — is not a feature most regulated buyers will touch with a ten-foot pole. Our authoring UI and import format fit how the work actually gets done in-house; a marketplace would solve a problem these teams specifically don't have.
"Dynamic scoring decay isn't shipped yet"
Also true — we currently ship flat scoring plus first-blood, with decay curves on the near roadmap. What I've seen: internal training ladders and recruiting funnels almost never use decay. Decay is tuned for a 48-hour public scrim where you want to separate "first to solve" from "eventually solved". Enterprises running continuous training want the opposite signal — who's ready, not who was fastest on a Saturday afternoon. The customers who have asked about decay have been, almost without exception, using the platform for a once-a-year public event, not for the day-to-day.
"There's no giant Stack Overflow community"
Correct. What I've seen: enterprise teams count this as a plus, not a minus. A public forum trail of "here's the weird thing our CTF platform does" is an information-disclosure risk, not a support channel. The customers we work with actively want their questions to land in a named engineer's DMs under NDA, not in a Google-indexed thread. The smaller community is a feature of the contract, not an accident.
"No in-app challenge-container orchestrator"
True. Battlegrounds integrates with your existing Kubernetes or Nomad cluster via a challenge-launch webhook; there's no "spin me a container" button inside the app at the maturity level of the SaaS catalogs. What I've seen: enterprise buyers in regulated environments already run their own orchestrator, already have policies around images, networking, and egress, and genuinely do not want a CTF vendor shipping a parallel, unreviewed orchestration layer into their VPC. They want the platform to use the infrastructure they already govern. That's what the webhook does.
"The default database is SQLite"
True for local dev — and irrelevant for production. In a regulated VPC you were never going to run the event on SQLite; you were always going to put it on the managed Postgres your DBA team already supports. The platform ships on Postgres on day one of a real deployment. The SQLite default is a convenience for a laptop, not a production claim.
Decision matrix — which platform, when?
| If your top priority is… | Pick |
|---|---|
| Self-hosted in your own VPC, with a vendor accountable on support | Battlegrounds or CTFd Enterprise |
| Self-hosted and you want everything in one ecosystem, including authoring tooling and branding | Battlegrounds |
| Running many concurrent events (recruiting + internal + partner) on one platform | Battlegrounds |
| Massive pre-built catalog of hands-on labs, data in vendor cloud is OK | HTB Enterprise |
| Guided skill-tree training across a large workforce, managed SaaS | TryHackMe for Business |
| Rigorous workforce-skill measurement with curated content, managed SaaS | Immersive Labs |
| Recruiting CTF, fully white-labelled, behind your SSO | Battlegrounds |
The rows where we're the answer all share the same shape: you want the platform under your roof, you want somebody accountable, and you want it to look like your product, not ours.
How we've actually deployed it
Four patterns we've seen repeatedly:
- Recruiting CTFs where the whole candidate funnel — registration, scoring, first-blood notifications, post-event exports — ran on a single self-hosted deployment behind the customer's SSO, under their branding.
- Continuous internal training ladders for blue-team and SOC staff, where new contests get spun up monthly without re-deploying anything.
- University and collegiate events where per-contest admin delegation let individual faculty run their own challenges on a shared platform that central IT actually operated.
- Partner and customer-facing events with branding, platform name, and support email pulled from a Settings table — no fork, no rebuild, no vendor logo on the login screen.
Because the platform is self-hosted, we don't hold your event data — which also means the "proven track record" we show you is the capability set we've shipped and the go-lives we've walked through personally, not anonymized telemetry from your users. That's usually the right trade for enterprise buyers. It occasionally frustrates marketing teams.
A four-week evaluation pattern
When customers ask me how to run the evaluation, this is the rhythm I suggest. It catches the surprises before the contract, not after.
The shape of a real evaluation. Week one is paperwork; week four is conviction.
Four questions I'd ask every vendor — not just us:
- SBOM. A software bill of materials for the current release.
- SOC 2 / ISO 27001. Current posture, or a clear statement if they don't hold one.
- Patch cadence. How fast do CVEs get addressed, and under what SLA.
- Escape-hatch clause. If this vendor disappears tomorrow, can you keep running the platform? With Battlegrounds the answer is yes, you have the source. Ask the same question of every SaaS option on your list and watch the room get quiet.
Closing
If the best catalog of hands-on labs is what you care about most, Hack The Box and TryHackMe are built for that, and they're very good at it.
If what you need is a CTF platform inside your own VPC, under your branding, with a vendor who will be on the call with you when something goes wrong at 2 a.m. — that's the corner of the market Battlegrounds was built for. We don't pretend to be the right answer everywhere else. We just try, honestly, to be the right answer there.
