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.Documentation Index
Fetch the complete documentation index at: https://ona.com/docs/llms.txt
Use this file to discover all available pages before exploring further.
What organizations contain
| Resource | Description |
|---|---|
| Projects | Environment configurations linked to repositories |
| Runners | Infrastructure for running environments |
| Members | Users with role-based permissions |
| Groups | Collections of members for access management |
| Teams | Organizational units used for usage attribution and per-team credit budgets |
| Organization roles | Delegated admin roles for runners, projects, groups, and automations |
| Secrets | Shared credentials and API keys |
| Policies | Organization-wide settings and restrictions |
Groups vs. teams
Groups and teams are two ways to organize people in an organization. They solve different problems and most organizations use both.- Use a group to answer “who can use this runner?” or “who can edit this project?”
- Use a team to answer “who’s on the Backend team?” and “how much did Backend spend this month?”
| Groups | Teams | |
|---|---|---|
| Purpose | Access control for projects, runners, and automations | Organizational reporting and cost management |
| Membership | A member can belong to many groups | A member belongs to at most one team per organization |
| Provisioning | Managed in Ona, or synced from your identity provider via SCIM | Managed in Ona |
| Visibility | Group membership is visible to organization members | All organization members can see all teams |
| Affects billing reporting? | No | Yes, usage is rolled up per team |
| Affects access to resources? | Yes | No |
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:- create or join the organization
- connect identity and invite members
- add runners or enable Ona Cloud regions
- create shared projects
- apply policies, secrets, and guardrails as the team grows