Nothing to install
Any laptop, any lab room. The workspace is in the browser and it persists.
Machines first. Teaching modules when you want them.
Real technology, taught on real machines rather than described on slides. Start with Linux workspaces and nothing else. Learn, Discuss, Evaluate and CTF are switched on later, per workspace, or never.
How the trial works: sign in, tell us about your institution, and once we approve it you get a dedicated 4 vCPU / 8 GB server under your own brand, free for 30 days. Afterwards the same server carries on as the Nano plan at €30.00 a month, and you can move to a bigger machine whenever you want. Want us to set it up for your team? Done-for-you setup →
Machines first
A computer per student, in the browser
Real Linux, theirs
Root, SSH, VS Code and a VPN address. A desktop when the class needs one.
Templates from the store
114+ templates, from a plain Ubuntu box to Jupyter. Publish your own.
Active Labs
- JD John Doe Deploying Container…
- AS Alice Smith Lab Completed (98/100)
- RJ Robert Jones Failed: DB Connect Error
A class at a glance
Every class is a department
A department per class, with the students in it and the workspaces they run. Limits per class, enforced rather than reported.
- Enrol by adding a member: A student joins the department and the class template is theirs to deploy.
- One template per class: A plain Ubuntu box or a Jupyter image. Everyone starts from the same one.
- Limits per class: Storage, workspaces and labs, set once on the department.
Templates and database engines, ready to deploy
Then the modules
Switch on what the class needs
Labs and Workspaces
Always on. The workspaces, and the administrators who manage them.
Learn
Roadmaps and a syllabus, when a course needs an order.
Evaluate
Quizzes and a code arena. Submissions run against real test cases.
Discuss and CTF
A forum with a relevant feed. Flags, clans and timed events.
Each module is a switch per platform. Off costs nothing and shows nothing.
Watch
See a real Linux machine in a browser tab
Filmed on the platform itself. What is on screen is what a student opens from any laptop, with no lab PC behind it.
- The workspace in a browser: The same terminal, editor and desktop a learner gets.
- Nothing staged: What is on screen is what the platform serves.
Want to know more? Press play. It is the platform, not a slide deck.
One platform, many classes
A department per class
Organization
The whole institution or company, with its plan and its ceiling.
Departments
One per course, batch or team. Members, storage, workspace and lab quotas, enforced rather than reported.
Templates
Publish one template per subject or stack. Everyone in the department starts from it.
Workspaces
A persistent Linux machine per person, with SSH, VS Code in the browser and a desktop when needed.
Tracking
What each child has actually done
Not attendance. What they opened, what they finished and what ran, kept per person as it happens, so a teacher can see who is stuck before the term ends rather than after it.
Kept per person
Lessons finished and submissions made are recorded against the student, and follow them from one class into the next.
Marked by a machine
A quiz or an arena submission is run, not read, so every child in the room is marked the same way.
A class at a glance
A department per class, with the students in it and the workspaces they are running, on one screen.
Agents in class
An agent can set the lab up. It cannot mark it.
Teachers and students connect Claude, Codex or any MCP client with their own permissions. The quiz bank, the code arena and the CTF flags are refused over MCP for every role, including an admin.
What an agent sets up
Over MCP, with no SSH key and nothing for a teacher to join.
- Brings up the machine a lesson needs, straight from the store
- Writes the files, starts the service and reads its own log
- Puts it on a URL with a certificate, so the class can open it
- Attaches a database with credentials only that workspace holds
- Publishes the finished setup back as the template for the class
Off limits to agents
Refused before any role is checked.
- Quizzes and quiz reports
- The code arena
- CTF flags and events
- AI answers in Learn AI, and AI help in Discussions
- The leaderboard
Build on it
Wire it into what the school already runs
The dashboard is built on its own HTTP API, and the same platform speaks MCP. A school portal, a timetable or an agent can drive it, with the permissions of whoever is calling.
The HTTP API
Everything on the dashboard is an API call, so the school's own portal can create a class, add a student and hand back a workspace without anyone opening this one.
MCP for a teacher
One connection. What the model is shown follows that teacher's role, and every call it makes is written down against them.
The sign-in they have
Students sign in with the school account they already have. GitLab, Google, Entra or any OIDC issuer, and the application is yours.
Use cases
What a school does with it
A computer per student, in the browser
Any laptop, any lab room. The workspace persists.
- Nothing to install: The workspace is a browser tab. It survives the year.
- Real Linux: Root, SSH, VS Code and a VPN address. A desktop when the class needs one.
- 114+ templates: From a plain Ubuntu box to Jupyter. Publish your own.
Use cases
- Computer labs without lab PCs
- Shared lab rooms
- Bring your own laptop
- Remote lessons
Outcomes
- Nothing to install
- No lab PC to maintain
- A machine that survives the year
- The same machine at school and at home
A department per class
Members, storage, workspace and lab quotas, set per class.
- One template per class: Publish it once. Every student starts from it.
- Limits per class: Enforced rather than reported.
- Membership is enrolment: Add a student to the department. Remove them when they leave.
Use cases
- A department per section
- A department per term
- Exam practice groups
- Mixed-age clubs
Outcomes
- Limits per class
- One image per class
- A ceiling that holds
- Each class in its own department
Switch on what the class needs
Labs and Workspaces are always on. The rest is a switch per platform.
- Learn: Roadmaps and a syllabus, progress kept per person.
- Evaluate: Quizzes and a code arena. Submissions run against real test cases.
- Discuss and CTF: Threads attached to the work. Flags, clans and timed events.
Use cases
- Coding classes with a syllabus
- Quiz days
- A forum per class
- Off entirely for a plain lab
Outcomes
- 6 modules, 2 always on
- Off costs nothing and shows nothing
- Progress per person
- Scores the same for everyone
Coding clubs and CTF days
A club is a department too. CTF gives it missions, flags and a live scoreboard.
- Missions with flags: Each mission is a lab. The flag proves it was solved.
- Clans and timed events: Teams, a start and an end, and a scoreboard the room can see.
- Off limits to agents: Flags, events and the leaderboard are refused before any role is checked.
Use cases
- Coding clubs
- Security clubs and CTF days
- Hackathon weekends
- Contests between classes
Outcomes
- A scoreboard the room can see
- Work that lives past the event
- Flags an agent cannot touch
- One template per event
Teacher practice and teacher control
Teachers get the same machine as the class, plus the department that runs it.
- Practice on a real machine: The same workspace a student gets, kept for the year.
- Publish the class template: Fork one from the store, change it, publish it to the class.
- Agents for the setup: Connect an MCP client to prepare labs. Quizzes and the arena stay out of reach.
Use cases
- Teacher practice
- Preparing a lesson image
- Resetting a class before term
- Labs prepared by an agent
Outcomes
- Teachers own the template
- Assessment stays with the teacher
- Every agent call audited
- No IT ticket
Machines first, modules when you want them
Real Linux workspaces for every student, and the teaching side switched on per workspace.