Skip to content

The RosettaCloud Model

Four things to understand, and everything else follows from them.

Where the RosettaOps model is about what RosettaHub may do on your cloud accounts, this is about what your people do with them. It is the shape of the product rather than a feature list.

One Template, Any Cloud

The central idea is that an environment should be described once and run anywhere. Not a lowest common denominator, and not a translation layer that breaks on the first provider-specific feature -- a Formation captures everything an environment needs, and the platform resolves it against whichever cloud you launch it on.

That is why the same template gives you a Jupyter notebook on AWS today and on GCP next week, and why moving providers does not mean rewriting anything or retraining anyone.

Build it. Launch it. Share it.

Three verbs, and they are the whole lifecycle.

What it means
Build Describe the environment once. Compute, storage, networking, images, keys, certificates, and any Infrastructure as Code you already have
Launch Deploy it to any cloud in one click, inside whatever budget and permissions apply to you
Share Give it to a person, a group or an entire organization, across accounts and across clouds, without anyone writing an IAM policy

The Four Things You Work With

graph LR
    Key["Cloud Key<br/><i>one account, one region</i>"] --> Form["Formation<br/><i>the template</i>"]
    Form --> Sess["Session<br/><i>a running instance of it</i>"]
    Sess --> Art["Artifacts<br/><i>images, storages, snapshots</i>"]
    Art -.->|"reused by"| Form

    style Key fill:#fff9c4,stroke:#f9a825,color:#000
    style Form fill:#e3f2fd,stroke:#1565c0,color:#000
    style Sess fill:#e8f5e9,stroke:#2e7d32,color:#000
    style Art fill:#f5f5f5,stroke:#616161,color:#000

Cloud Keys

A Cloud Key is credentialed access to one cloud account in one region, with a dedicated platform-managed network created alongside it. On AWS and Alibaba Cloud these are roles assumed through temporary credentials rather than long-lived keys; on Azure and GCP they are the equivalent service identities.

Keys are provisioned for you when your account is created, for each region you are permitted to use.

Cloud Keys are the root of everything else

Every Formation, image, storage and snapshot is linked to the key that created or retrieved it. Delete a key and the RosettaHub artifacts linked to it are removed from the platform, along with the sharing relationships built around them. The underlying cloud resources are not deleted, but their representation on the platform is.

Formations

A Formation is the template. It combines up to ten kinds of component -- machine images, instance types, storages, container images, startup scripts, certificates, cluster definitions, and IaC templates in CloudFormation, CDK, Terraform, OpenTofu or Pulumi.

That last one matters: a Formation is not an alternative to the IaC you already have, it can carry it.

Sessions

A Session is a running instance of a Formation. Single-machine or multi-machine, it has a lifecycle of its own, and it is what you connect to.

Artifacts

Everything a Session produces or consumes that outlives it: images, storages, snapshots, container repositories, certificates, key pairs. These feed back into Formations, which is how an environment becomes reproducible rather than merely repeatable.

Sharing Without IAM

Anything in the list above can be shared with a user, a group, or an organization, and the platform issues the delegated credentials that make it work. Unshare and they are revoked.

Two consequences worth knowing:

  • It crosses accounts and clouds. A storage in one cloud account can be mounted on a machine in another. The boundary that usually makes this a project is handled by the platform.
  • It does not need an administrator. A researcher can share a dataset with a collaborator without anyone writing a policy or raising a ticket, because the delegation is the platform's to make.

Curated collections become portfolios, which act as private marketplaces, and anything can be published to the public marketplace.

With and Without RosettaOps

RosettaCloud works on its own. Sign up as an individual, connect a cloud account you own, get keys, build Formations, launch and share. Guardrails come from the Cloud Key itself: the instance types you are permitted, the region it is locked to, and its dedicated network.

With RosettaOps present, the same launches happen inside the governance layer. Budgets, quotas, region and service restrictions apply to everything a Formation tries to create, and they apply equally to anything launched directly in the cloud console. A user does not experience two systems: they build and launch as before, and the limits are simply real.

That combination is the full platform, and it is what an organization enables rather than a second product it buys. The scope is called MetaCloud: turn it on for an account and Formations can provision infrastructure there, under the same budgets and policy as everything else. It is a parameter on the deployment template rather than a default, and it is offered only on the Automate edition -- the Governance templates behind Observe and Govern declare no parameter that grants it, because those editions exist to have no path by which RosettaHub builds anything. See Account Access and Scopes.

This is what makes the combination worth more than the parts

Self-service without governance produces surprise bills. Governance without self-service produces tickets. The platform is both, and the same decision applies to a Formation launch and a console click.

Next Steps