# Account model

Source: https://docs.quake.ai/docs/account/concepts
Markdown: https://docs.quake.ai/docs/account/concepts.md
> How Rumble.com identity, organizations, projects, resource tiers, team roles, and application credentials fit together, and how the portal and console divide responsibilities.

---

# Account model

Quake AI organizes everything you own around three nested ideas: your identity, an organization, and the projects inside it. Resource tiers, team roles, and application credentials all attach to those ideas. This page explains how the pieces relate so the procedures in the rest of the Account & Billing section make sense as a whole. For step-by-step instructions, follow the links in each section.

## The three layers

Your account has three layers, from the outside in.

<Figure caption="Identity signs in to an organization, which holds region-scoped projects; each project carries a resource tier and its own application credentials">

```d2
account: Rumble.com account {shape: person}

org: Organization {
  members: Team members
  billing: Billing and subscriptions

  proj1: Project (region a) {
    tier1: Resource tier
    creds1: Application credentials
  }
  proj2: Project (region b) {
    tier2: Resource tier
  }
}

account -> org: signs in
org.members -> org.proj1: project role
org.members -> org.proj2: project role
```

</Figure>

**Identity** is your Rumble.com account. The same login works across Rumble platforms, and Quake AI authenticates against it. You register with an email and password or through single sign-on (Apple, Google, or Facebook), and you manage two-factor authentication from your Rumble.com security settings.

**An organization** groups related projects and team members under one billing entity. You create an organization the first time you set up Quake AI. One organization can hold multiple projects, and each project can live in a different region.

**A project** is the resource and billing isolation unit. It owns the instances, networks, volumes, buckets, and other resources you provision, it carries its own quota, and it produces its own subscription charge. Projects are where you do day-to-day infrastructure work.

## Projects are the isolation boundary

A project is the boundary that owns resources, applies quota, and generates a bill. You pick its region when you create it, and that choice holds for the life of the project. To separate environments such as production, staging, and tooling, you create separate projects rather than partitioning a single one.

For readers coming from AWS, a Quake AI project is the closest analog to an AWS account that sits inside an AWS Organization: it is the unit that holds resources and receives the bill. The organization above it plays the role AWS Organizations plays. The full service-by-service mapping lives in [Coming from AWS](/resources/migration/coming-from-aws).

You create and switch projects from the portal. See [Manage cloud projects](/docs/account/projects) for the procedure.

## Resource tiers shape the project subscription

Each project carries a **resource tier**, a billing category that bundles a set amount of compute, memory, and storage into a fixed monthly subscription. Quake AI documents three standard tiers:

| Tier | vCPUs | RAM | Block storage | Object storage |
|---|---|---|---|---|
| Developer | 1 shared | 1 GiB | 20 GiB NVMe | Add-on |
| OpenClaw Starter | 4 shared | 4 GiB | 25 GiB NVMe | Add-on |
| Basic | 4 dedicated | 16 GiB | 50 GiB NVMe | Add-on |

The tier sets the project's quota: the total vCPUs, RAM, and storage you can allocate. Within that quota you launch individual instances using flavors (named vCPU, RAM, and disk combinations). You can customize a tier by adding vCPUs, memory, storage, or public IPv4 addresses, and you can upgrade, downgrade, or pause a tier at any time. Pausing reduces billed resources to zero so the project holds its place without a charge.

