Skip to main content
Organizations provide a shared space for development resources. Administrators can manage projects, environments, runners, and member access. For personal use, you can create an organization for yourself. Think of an organization as the administrative and security boundary for Ona. Projects, runners, secrets, login settings, and policies all live inside an organization.

​
What organizations contain

ResourceDescription
ProjectsEnvironment configurations linked to repositories
RunnersInfrastructure for running environments
MembersUsers with role-based permissions
GroupsCollections of members for access management
Organization rolesDelegated admin roles for runners, projects, groups, and automations
SecretsShared credentials and API keys
PoliciesOrganization-wide settings and restrictions

​
Isolation

Organizations are hard boundaries. Resources cannot be shared or transferred between them. Each runner, project, and environment belongs to exactly one organization. Users can be members of multiple organizations but must switch between them explicitly.

​
What admins usually manage

Organization admins usually own:
  • who can join and how they authenticate
  • which runners and projects are available
  • how resources are shared across teams
  • which guardrails and policies apply by default
  • what secrets and service accounts shared workflows can use

​
Common operating model

For many teams, the pattern looks like this:
  1. create or join the organization
  2. connect identity and invite members
  3. add runners or enable Ona Cloud regions
  4. create shared projects
  5. apply policies, secrets, and guardrails as the team grows

​
Next steps