Organizations#
Every repository belongs to an organization, and its URL is oak.space/<organization>/<repo>. 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.
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/<org>/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 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
readerorwriterrole.
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 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 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.
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.
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/<org>/audit, or GET /api/orgs/{slug}/audit.
The organization page#
oak.space/<org> 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.