Everything you save stays on the disk when you stop.
We build the lab your syllabus actually needs. Every student gets their own full machine, an agent on it checks their work as they go, and the instructor sees exactly what each of them did.
Everything you save stays on the disk when you stop.
One machine, one button, and a task the machine itself marks. The instructor is reading the same result at the same moment.
You tell us what the module has to run. We build that environment, pin it for the semester, and hand every student their own copy of it in a browser tab.
Tools, targets, datasets, whatever the module actually needs. We build that, rather than handing you a menu to squeeze the course into.
The environment is fixed to one image, so the machine a student meets in week one is the machine they sit the exam on.
No VM downloads, no dual boot, no lab-room booking. A browser and a login is the whole requirement, on any laptop they own.
Provision a whole class in one action, and take the whole class down when the module ends. You are not carrying idle machines between semesters.
An agent runs on every student machine and verifies each task where the work actually happened. Progress is observed, not claimed — which is what makes it usable for grading.
Students work through the exercise in a panel on their own machine, with a hint available when they stall. Nothing to open in a second tab.
Each step has criteria checked where the work happened — a file that exists, a service answering, a command that was actually run. A student cannot tick their own box.
The student sees which criteria passed and what is still outstanding. The instructor sees the same per student, timestamped, without asking anyone.
| Student | Task | Criteria passed |
|---|---|---|
| Fatima Al-Sayed | Recon 101 | 4 / 4 |
| Yusuf Rashid | Recon 101 | 3 / 4 |
| Noor Abdulla | Recon 101 | 4 / 4 |
| Hassan Kamal | Recon 101 | 1 / 4 |
Illustrative — the shape an instructor reads, not a real cohort.
Who is on which machine, what they ran, what passed, and who reset what. Availability, power and every check result land in one log with a name and a timestamp against them.
| Machine | Student | Power |
|---|---|---|
| EH-01 | Fatima Al-Sayed | RUNNING |
| EH-02 | Yousif Kanoo | STOPPED |
| EH-03 | Noor Hassan | RUNNING |
| EH-04 | Ali Mansoor | STOPPED |
Seats, machine-hours and usage in one view, with CSV export behind them. An illustrative 14-week semester — not a customer’s data.
Anything taught on a machine rather than on paper — ethical hacking, networking, databases, Linux administration, data science. If the module needs a real environment and setting it up eats the first hour of every session, it fits.
An agent on each machine checks the task where it happened: a file that exists, a service that answers, a command that was genuinely run. The result is per student and timestamped, so progress and attendance are something you read rather than something you are told.
Every student gets their own machine, reachable only by them. There is no shared filesystem and no network path between seats, so one student cannot reach another's work — which is what makes the security courses safe to run.
It only needs outbound HTTPS on 443, the same thing a browser already uses. There is no VPN client, no extra port and nothing for IT to whitelist per student.
There is no list price because no two institutions buy the same thing. Seat counts, how long machines stay on, and whether you need nested virtualisation all move the number, so we quote against your actual course rather than a tier you have to fit.