Organizations and projects

An organization is RunMat Server's tenant, membership, and policy boundary. Projects belong to an organization and provide isolated filesystem, history, event, and execution namespaces.

Assign organization roles using least privilege. Owners control the highest-impact lifecycle operations; administrators manage approved organizational resources; members and viewers receive narrower capabilities. Service identities should be separate from human users so access can be rotated without sharing credentials.

When creating a project, choose a stable name and ownership context, then define membership before importing sensitive files. Project deletion and retention behavior depend on deployment policy; export or snapshot required evidence before destructive lifecycle operations.

Every request is evaluated in its selected tenant and project context. A user who belongs to two organizations receives the permissions attached to the organization selected for that request. If a client appears to show the wrong project, verify the active organization before changing files or launching a run.

Resource hierarchy

Organization identity scopes memberships, plans, entitlements, SSO settings, package namespaces, projects, usage, and administrative audit. Project identity scopes filesystem paths, history, snapshots, project events, project membership, and optional remote runs.

APIs use stable IDs; clients may show human-readable slugs. A rename changes the display identity while preserving ownership and authorization. Archive and deletion operations follow the documented lifecycle so content, history, usage, and background cleanup remain consistent.

Add a collaborator

1. Add or provision the user in the organization.
2. Assign the least organization role needed.
3. Add project-specific read or write access when needed.
4. Refresh the client's account context if it cached /auth/me.
5. Audit role elevation and removal.

Service accounts represent headless automation. A CI identity usually needs write access only to the projects it builds. A reporting job usually needs read access. Remove its membership and revoke its key when the automation is retired.

Project lifecycle

Create the project in the organization that owns its policy and data. Import source, validate a clean local run, then add collaborators. Before archive or deletion, create or export any required snapshot and check artifact retention. A project snapshot records file versions; external datasets and uncaptured Runtime state require their own records.

Course and other specialized organization types have separate memberships, limits, dates, and grants. They remain distinct organization aggregates.

Misconfigurations to avoid

• Creating shared work in a personal organization and expecting team policy to apply.
• Granting organization admin for a task that only needs project write access.
• Reusing a person's API key in CI.
• Assuming removal can erase copies previously exported by a member.
• Treating a slug or opaque ID as proof of authorization.