Organizations and projects
Every resource on SdV Cloud — projects, services, deployments — belongs to exactly one organization. Understanding how organizations, projects, and roles relate to each other explains why certain things are visible or editable only to certain people.
Organization
Section titled “Organization”An organization is your team’s workspace. It owns every project you create, every person who works with you, and account-wide settings like whether two-factor authentication is required to sign in.
You can belong to more than one organization — for example, if you work with several clients or teams — and you always act within one organization at a time. Nothing you see or do ever crosses into another organization’s data.
Project
Section titled “Project”A project groups the service containers you deploy together — typically the pieces of one application or one client engagement. Projects exist to organize work, not to isolate it further: everyone with access to the organization can see its projects, and permissions are what actually control who can change what.
Two independent sets of roles apply, one at each level:
| Level | Roles | Controls |
|---|---|---|
| Organization | Owner, Member | The organization itself — billing-adjacent settings, security policy, who’s invited, which projects exist |
| Project | Owner, Developer, Auditor | One project — its services, deployments, and who’s on it |
An organization Owner can manage the organization, invite or remove people, enforce two-factor authentication for everyone, and create or delete projects. A Member can see the organization but needs project-level access to act on anything inside it.
Within a project, an Owner has full control — including managing who else has access. A Developer can create and configure services and trigger deployments, but can’t delete the project or change its membership. An Auditor can see everything in the project — services, deployments, logs — but can’t change anything. Organization Owners always have Owner-level access to every project, even without being added to it explicitly, since they’re accountable for the organization as a whole.
This split keeps day-to-day deployment work (project roles) separate from organization-wide decisions (organization roles), so a Developer can ship services without ever needing the ability to, say, remove a teammate from the organization.