RosettaCloud™ Compute
Machines, pools and notebooks
Open the cloud
to everyone who needs it.
A statistician, a biologist and a first-year student all need serious compute, and none of them are going to become cloud engineers to get it. Pitch the abstraction at what they already understand, a machine with their software on it, and the cloud becomes available to all of them.
Open a browser,
and the work is there
People arrive at the tool they already use, with the packages the work depends on already present.
Notebooks
Jupyter and RStudio, the environments a data scientist or a researcher was going to open anyway.
A desktop
A full graphical session in the browser, for the licensed applications a course or a lab is built around.
An editor
VS Code in the browser, running next to the data rather than across a network from it.
A machine and a terminal
For the people who want exactly that, with the same limits applying underneath.
People start their own work
They launch what they need, see what it costs, and ask for more when they run low. With RosettaOps governing the accounts, an administrator answers that request, or steps in and works alongside them.
A budget they can see
Spend is visible while the work happens, so a limit approaching is something a person notices rather than something they are told about later.
A budget that can move
Ask for more, and an administrator can transfer budget across, set a new figure, or let budgets top up on their own. Running out is a conversation, not a dead end.
Help that actually helps
A lecturer or administrator can work as the user and see exactly what they see. Support stops depending on someone describing a screen they do not recognise.
Whether anyone may work as another user is granted by the organisation and by the account, so it is a permission, not an assumption.
One machine, or one each
The same description covers both, which is why giving thirty people an environment costs about as much effort as giving one person an environment.
A single machine
One person, one environment, started and stopped by them without anybody else being involved.
A pool
A minimum, a maximum and a desired count from one description, so a group draws a copy each on demand.
On spot, either way
Both run on spare capacity where the work allows it, hibernating rather than dying when the cloud takes the instance back.
It comes up connected
Most of the time between having a machine and using one goes on the work between the pieces. That part is done for you, identically on every cloud.
Storage is already mounted
Attach the storage a machine needs and it is there at its path when the machine comes up. Nobody edits a mount table, copies data in, or explains to the next person where the files went.
There are no keys to hand out
Cloud keys are held by the platform, not by the people using it. Nobody is emailed a private key, nobody stores one on a laptop, and there is nothing to rotate or to leak.
Certificates are issued and attached
A service that should be reachable over HTTPS comes up that way, without a certificate request, a renewal reminder, or an expiry nobody noticed until it broke.
It has a name, not an address
DNS records are created on the domains you have mapped, so people reach the machine by a name that means something and keeps working when the machine behind it changes.
And you can share it while it is running
A live machine is shared with a colleague, a group or a whole organisation the way a document is. They get access to the thing itself, not a copy of it and not a rebuild of it, and that access ends when the share does.
See how sharing works →Machine images
Expertise, saved once
and used by everyone
The days somebody spent getting an environment right are worth more than the machine that holds them. An image turns that work into something other people launch.
Captured from a machine
Take an image of one that works, or register one you already had, and it becomes a starting point rather than a page of instructions.
It knows what it needs
The image records which machine types it runs on, what software it carries, which ports it uses, and whether it supports GPUs or hibernation, so a launch behaves predictably.
Shared or published
Keep it private, give it to a group, or publish it so anyone in the organisation can launch from it without asking.
Decided once,
by the person who should decide it
Everything below belongs to whoever prepares the environment. The person launching it inherits good answers without having to know the questions existed.
The machine itself
Any instance type the cloud offers, with GPUs where they are needed, in the zone or placement group you choose.
The root volume
Size, type, throughput and IOPS, encrypted with your own key, kept or discarded when the machine goes.
How it is reached
A browser session, a desktop or a terminal, restricted to the source addresses you allow, on a private subnet if it should not be reachable at all.
When it stops
An autostop rule for idleness and a lifetime limit for certainty. You decide whether the user may change them.
Spot behaviour
Stop or hibernate when capacity is reclaimed, and return automatically when it comes back.
Network limits
Caps on data in and out, with an action you choose when a machine crosses the threshold.
Monitoring and logs
Metrics and log collection per formation, with a retention period you set rather than inherit.
Who else can use it
Share it with a person, a group or an organisation, and every copy stays inside the same limits.
The same machine
your budget knows about
A launch beyond budget is refused at the cloud’s own API. An idle machine is one of twenty eight kinds of waste that get detected. Cost lands on the person and the project that started it, in your own account, on your own bill.
Common questions
Can people who do not know the cloud use this?
That is what it is for. Someone who knows the cloud describes the environment once, and everyone else launches it from a browser and opens Jupyter, RStudio, VS Code or a desktop. No cloud account, no credentials, no console, and nothing to install locally.
What happens when someone runs out of budget?
They see it coming, because the budget is visible while they work rather than discovered afterwards. Where RosettaOps governs the accounts, they can request more and an administrator can transfer budget to them, set a new figure or let budgets top up automatically, so the limit is a conversation rather than a wall.
How does an administrator help someone who is stuck?
Where RosettaOps governs the accounts, an administrator can work as that person and see exactly what the user sees, so support does not depend on screenshots or on someone describing a screen they do not recognise. Whether this is permitted is set by the organisation and by the account, so it is granted rather than assumed.
Can one description give a whole group an environment each?
Yes, that is a machine pool: one description, a minimum, a maximum and a desired count. Everyone in the group draws their own copy without an allocation step. The same mechanism is what makes a virtual lab for a class work.