Cloud permissions
Appaloft Cloud organization permissions, assignable roles, and plan availability.
Cloud
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
ownerandadminroles map to the same Cloud permissions. Historicalmemberrows remain compatible asdeveloper. - Unknown role strings fall back to
vieweras 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.