Projects
Create and manage projects within your organization.
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.
| Concept | Description |
|---|---|
| Organization | The unit of membership and billing. Members, invitations, and credits belong to the organization. Contains any number of projects. |
| Project | The unit of isolation. Holds sandboxes, images, snapshots, volumes, secrets, registry credentials, and API keys. |
| API key | Minted per project. Confined to that project and to its permission scopes; revoking a key takes effect immediately for new requests. |
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
defaultproject. - Any other project is visible only to members who have been added to it. Members who are not on a project get a
404for 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.
- Go to Daytona Dashboard
- Click Create Project
- Enter a Name for the project
- Click Create Project
You can also click the project switcher in the header and choose Create Project.
daytona project create my-project --org ORG_IDThe creator field is null unless the caller holds the members read permission.
Operations
List projects
List the projects you can access in an organization. The default project is always listed first.
daytona project list --org ORG_IDSelect 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_IDGet by ID
Get a single project.
daytona project get PROJECT_IDRename projects
Rename a project. The default project cannot be renamed.
- Go to Daytona Dashboard
- Click the ⋮ menu of the project
- Click Rename
- Enter the new name and confirm
daytona project update PROJECT_ID --name my-renamed-project --org ORG_IDDelete projects
Delete a project, revoking its API keys and removing its secrets and registries.
The default project cannot be deleted.
- Go to Daytona Dashboard
- Click the ⋮ menu of the project
- Click Delete
- Confirm the deletion
daytona project delete PROJECT_ID --org ORG_IDProject 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 answers 402 PROJECT_BUDGET_EXCEEDED, so the reservation ends at its period_end. 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. Reading a budget requires the budgets read permission; setting or removing it requires budgets write.
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 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. Project budgets require the Team plan or above.
- Go to Daytona Dashboard
- Click the project
- In the Budget section, click Set budget, or Edit budget to replace an existing one
- Enter the Monthly budget in USD
- Click Save
# The argument is optional; omit it to use the selected project
daytona project budget set PROJECT_ID --monthly-usd 500| Flag | Type | Description |
|---|---|---|
--monthly-usd | string | Required. Monthly budget in US dollars, at least 1.00 and at most two decimals, such as 500 or 499.99. |
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.
- Go to Daytona Dashboard
- Click the project
- In the Budget section, click Remove budget
- Confirm with Remove
# The argument is optional; omit it to use the selected project
daytona project budget remove PROJECT_IDLifecycle 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 in the ephemeral block, and these timeouts always delete the sandbox. A macOS create does not take the project's lifecycle defaults: it gets the platform defaults, which the effective.macos block shows.
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.
- Go to Daytona Dashboard
- Click the project
- 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'The following response is abridged to the effective.linux.ephemeral block. The full effective object also has linux.persistent, windows, gpu, and macos blocks, and each policy also has wake_on_request.
{
"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" }
}
}
}The response has the following fields:
| Field | Description |
|---|---|
policy | Holds the stored values. An unset field is null. |
effective | Holds what a create with no lifecycle settings receives. |
timeout_source | The value in each effective block is project, platform, or none. |
timeout_capped | The value in each effective block is true when a stored timeout above the organization's timeout cap is capped to it. |
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.
- Go to Daytona Dashboard
- Click the project
- Open the Settings tab
- In the Sandbox Lifecycle Policy section, click the edit button on the Ephemeral sandboxes card
- 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 }
}'| Field | Type | Description |
|---|---|---|
ephemeral | object | Sets the timeouts for sandboxes. null clears the block. If omitted, the stored block is kept. |
ephemeral.timeout_seconds | integer | Sets the seconds until a sandbox is deleted, from 1 to the organization's maximum timeout. By default, it is unset. |
ephemeral.idle_timeout_seconds | integer | Sets the idle seconds until a sandbox is deleted. Values below 60 are raised to 60. By default, it is unset. |
Project members
Control which organization members can access a non-default project. Listing members requires the members read permission; adding and removing them requires the members write permission. Organization admins are members of every project implicitly and do not need to be added.
List project members
daytona project member list --project PROJECT_IDThe 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| Flag | Type | Description |
|---|---|---|
--bulk | string | A comma-separated list of user IDs, emails, or names. Cannot be combined with a positional user. |
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_IDProject 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_IDAdd 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_IDRemove 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_IDProject 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.