The [resource tiers reference](/docs/account/resource-tiers) covers the tier specifications and the dedicated-versus-shared vCPU distinction. For current prices, see the [pricing reference](/docs/account/billing/pricing). The [Quake AI pricing page](https://www.quake.ai/pricing/) hosts the custom-package slider.

## Two levels of roles

Team members hold roles at two levels: the organization and the project. The two levels answer different questions. Organization roles control who can manage the account, projects, users, and billing. Project roles control what a member can do with the resources inside one project.

You add a member to the organization first, then assign them to specific projects. A member with no project assignment can belong to the organization without touching any project's resources.

### Organization-level roles

You manage these under **Organization** > **Team** in the portal.

| Role | Manage org | Manage projects | Manage users | Billing access |
|---|---|---|---|---|
| Owner | Full | Full | Full | View and pay |
| Manager | Full | Full | All except owners | View and pay |
| Member | View | View (assigned only) | View | None |
| Billing Admin | None | View | View | Full |

### Project-level roles

You assign these when you add a member to a specific project.

| Role | Access |
|---|---|
| Project Reader | Read-only access to compute resources (instances, networks, routers, and volumes) |
| VM Admin | Read-write access to compute resources |
| Object Storage Admin | Read-write access to object storage resources |
| Project Admin | Read-write access to both compute and object storage |

See [Manage your account](/docs/account/guide#add-members-to-your-team) for inviting members at the organization level and [Manage cloud projects](/docs/account/projects#add-team-members-to-a-project) for assigning project roles.

## Application credentials authenticate workloads

The role tables above govern people working in the portal and console. Non-interactive workloads use a different mechanism: **application credentials**.

Application credentials are project-scoped secrets you generate to authenticate CLI tools, CI/CD pipelines, Terraform, and scripts against the OpenStack API. The identity service (OpenStack Keystone) backs them. A credential carries one of three coarse Keystone project roles, `admin`, `member`, or `reader`, which set how much of the project's API the workload can use.

Two properties follow from how application credentials work:

- **Project-scoped.** A credential is valid only inside the project that issued it. To limit blast radius, you separate workloads into different projects and issue each its own credentials.
- **Coarse roles, no policy language.** Authorization uses the three Keystone roles rather than per-resource policy documents. You express isolation through the project boundary rather than fine-grained grants.

The [tools and credentials model](/docs/tools/concepts) explains how application credentials sit alongside API tokens, S3 credentials, and SSH keys. Generate application credentials from the console or CLI per [Generate application credentials](/docs/tools/generate-app-credentials).

## Portal and console divide the work

Quake AI splits management across two surfaces. You sign in to both with your Rumble.com account.

| Surface | URL | What you do there |
|---|---|---|
| Portal | `portal.rumble.cloud` | Manage organizations, projects, team members, resource tiers, subscriptions, invoices, payment methods, and help desk |
| Console | `sky.<region>.rumble.cloud` | Provision and operate resources: instances, networks, volumes, buckets, and Kubernetes clusters |

The portal is the management layer above your cloud. It is global and works from any browser regardless of where your resources live. The console is region-scoped: each project opens its own console URL, and you reach it from the project's page in the portal. The [portal reference](/docs/account/portal) documents the portal views, and the [console dashboard](/docs/account/dashboard) covers the quota bars you land on after opening a project.

## Where billing fits

Billing attaches to the organization and breaks out per project. Each project's resource tier and add-ons produce a fixed monthly subscription, and every plan includes unlimited data transfer. Invoices arrive on a monthly cycle, and add-ons such as extra object storage or additional public IPs appear as line items.

[How billing works](/docs/account/billing/how-billing-works) explains the monthly model and what appears on an invoice. The [Account & Billing FAQ](/docs/account/faq) answers practical questions about payment methods, invoices, and subscription changes.

## Related reading

- [Account & Billing overview](/docs/account): entry point for account, project, and billing tasks
- [Manage your account](/docs/account/guide): account setup, organizations, and team roles
- [Manage cloud projects](/docs/account/projects): create projects, assign roles, change tiers
- [Resource tiers](/docs/account/resource-tiers): tier specifications and vCPU types
- [How billing works](/docs/account/billing/how-billing-works): the monthly subscription model
- [Tools and credentials model](/docs/tools/concepts): how application credentials relate to other authentication surfaces
- [IAM on Quake AI](/docs/account/concepts/iam): AWS/GCP/Azure IAM vocabulary mapped to projects, roles, and credentials
- [Coming from AWS](/resources/migration/coming-from-aws): AWS account and IAM mapped to Quake AI projects and credentials