Workspaces and orgs

Every interaction with githosted runs through this hierarchy:

user → organization → workspace → repo

You won’t usually think about all four. Most of the time it’s just a workspace and a repo inside it.

Organizations

An organization is the billing entity and the membership boundary. Every user gets a personal organization automatically on sign-up — a one-person org named after them. Companies and teams make new orgs explicitly.

Organizations are mostly invisible to solo users. They become relevant when:

• You add other people who need access to your repos
• Billing turns on (post-public-beta) and an org chooses a plan
• You want to keep work-stuff and personal-stuff under separate billing

Workspaces

A workspace lives inside an organization and owns a set of repos plus the tokens that access them. Workspaces are the isolation boundary for technical access — a workspace token can only see repos in its own workspace.

Most projects are one workspace. Reach for multiple workspaces inside the same org when you need to:

• Separate development environments (e.g. dev, staging, prod)
• Scope tokens narrowly so a leak only touches one slice of your estate
• Hand a slice of activity to another tool / agent / collaborator

Repos

A repo is a real Git repo. SDK calls produce real Git commits. You can git clone and git push the same repo from a terminal, or read and write its files through the SDK — both are first-class.

See Concepts → Repos for the longer version.

Slugs and IDs

Both organizations and workspaces have a slug (human-friendly, shows up in URLs) and a stable ID (org_…, ws_…). Slugs can be renamed; IDs cannot. The SDK accepts either, and the dashboard URL uses slugs:

/o/{org-slug}/w/{workspace-slug}/{repo-slug}

When the workspace is implied by the token (the common case), the SDK lets you use just the repo slug.