Skip to content

Onboard Your Organization

From registration form to governed cloud accounts. This is the RosettaOps path.

This is one of two ways to be onboarded

This page is the organization path: RosettaOps, many accounts, many people, and governance over both.

If you are one person bringing a cloud account you already own, you want RosettaCloud instead, and the shorter Sign Up as an Individual path -- one template, a free tier, and no organization to create.

For bringing individual people into an organization that already exists -- self-registration, manager-created users, SSO auto-provisioning -- see User Onboarding.

For the same registration done through the console with screenshots, see the Register Your Organization tutorial.

The Flow

flowchart TD
    Reg["1. Submit the registration form"] --> Email["2. RosettaHub emails your credentials,<br/>UserUid and API key"]
    Email --> Deploy["3. Run the deployment runbook<br/>for your estate"]
    Deploy --> Done["Cloud accounts registered<br/>and governed"]

    style Reg fill:#e3f2fd,stroke:#1565c0,color:#000
    style Email fill:#fff9c4,stroke:#f9a825,color:#000
    style Deploy fill:#e8f5e9,stroke:#2e7d32,color:#000
    style Done fill:#e8f5e9,stroke:#2e7d32,color:#000

Step 1 -- Register the Organization

Submit the institution registration form:

https://www.rosettahub.com/registration/institution.xhtml

This creates your organization on the platform and the first user account, which becomes the owner of everything that follows.

Step 2 -- Receive Your Credentials

RosettaHub sends an email containing:

What Used for
Console credentials Signing in to the RosettaHub web console and desktop app
UserUid A CloudFormation parameter. Identifies the platform user the organization attaches to, and doubles as the sts:ExternalId on the control role's trust policy
ApiKey A CloudFormation parameter. Authorises the registration call each template makes back to the platform

Keep the API key safe

ApiKey is a platform credential, not an AWS one. It authorises registering cloud accounts against your organization. Templates declare it as NoEcho, so it stays out of CloudFormation console output and stack events, but anyone who can read a deployed stack's Lambda configuration in an account can retrieve it. Treat it accordingly, and rotate it through the console if you suspect exposure.

Step 3 -- Deploy

Two questions decide this. The first picks your runbook, the second picks your template and flags.

Which runbook: who owns the accounts?

  • RosettaHub creates them

    One command. Leave the functional account IDs empty and RosettaHub creates the FinOps, audit and log-archive accounts, then vends member accounts as users need them.

    Automate only -- creating accounts needs the Lifecycle grant.

    Greenfield runbook

  • You bring existing accounts, roles on the payer

    Two commands. One stack on the payer, one StackSet across the accounts you already have.

    Any edition.

    Payer-only runbook

  • You bring existing accounts, separate functional accounts

    Four phases, in order. The control role deploys first so the functional templates can trust it.

    Any edition.

    Functional-accounts runbook

The member StackSet is for accounts you already have

Accounts RosettaHub creates are set up at creation and need no StackSet. You deploy the member template only over accounts you are bringing across. Estates with both do both.

Which template: which edition did you buy?

Edition Template family Flags
Observe RosettaOpsGovernance* EnablePermissions=false
Govern RosettaOpsGovernance* EnablePermissions=true
Automate RosettaOpsAdmin* EnableDestroy, EnableFederation, EnableMetacloud, EnableLifecycle. EnablePermissions is not a parameter here -- it is always on

Each runbook repeats this table and shows the commands for one family, so you never have to hold the mapping in your head while deploying.

Prerequisite for both

Member accounts are deployed by StackSet under service-managed permissions, which requires AWS Organizations with all features enabled. Consolidated billing alone will not do. You create no roles for StackSets yourself; CloudFormation provisions what it needs through Organizations trusted access. Ask us if your security review needs the detail of what that puts in your accounts.

What You Are Deploying

Which templates apply depends on the edition you bought. All are published as plain CloudFormation YAML at a public path, need no credentials to fetch, and can be read in full before you deploy anything.

BASE=https://com-rosettahub-public-code.s3.eu-west-1.amazonaws.com/cloudformation/2.0.0
curl -O $BASE/RosettaOpsGovernance.yaml
Edition Family Templates Key parameter
Observe Governance RosettaOpsGovernance* EnablePermissions=false
Govern Governance RosettaOpsGovernance* EnablePermissions=true
Automate Admin RosettaOpsAdmin* EnableDestroy, EnableFederation, EnableMetacloud, EnableLifecycle

Observe and Govern are the same file

Moving from Observe to Govern is a parameter change on a stack you have already deployed. Moving to Automate means deploying a different family, deliberately -- because that is where RosettaHub first gains an administrative path to an account. See Account Access and Scopes.

Within a family, which template goes to an account depends on what that account is:

Template Deploy to When
...Management Your management (payer) account Always
(base name) Every ordinary member account Always
...Functional FinOps, audit or log-archive accounts Only if those are separate accounts
RosettaOpsControlRole Your management (payer) account Only alongside the above
RosettaOpsOrgAccessRoleTrust Member accounts Optional, and last

Most organizations deploy the first two.

After Onboarding