# Organizations and access ## Organizations Every repository belongs to an **organization**, and its URL is `oak.space//`. Every account comes with a **personal organization** named after its username; create shared ones for teams and companies from your dashboard (or `POST /api/orgs`). The organization is also where storage is accounted and **deduplicated**: content is stored once per organization, so the same large asset committed to five of its repos costs one copy. Storage quotas, CI minutes, and CI concurrency are all per organization — see [Plans and limits](/docs/limits). A personal organization always has exactly one member. To work with others, create a shared organization and invite them. ## Members and roles | Role | Can | |---|---| | **Owner** | Everything, including deleting the organization. | | **Admin** | Manage members, groups, repository access, service accounts, and settings. Full access to every repo. | | **Member** | Create repos in the organization, and read or write the repos they've been given access to. | Manage members under **Settings → Members** on the organization's page (`oak.space//settings`). Admins and owners can always read and write every repo in the organization, and are the only people who can change a repo's [path permissions](/docs/path-permissions) once they're set up. ## Who can see a repository A **public** repo can be read by anyone, signed in or not — on the web, with `oak clone`, and with stock `git clone`. Only people with write access can push branches or merge. A **private** repo can be read by: - the organization's **owners and admins**, and - people added to that repo as **collaborators**, with either the `reader` or `writer` role. Note that being a plain **member** of the organization doesn't by itself grant access to its private repos — add members as collaborators on the repos they need. Manage collaborators under the organization's **Settings → Repository access**; invited people get an email. Change a repo's visibility under the repo's **Settings**, or with `PATCH /api/{owner}/{name}/visibility`. Inside a repo, [path permissions](/docs/path-permissions) can narrow access to particular directories, or publish parts of a private repo to everyone. ## Groups A **group** is a named list of an organization's members, such as `sec-team` or `contractors`. Groups exist so that [`.oak/PERMISSIONS`](/docs/path-permissions) can grant access to `@group/sec-team` instead of listing people one by one — membership is managed in one place, here, rather than in every repo's file. Owners and admins manage groups under **Settings → Groups**, or with the [API](/docs/api#organizations). ## Service accounts A **service account** (listed as **Agents** in organization settings) is a non-human identity for automation — a deploy bot, a CI system, a long-running coding agent. It gets its own API keys with explicit scopes, and its actions show under its own name in the audit log. See [API keys and tokens](/docs/api-keys#service-accounts). ## Moving and renaming - **Transfer a repo** to another organization from the repo's **Settings** (or `POST /api/{owner}/{name}/transfer`). Its history, branches, and settings come along. - **Rename a repo** from its **Settings**. - **Rename an organization's slug** from the organization's **Settings → General**. URLs that use the old slug stop working, so update remotes and links. ## Audit log Owners and admins can see who did what — membership changes, merges, forced merges past CI, settings changes — at `oak.space/orgs//audit`, or `GET /api/orgs/{slug}/audit`. ## The organization page `oak.space/` is the organization's landing page. Under **Settings → Page** you can give it an About section in Markdown, an image, custom CSS, and choose whether it's public. To serve a whole static site from a repo, see [Sites](/docs/sites).