Projects

Projects group resources and credentials inside an organization. Organizations contain projects, and projects contain everything else: every sandbox, image, snapshot, volume, secret, registry credential, and API key is scoped to exactly one project.

Projects are the unit of isolation. Nothing is shared between projects implicitly: a secret or volume in one project is invisible to sandboxes in another, and a project's API key cannot see other projects' resources. Organizations are the unit of membership and billing.

Every organization has a project named default that cannot be renamed or deleted. The name is reserved, so no other project can use it.

Project access

Projects also decide which organization members can reach their resources:

• Organization admins can access every project.
• Every member can access the default project.
• Any other project is visible only to members who have been added to it. Members who are not on a project get a 404 for it, as if it did not exist.

Whoever creates a project is added to it automatically.

Projects are managed on the dashboard's Projects page and switched in the header's organization and project switcher. These routes use your dashboard session token (an OIDC bearer JWT), not a project API key, and need matching organization project permissions.

Create projects

Create a project. Names are trimmed, unique per organization, and up to 100 characters.

1. Go to Daytona Dashboard
2. Click Create Project
3. Enter a Name for the project
4. Click Create Project

You can also click the project switcher in the header and choose Create Project.

daytona project create my-project --org ORG_ID

The creator field is null unless the caller holds the members read permission.

Operations

List projects

List the projects you can access in an organization, newest first.

daytona project list --org ORG_ID

Select project

Select the project that later CLI commands run against. The selection is per organization, so switching organizations restores your last project there. Pass an ID or an unambiguous name; with no argument, the CLI shows a picker at a terminal.

daytona project use PROJECT_ID

Get by ID

Get a single project.

daytona project get PROJECT_ID

Rename projects

Rename a project. The default project cannot be renamed.

1. Go to Daytona Dashboard
2. Click the ⋮ menu of the project
3. Click Rename
4. Enter the new name and confirm

daytona project update PROJECT_ID --name my-renamed-project --org ORG_ID

Delete projects

Delete a project, revoking its API keys and removing its secrets and registries. The default project cannot be deleted.

1. Go to Daytona Dashboard
2. Click the ⋮ menu of the project
3. Click Delete
4. Confirm the deletion

daytona project delete PROJECT_ID --org ORG_ID

Project budgets

A project budget caps the project's spend in each calendar month, in UTC, at list price and before credits. When the month-to-date spend reaches the budget, creating, forking, starting, or resuming a sandbox in the project, or restoring one from a snapshot, is refused. After the organization's grace period, running persistent sandboxes are stopped and running ephemeral sandboxes are deleted. macOS sandboxes, which run on a prepaid Mac reservation, keep running until the reservation's paid period ends; while the project is held, a renewal fails, so the reservation ends at the end of its paid period. The hold lifts at the start of the next month; when the grace period would end after that, no sandbox is ended that month.

Spend is evaluated periodically and can lag usage by several minutes.

Get a project budget

Get a project's monthly budget and this month's spend. The SDKs, and the API with an API key, read the budget of the API key's project.

from daytona import Daytona

daytona = Daytona()

budget = daytona.v2.get_project_budget()
if budget.monthly_limit_cents is None:
    print("The project has no budget")
else:
    print(f"Spent {budget.spent_cents} of {budget.monthly_limit_cents} cents")

Set a project budget

Set or replace a project's monthly budget.

1. Go to Daytona Dashboard
2. Click the project
3. In the Budget section, click Set budget, or Edit budget to replace an existing one
4. Enter the Monthly budget in USD
5. Click Save

# The argument is optional; omit it to use the selected project
daytona project budget set PROJECT_ID --monthly-usd 500

Remove a project budget

Remove a project's monthly budget. Removing it releases a budget hold on the project; sandboxes that were already stopped stay stopped.

1. Go to Daytona Dashboard
2. Click the project
3. In the Budget section, click Remove budget
4. Confirm with Remove

