Build vs. Buy: What It Actually Costs to Run Your Own Hacking Lab Infrastructure

Every training company, bootcamp, or enterprise L&D team that wants to teach hands-on cybersecurity eventually hits the same fork in the road: build the lab infrastructure yourselves, or run on a platform that already built it. The pitch decks on both sides make this sound simple — "just build it, it's containers" or "just buy it, it's turnkey" — and both pitches are lying by omission. The honest answer depends on what you're actually optimizing for, and it's worth doing the arithmetic instead of trusting either slide.

We build a powered-by lab platform for a living, so we're obviously not neutral on this. But we'd rather you make this decision with real numbers than with our numbers, so here's what we've seen building it ourselves and watching customers evaluate the alternative.

What "a hacking lab platform" actually requires

The phrase "spin up a Docker container per student" undersells the problem by an order of magnitude. A lab platform that's actually usable by paying students or candidates needs, at minimum:

• Per-session isolation — not just a container, but a container plus its own network segment, so one student's workspace can't see or touch another's, and targets can't be reached from outside the session.
• Lifecycle management — provisioning on demand, enforcing one-session-at-a-time (or whatever concurrency rule you need), clean teardown, and recovery when a session crashes instead of ending normally.
• A terminal that actually works — a real shell into the container, not a canned command list. That means a WebSocket server, PTY handling, reconnect-with-backoff, and resize support, none of which show up in a "hello world" Docker demo.
• Grading — flag checking, command verification, or output matching that happens server-side, because the answer key can never touch the browser. Is it a flag hash you check, a regex against submitted output, or do you need to actually execute something against the live target? Each is a different subsystem.
• Content authoring — a way for instructional designers (not infra engineers) to define a lab's targets, challenges, hints, and starter scripts without opening a pull request every time.
• Progress, certification, and reporting — enrollment, completion tracking, badge/certificate issuance that an employer can actually verify, and (if you sell into hiring) a candidate assessment flow with time limits, scoring, and audit trails.
• Multi-tenant admin — if you have more than one customer, cohort, or business unit, someone needs a dashboard to manage courses, see rosters, and configure branding without a database console.

None of these are individually hard. Collectively, they're a product, not a weekend project — and they're a product adjacent to your actual business, which is teaching security skills, not building infrastructure.

The time cost, roughly

Estimates vary by team, but here's a realistic range for a small platform team (2-3 engineers) building a first usable version — not a polished product, just something you could run a paying cohort on:

Component	Rough build time
Container orchestration + per-session networking	3-6 weeks
Live terminal (WebSocket + PTY + reconnect)	2-4 weeks
Server-side grading engine	2-3 weeks
Course/lesson authoring + student progress	4-6 weeks
Certificates with public verification	1-2 weeks
Candidate hiring-assessment flow	3-4 weeks
Multi-tenant admin + billing	4-8 weeks
Total for a real MVP	5-7 months of a small team, often more

And that's the build number. It doesn't include the maintenance tail: container-runtime security patching, scaling the terminal server as concurrency grows, keeping grading logic correct as you add lab content, and the ongoing cost of someone being on call when a container runtime update breaks lab sessions during a live cohort.

When building in-house is the right call

It isn't always wrong to build. It makes sense when:

• Your content is genuinely unusual. If you're teaching something that doesn't fit a workspace-plus-target container model — kernel exploitation requiring real hypervisor escape, hardware-in-the-loop labs, physical red-team simulation — a generic platform (ours included) won't fit, and you need infrastructure shaped around your specific threat model.
• You have idle, capable infra engineering capacity already. A DevOps team that's already running Kubernetes for your core product can extend that investment cheaply. A team starting from zero cannot.
• Data sovereignty or air-gapped requirements rule out any hosted or even self-hosted-but-vendor-supported option, and you need infrastructure nobody outside your organization ever touches.
• You're building for a 5+ year horizon at serious scale, where the long-run cost of per-seat or per-tenant platform fees eventually exceeds the cost of owning the stack — though this crossover point is further out than most people assume once you price in your own maintenance burden honestly.

When buying wins

Most training companies, bootcamps, and enterprise L&D teams aren't actually in any of those buckets. If your content is standard fare — web app exploitation, network pentesting, AD attack paths, SOC/incident response scenarios, cloud misconfig hunting — the isolation model a generic platform offers is the same isolation model you'd build yourself, just already built, already patched, and already handling concurrency you haven't hit yet.

The real argument for buying isn't "it's cheaper" in some abstract sense — it's opportunity cost. Every week your best engineer spends on container networking is a week they didn't spend on the thing that's actually differentiated: your curriculum, your subject matter expertise, your relationships with employers who hire your graduates. A powered-by platform doesn't write your courses for you — that part is still on you, and it should be, since your curriculum is your actual IP — but it removes the part of the stack that looks identical across every training company in the market.

The honest comparison

	Build in-house	Powered-by platform
Time to first paying cohort	5-7+ months (MVP), longer to production-grade	Days to weeks (content authoring is the bottleneck, not infra)
Upfront engineering cost	Real salary cost for months, often underestimated	Subscription/per-seat, predictable
Who maintains the terminal/grading engine at 2am	You	The vendor
Ability to support genuinely novel lab types	Full control	Limited to what the platform's container model supports
Branding and domain	Fully yours by default	Your logo/domain/certs on a shared platform UI — not invisible, not fully custom either
Ongoing infra headcount needed	At least one dedicated owner, realistically	Zero

The question to actually ask yourself

Not "can we build this" — almost any competent engineering team can, eventually. The question is whether the next six months of your best engineers' time is better spent replicating infrastructure that already exists in several mature products, or building the curriculum, instructor relationships, and employer partnerships that nobody can sell you off the shelf. For most training companies and bootcamps, that's not a close call. For a narrow set of teams with unusual content or existing infra capacity, it genuinely is — and if that's you, we'd rather you build it right than buy something that doesn't fit, which is also, not coincidentally, why we spend so much of our own time writing honestly about when not to buy from us.