RosettaHub™ for Education
Teaching, labs and assessment
Thirty students.
Thirty working environments.
Teaching anything computational starts with everyone having the same setup, and the first hour usually goes on the people for whom it did not install. Prepare the environment once and every student opens an identical one in a browser.
Set up once,
issued to the whole cohort
Whoever knows the material prepares the environment. Everyone else receives it, identically, which is also what makes an exercise reproducible from one year to the next.
Any environment a course needs
A desktop with licensed software, a notebook, a container, or a Kubernetes, Spark or HPC cluster where the subject calls for one.
Nothing on the student device
A browser is the whole requirement, so the course does not quietly depend on who could afford a capable laptop.
One each, on demand
Every student draws their own copy from the same description, with no account to create and nothing to allocate by hand.
The same one next term
The environment is a description you keep, so running the module again is a launch rather than a rebuild.
Students learn the real cloud,
where mistakes are affordable
Cloud skills are what graduates are hired for, and they are learned on a real provider rather than a simulator. Each student gets a genuine account, bounded to the services the course needs and the money you have set aside for it.
A real account, bounded
Students work in the provider’s own console and tools, restricted to the regions, services and machine sizes the course actually needs.
A budget per student and per project
Funding is set at both levels, so a module and a group project can be tracked and capped separately without either being an estimate.
They sign in as themselves
Access comes through your existing single sign-on, so there are no separate credentials to issue, reset or chase, and someone who leaves the institution loses cloud access with their account.
The expensive mistake cannot happen
The classic story is a student leaving something large running over a holiday. Here the launch is refused before the budget is gone, so the lesson costs the intended amount.
Students run their own work
They start what they need, when they need it, and see what it costs while they do.
A budget each, visible
Students see what they are spending as they work, and a launch beyond the limit is refused rather than reported to somebody later.
A budget that can move
A student asks for more and a lecturer transfers it, sets a new figure, or lets budgets top up on their own. Nobody is stuck at a deadline.
Help that actually helps
A lecturer can work as the student and see exactly what they see, which beats a screenshot from someone who does not yet have the vocabulary to describe the problem.
Guardrails are what let cloud adoption scale across an institution. Without them it stays with the few people trusted to hold an account.
“Students like the autonomous, independent working model with re-adjustable budgets. Lecturers and administrators get notified when resources are expended, take control and assist by masquerading as the user.”
The reason the module
runs again next year
A teaching budget that overran once tends not to be approved twice. Predictability matters more here than in most places.
Your accounts, your rates
Everything runs in the institution’s own cloud accounts at the prices you already pay, with no margin added to infrastructure and academic credit programmes still applying.
Stopping keeps the work
Idle machines stop themselves and resume with state intact, so the safe thing to do is also the cheap one and nobody avoids doing it.
No hardware to buy first
A department can put serious compute behind a project without a capital case, scale it up when the work demands it and down when it does not, and stop paying entirely when the project ends. Spend is attributed as it happens, so next year’s figure is last year’s report rather than an estimate.
Beyond taught courses
Teaching is where this usually starts. It is rarely where it stops, because the same arrangement answers every case where a group needs real infrastructure briefly.
Final-year projects
Ambitious projects need whatever the idea requires, not whatever the lab image happened to contain. Students get databases, clusters and GPUs on their own initiative, each inside its own budget.
Research and innovation
Departments put serious compute behind a project without a procurement round first, and stop paying for it when the project ends.
Training and workshops
A bootcamp, a certification course or a workshop audience given a sandbox each, ready before the session starts.
Assessment and onboarding
An identical clean environment per candidate, and the same route for a new intake on their first day.
“Through RosettaHub, we were able to define and manage cloud budgets for each student and each project through intuitive account sandboxing and budget transfer features.”
Common questions
Do students need their own cloud accounts?
No. Everything runs in the institution’s own cloud accounts. Students sign in and reach their environment in a browser, with no cloud account to create, no credentials to issue and nothing to install on a laptop that may not be capable of the work anyway.
How do we stop a class overspending?
Each student has their own budget, and a launch that would exceed it is refused rather than reported afterwards. Machines nobody is using stop themselves and keep their state, so an environment left open overnight does not consume the module’s funding.
What happens when a student runs out of budget mid-assignment?
They can ask for more, and a lecturer or administrator can transfer budget across, set a new figure, or let budgets top up automatically. Nobody is blocked at a deadline waiting for a ticket, and nobody has to hand out an unlimited account to avoid that.
Can students use the real cloud console safely?
Yes, and it is one of the better reasons to do this. Each student gets a genuine sandboxed account, restricted to the regions, services and machine sizes the course needs, with a budget of its own. They learn the provider’s actual tools rather than a simulation, and the account cannot be used to run up a bill nobody approved.
How do students sign in?
Through your existing single sign-on, as themselves. There are no separate credentials to issue at the start of term or reset during it, and when someone leaves the institution their cloud access goes with their account rather than waiting to be noticed.
How does a lecturer help a student who is stuck?
They can work as that student and see exactly what the student sees, which is a great deal more useful than a screenshot from someone who does not yet know the vocabulary to describe the problem. Whether this is permitted is set by the institution.