# The argument is optional; omit it to use the selected project
daytona project budget remove PROJECT_ID

Lifecycle defaults

Lifecycle defaults set the timeouts that new Linux sandboxes in a project receive when the create request leaves them out. A project stores them as defaults for ephemeral sandboxes, and these timeouts always delete the sandbox. A macOS create does not take the project's lifecycle defaults: it gets the platform defaults.

Daytona reads the defaults only when it creates a sandbox. Each field the create request sets overrides the matching default, and saving new defaults never changes existing sandboxes.

Get lifecycle defaults

Get a project's stored lifecycle defaults and the policy a create without lifecycle settings receives for each sandbox type.

1. Go to Daytona Dashboard
2. Click the project
3. Open the Settings tab and find the Sandbox Lifecycle Policy section

curl 'https://api.daytona.com/projects/PROJECT_ID/lifecycle-policy' \
  --header 'Authorization: Bearer YOUR_OIDC_TOKEN'

{
  "policy": {
    "ephemeral": { "timeout_seconds": 1800, "idle_timeout_seconds": 600 }
  },
  "effective": {
    "linux": {
      "ephemeral": { "timeout_seconds": 1800, "on_timeout": "delete", "timeout_source": "project", "timeout_capped": false, "idle_timeout_seconds": 600, "on_idle_timeout": "delete" }
    }
  }
}

Update lifecycle defaults

Update a project's lifecycle defaults. Each block is updated as a whole: a block left out of the request is kept, an empty value clears it, and a sent block replaces the stored one, so a field left out of a sent block is unset.

1. Go to Daytona Dashboard
2. Click the project
3. Open the Settings tab
4. In the Sandbox Lifecycle Policy section, click the edit button on the Ephemeral sandboxes card
5. Set the timeouts, then click Save

curl 'https://api.daytona.com/projects/PROJECT_ID/lifecycle-policy' \
  --request PATCH \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer YOUR_OIDC_TOKEN' \
  --data '{
    "ephemeral": { "timeout_seconds": 1800, "idle_timeout_seconds": 600 }
  }'

Project members

Control which organization members can access a non-default project. Organization admins are members of every project implicitly and do not need to be added.

List project members

daytona project member list --project PROJECT_ID

The implicit flag is true for organization admins, who have access without a membership entry.

Add project members

Add one or more members in one request.

daytona project member add USER_ID --project PROJECT_ID --org ORG_ID

daytona project member add --bulk USER_ID_1,USER_ID_2 --project PROJECT_ID --org ORG_ID

Remove project members

Remove a member from a project. Unless they are an organization admin, removal also revokes the API keys they minted in the project; admins keep access through their role.

daytona project member remove USER_ID --project PROJECT_ID --org ORG_ID

Project service accounts

List project service accounts

List the service accounts that can hold API keys in a project. A service account mints keys only in projects it has been added to. The default project is open to every service account.

daytona project service-account list --project PROJECT_ID

Add project service accounts

Add a service account to a project. Archived service accounts cannot be added, and you must hold every permission the account holds.

daytona project service-account add SERVICE_ACCOUNT_ID --project PROJECT_ID --org ORG_ID

Remove project service accounts

Remove a service account from a project, revoking every API key it holds there.

daytona project service-account remove SERVICE_ACCOUNT_ID --project PROJECT_ID --org ORG_ID

Project secrets and registries

Secrets and registry credentials belong to a project. Manage them with a credential that acts in the project: a project API key, or the access token from exchanging a token for that project. The CLI uses the selected project's credential after you sign in.

Permissions

Projects and their budgets, members, and service accounts are governed by organization permissions, which you can grant through an organization role. A project API key or project access token reads the budget of its own project with the project spending permission.

Changing a lifecycle default whose action is delete also requires the permission to delete sandboxes. The audit logs record project creates, updates, and deletes, and budget, member, and service account changes.