---
title: "Cloud permissions"
description: "Appaloft Cloud organization permissions, assignable roles, and plan availability."
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.appaloft.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Cloud permissions

{/* appaloft-cloud-docs-injected: cloud-permissions/v1 */}

<span className="inline-flex items-center rounded-full border border-blue-500/30 bg-blue-500/10 px-2 py-0.5 text-xs font-bold text-blue-700">Cloud</span>

# Cloud Permissions

Appaloft Cloud organization permissions are enforced by the backend operation guard. Member pages, invite dialogs, and dropdowns only show the available choices; the actual allow or deny decision comes from Cloud authorization policy.

## Plan Availability

| Plan | Assignable organization permissions | Notes |
| --- | --- | --- |
| Free | `owner`, `developer` | Keeps the minimum team model. Invited members default to `developer`. |
| Basic | `owner`, `developer` | Same as Free for core collaboration. Fine-grained permissions are not unlocked. |
| Team | `owner`, `admin`, `developer`, `billing`, `viewer` | Unlocks Basic RBAC so governance, delivery, billing visibility, and read-only access can be separated. |
| Business | `owner`, `admin`, `developer`, `billing`, `viewer` | Inherits Team's Basic RBAC. |
| Enterprise | `owner`, `admin`, `developer`, `billing`, `viewer` | Inherits Basic RBAC. Custom roles, project-level roles, SSO/SCIM, and custom policy controls remain future Enterprise scope. |

## Organization Permission Model

| Permission | Best for | What it can do |
| --- | --- | --- |
| `owner` | Founders and final organization owners | Full organization capability, including organization deletion, ownership transfer, member invites, role changes, resources, and deployments. |
| `admin` | Team leads and platform administrators | Manages non-owner members and most product operations; cannot transfer ownership, delete the organization, or change/remove owners. |
| `developer` | Developers, operators, and delivery engineers | Creates and manages projects, resources, deployments, and runtime actions; cannot manage organization members or billing settings. |
| `billing` | Finance, procurement, and FinOps | Reads projects, resources, and billing-adjacent information; cannot deploy, mutate resources, or govern members. |
| `viewer` | Auditors, support, and external collaborators | Read-only access to projects, resources, deployments, members, and configuration summaries. |

## Permission Matrix Summary

| Capability area | owner | admin | developer | billing | viewer |
| --- | --- | --- | --- | --- | --- |
| Project, resource, and deployment reads | Allow | Allow | Allow | Allow | Allow |
| Project lifecycle management | Allow | Allow | Allow | Deny | Deny |
| Delivery and runtime operations | Allow | Allow | Allow | Deny | Deny |
| Blueprint marketplace installation | Allow | Allow | Allow | Deny | Deny |
| Member invite, role change, remove, restore | Allow | Non-owner members only | Deny | Deny | Deny |
| Ownership transfer and organization deletion | Allow | Deny | Deny | Deny | Deny |
| Instance maintenance | Instance super admin only | Instance super admin only | Instance super admin only | Instance super admin only | Instance super admin only |

## Defaults And Compatibility

- Newly invited members default to `developer`, because delivery collaboration is the primary Cloud workflow.
- Historical Better Auth `owner` and `admin` roles map to the same Cloud permissions. Historical `member` rows remain compatible as `developer`.
- Unknown role strings fall back to `viewer` as the least-privileged permission.
- Owner governance cannot be bypassed through ordinary role changes. Setting an owner, transferring ownership, or changing/removing owner members must pass ownership-transfer invariants.

## Backend Enforcement

Cloud permissions are not UI decoration. Every product operation has a CASL policy. Denied calls return an authorization error with auditable trace attributes such as `appaloft.cloud.authz.denied` and a denial reason. API, CLI, worker, and Web console entrypoints share the same operation guard.

Source: https://docs.appaloft.com/en/cloud/permissions/index.mdx