Organizations & Projects
Structure your team — organizations, members, invitations, projects, and API keys.
Everything in Daytona lives inside a two-level hierarchy: organizations contain projects, and projects contain everything else. Organizations are the unit of membership and billing — members and credits belong to the org. Projects are the unit of isolation — every sandbox, image, snapshot, volume, secret, object store, registry credential, and API key is scoped to exactly one project, and an API key for one project cannot see another project's resources.
When you sign in for the first time, Daytona automatically creates a personal organization (with you as its owner) and a default project inside it, so you can mint an API key and create your first sandbox immediately. The personal organization is yours alone: it cannot be deleted and cannot take additional members. For team work, create a separate organization.
All of the management operations below are available in the dashboard; they are also exposed as a REST management API authenticated with your user session (OIDC) rather than a project API key — see the management API reference.
Roles
Organization members have one of two roles:
| Role | Can do |
|---|---|
owner | Everything: manage the org itself, its membership and invitations, plus all project operations |
member | Manage projects, API keys, and project resources — but not the org itself or its membership |
An organization always retains at least one owner: the last owner cannot be removed.
Members and invitations
New people join an organization by invitation. An owner invites an email address with a role (owner or member); the invitee sees the pending invitation after signing in (in the dashboard, or via GET /invitations) and accepts it to become a member. Invitations expire after 14 days; re-inviting the same email refreshes the pending invitation rather than creating a duplicate.
Owners can remove members at any time. Removal takes effect for dashboard and management access immediately; project API keys are independent credentials, so review a project's keys when offboarding someone who held them.
Typical flow in the dashboard:
- Members page → invite by email, choose a role.
- The invitee signs in to
https://app.rl.trydaytona.comand accepts on the Invitations page. - The new member appears on the Members page and can access the org's projects.
Projects
Projects group resources and credentials. Common patterns are one project per environment (staging, production) or per application. Creating a project needs only a name (unique within the org); deleting a project removes it along with its scoped resources — there is no undo, so treat project deletion as a destructive operation.
What is project-scoped:
- Sandboxes, images, and snapshots
- Volumes and object stores
- Secrets and registry credentials
- API keys
Nothing is shared between projects implicitly — a secret or volume in one project is invisible to sandboxes in another.
API keys
API keys are minted per project on the dashboard's API Keys page (or via the management API). A key is shown once at creation — it looks like rlp_... — and only a hash is stored, so copy it immediately. Keys carry the full authority of their project: every SDK call and REST request made with the key is scoped to that project.
Revoking a key takes effect immediately for new requests. Mint separate keys per service or teammate so that revocation is surgical rather than disruptive.
See Authentication for how keys are passed in SDK configuration and REST requests.
See also
- Spending & Credits — how usage is billed against the organization's balance.
- Dashboard — where all of this is managed day to day.
- Management API reference — the OIDC-authenticated REST surface behind the dashboard.