RosettaHub™
One cloud API
Every cloud does the
same things.
None of them agree how.
A machine, a disk, a network, a cluster. The same handful of ideas, named differently and shaped differently by every provider, so knowing one cloud well earns you very little on the next. RosettaHub presents one set of operations over all of them, for building infrastructure and for governing it.
Twenty areas, one vocabulary
Each of these is the same operation with the same shape on AWS, Azure, Google Cloud, OVH and OpenStack. It covers both halves of the platform: the things you build, and the things that govern them.
What you build
Compute
Instance lifecycle, spot capacity, regions, machine types
Storage
Volumes, snapshots, file systems
Object storage
Buckets, objects, static hosting
Images
Register, snapshot and share machine images
Networking
Virtual networks, security groups, addresses, interfaces
Keys and encryption
SSH key pairs and managed encryption keys
Kubernetes
Clusters and node groups, drivers installed for you
Containers
Container services and private registries
Big data
Hadoop and Spark clusters
HPC
Schedulers, head nodes and autoscaling compute
DNS and CDN
Hosted zones, records and content delivery
Infrastructure as code
CloudFormation and Terraform stacks
How it is governed
Accounts
Create, name, inspect, close and recycle accounts
Permissions
Translate a role into whatever that cloud enforces natively
Billing
Wire up cost and usage data, and where it is delivered
Audit
Organisation trails, monitoring functions, audit roles
Federation
Time-limited sessions into the provider console
Lifecycle
Root credentials, account email, org-wide hygiene
Compliance
Run policies and collect findings across the estate
Marketplace
Subscriptions and entitlements from the provider
This is the half nobody else unifies. Creating an account, translating a role into native policy, wiring up billing and running a compliance scan are the same operations on every cloud too.
555
distinct operations, each the same on every cloud
20
capability areas, building and governing
5
clouds behind one interface
6
surfaces, every operation on each
That is the size of the vocabulary you learn once instead of learning six times.
Why almost nobody has this
Unifying cloud APIs has been attempted for over a decade. The attempts fall into three shapes, and each gives something up.
The libraries
Covered machines, and stopped
The open source abstraction libraries got compute right and little else. Networking, DNS and delivery were thin or missing, and almost no real system is a machine on its own. Most are now dormant.
The IaC tools
One workflow, not one API
Terraform and its relatives give you a single language and a single way of working, which is genuinely valuable. The resource definitions underneath stay provider-specific, so the description still has to be translated per cloud.
The control planes
Unified, if you live in Kubernetes
The Kubernetes-native control planes do reconcile across clouds, and they are a real answer for teams already running Kubernetes as their platform. For everyone else the cluster is a large thing to adopt in order to launch a machine.
Where the abstraction
stops, on purpose
An abstraction over several providers can flatten into a lowest common denominator: generic infrastructure that uses the strengths of none of them. The boundary is therefore drawn deliberately, and it is worth knowing where.
The surface stops where the equivalence does
An operation joins the unified surface when it has a real equivalent on every cloud. A common shape that only one provider implements well would cost you that provider’s strengths, so it stays where it is.
And the console is one click away
For anything provider-specific, a time-limited federated session drops you into that cloud's own console, under the same budgets and policy. The abstraction speeds up the common work without ever becoming a ceiling.
Portable intent where it helps, native access where it matters.
Every operation, on every surface
An API is only as useful as the ways you can reach it. There is no operation that exists in one place and not the others.
Dashboard
Composable panels
Desktop app
Mac, Windows, Linux
Command line
Scriptable, with cron
SDKs
Python, Java, JavaScript
Open API
Generate your own client
MCP servers
Drive it from an AI agent
One vocabulary is what makes that possible. An agent can learn a single set of operations instead of one set per provider.
“It allows us to establish a Multi-Cloud Campus, as the platform can be linked to major cloud providers like AWS and Microsoft Azure.”
Common questions
Is this the same as an infrastructure as code tool?
No. Those unify the tool, not the API. You write one workflow but the resource definitions are different for every provider, so moving between clouds means translating the description. Here the operation is the same call whichever cloud it lands on.
Does an abstraction like this limit me to the lowest common denominator?
That is the usual failure and it is avoided by not pretending to cover everything. The unified surface covers the operations that genuinely have an equivalent everywhere. For anything provider-specific you get a time-limited federated session into that cloud console, under the same governance, so the abstraction never becomes a ceiling.
Can I still use the provider SDKs?
Yes. Nothing is hidden and nothing is proxied away. The unified API is where the common work gets faster, and the provider console and SDKs remain available for the rest.
Which surfaces expose it?
A composable web dashboard, a desktop application, the command line, Python, Java and JavaScript SDKs, an open API, and MCP servers so an AI agent can drive the same operations. Every operation is on every surface.